When configuring RSVP, the “ip rsvp bandwidth (bandwidth) [per flow limit]” command there is an optional parameter which limits the per flow bandwidth of individual RSVP reservation. When using Call Admission Control for VoIP, that is the rate of an individual voice call in one direction, but the behavior is not as clear cut as it seems.
This feature was added to prevent other application from reserving all of interface’s reservable bandwidth. If a video application uses RSVP within the network, it can take up majority of the reservation with a single video call. For example if the smallest interface only has 500 kbps RSVP bandwidth and a video conference request all 500 kbps, no voice calls will be allowed through. Per flow limit wouldn’t allow one reservation to request all of the bandwidth. There are other methods to limit other application’s ability to reserve bandwidth with a more granular method using a RSVP local policy.
The actual VoIP rate is depended on many factors such as codec, sampling rate and header overhead.[1] The most common codec is either G.711 or G.729. For the G.711 codec, the IP rate is 80 Kbps and for G.729 it is 24 Kbps. Ideally setting the per flow limit to the max rate of a VoIP call would be a good design choice.
There is one hidden caveat with RSVP and VoIP as it relates to this feature. Configuring the per flow limit to 80 Kbps or 24 Kbps will not work. The voice gateways acting as RSVP agents do not request these rates. They assume the highest bandwidth for each codec and request a higher rate. For G.711 and G.729, the RSVP agents assumes the sampling rate is 10 ms which equates to a 96 Kbps rate and 40 Kbps respectably. After about one second, the RSVP agents request the new correct rate. Below is an output of “debug ip rsvp signaling” for a voice call. The first two reservations are requested with the 96 Kbps rate and one second later, another request is sent with a reservation for 80 Kbps.[2]
20:46:44.811: RSVP: 10.255.222.1_18504->10.255.221.1_17696[0.0.0.0]: start requesting 96 kbps FF reservation on GigabitEthernet0/1, neighbor 57.1.0.222
20:46:44.827: RSVP: 10.255.221.1_17696->10.255.222.1_18504[0.0.0.0]: start requesting 96 kbps FF reservation on GigabitEthernet0/0, neighbor 10.221.1.5
20:46:45.883: RSVP: 10.255.222.1_18504->10.255.221.1_17696[0.0.0.0]: start requesting 80 kbps FF reservation on GigabitEthernet0/1, neighbor 57.1.0.222
20:46:45.963: RSVP: 10.255.221.1_17696->10.255.222.1_18504[0.0.0.0]: start requesting 80 kbps FF reservation on GigabitEthernet0/0, neighbor 10.221.1.5
When calculating the number of G.711 calls allowed per circuit, it’s recommended to calculate one call at 96 Kbps and the rest at 80 Kbps.
[1] For exact calculation of VoIP bandwidth see Cisco’s Voice Codec Bandwidth Calculator https://tools.cisco.com/Support/VBC/do/CodecCalc1.do
[2] For more information on the RSVP bandwidth calculation see Resource Reservation Protocol in the Cisco Unified Communications Manager System Guide, Release 7.0(1) http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_0_1/ccmsys/a02rsvp.html#wp1071163