Table of Contents
Bandwidth Calculation
Signal
The recommended bandwidth needed for call control traffic can be obtained from the following formula:
Equation 1A: Recommended Bandwidth Needed for SCCP Control Traffic without Signaling Encryption.
Bandwidth (bps) = 265 * (Number of IP phones and gateways in the branch)
Equation 1B: Recommended Bandwidth Needed for SIP Control Traffic without Signaling Encryption.
Bandwidth (bps) = 538 * (Number of IP phones and gateways in the branch)
If a site features a mix of SCCP and SIP endpoints, the two equations above should be employed separately for the quantity of each type of phone used, and the results added.
If encryption is configured, the recommended bandwidth is affected because encryption increases the size of signaling packets exchanged between Unified CM and the endpoints. The following formula takes into account the impact of signaling encryption:
Equation 2A: Recommended Bandwidth Needed for SCCP Control Traffic with Signaling Encryption.
Bandwidth with signaling encryption (bps) = 415 * (Number of IP phones and gateways in the branch)
Equation 2B: Recommended Bandwidth Needed for SIP Control Traffic with Signaling Encryption.
Bandwidth with signaling encryption (bps) = 619 * (Number of IP phones and gateways in the branch)
This information was taken from the SRND 6.x as refered to in an earlier post which may require CCO login.
Branch Office Size (Number of IP Phones and Gateways) Recommended Bandwidth for SCCP Control Traffic (no encryption) Recommended Bandwidth for SCCP Control Traffic (with encryption) Recommended Bandwidth for SIP Control Traffic (no encryption) Recommended Bandwidth for SIP Control Traffic (with encryption)
One word advice you need to cautious when you are configuring shared-lines and broadcast hunt-group in remote office with centralised CUCM.
The reason is that this will considerably increase your voice signalling requirements. For example you have a broadcast hunt-group of 10 phones, these 10 phones will be signalled simulateously, the same applies to shared lines.
Erlang
Erlang is used to work out the number of trunk require.
BHCA = Busy Hour Call Attempt = Average number of call made by each user every hour in mins
Average Call Duration e.g. 2 mins
Erlang = Busy Hour Traffic = The amount of call hour made in a given hour
Erlang = No. Users x BHCA x Average Call Duration (mins) / 60
E.g. No. Users = 100 BHCA = 2 Average Call Duration = 2 mins
BHT = 100 x 2 x 2 mins / 60 = 6.7 hours of call made continuously within a hour. This indicates that we need 7 channels to sustain all the calls.
Assuming each channel consumes 80kbps of bandwidth
Total bandwidth (kbps) = 7 x 80kbps = 560kbps.
Media
CUCM Locations-Based CAC Bandwidth Values
You can find this information in CUCM Admin > System > Locations > Add Location > Help > About This Page
- G.711 call uses 80 kbps
- G.722 call uses 80 kbps
- G.723 call uses 24 kbps
- G.728 call uses 16 kbps
- G.729 call uses 24 kbps
- GSM call uses 29 kbps
- Wideband call uses 272 kbps
Gatekeeper-Based CAC Bandwidth Values
A “debug h225 asn1” will reveal “bandWidth 1280” in the ARQ. Note well, H225 debugs tack a 0 (zero) on the end of your values. Therefore, 128 kbps (G.711) will show 1280 and 16 kbps (G.729) will show 160.
- G.711 call uses 128 kbps
- G.729 call uses 16 kbps
QoS Bandwidth Values
Best document is the QoS SRND, page 33.
[L2 (G.729 = 20 kbps; G.711 = 80 kbps) + L3] * 8 * 50 = Value per call
- 802.1Q Ethernet adds (up to) 32 bytes of Layer 2 overhead.
- Point-to-point protocol (PPP) adds 12 bytes of Layer 2 overhead.
- Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead.
- Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.
RSVP Bandwidth Values
A “debug ip rsvp messages” will show the worst-case scenario bandwidth value used. Look for “start requesting XX kbps” in the output.
The ip rsvp bandwidth value should be equal to (x-1 calls at normal scenario + 1 call at worst case scenario). For example, two G.729 calls would be calculated as 24 + 40 = 64 kbps. In the example below, I have configured RSVP for one G.729 calls (1-1 calls at normal scenario + 1 call at worst-case scenario of 40 kbps)
- G.711 call uses 96 kbps as a 10 ms worst-case scenario.
- G.729 call uses 40 kbps as a 10 ms worst-case scenario.
At 10ms, the voice payload size will be half at 20ms. Hence G.711 at 10ms = 160/2 = 80 bytes and G.729 at 10ms = 20/2 = 10 bytes
Including layer 3 overhead of 40 bytes. G.711 = 120 bytes and G.729 = 50 bytes
G.729 bandwidth = 8kbps x 50 / 10 = 40kbps
G.711 bandwidth = 64kbps x 120 / 80 = 96kbps
Examples
Scenario » Voice Bandwidth( Layer 2 Overhead), [compress header ip rtp] sampling rate - 20ms:
20 bytes ←- G.729 media payload>
2 bytes ←- L3/L4 Header Compressed with cRTP (Normal sizes WITHOUT compression are 20 bytes for IP, 8 bytes for UDP, 12 bytes for RTP: for a total of 40 bytes for the L3/L4 Header)>
+4 bytes ←- frame relay header
-------------
= 26 bytes *8 bits per byte ←- convert to kilobits>
-------------
= 208 bits *50 ←- based on 50 pps>
-------------
10,400 bits per second or 10.4kbps per G729 call
(round up to 11Kbps for QoS – Always want to have slightly more bandwidth - rather than less bandwidth reserved!)
Scenario » Voice Bandwidth( Layer 2 Overhead), NO cRTP compression, sampling rate - 20ms:
20 bytes ←- G.729 media payload>
40 bytes ←- L3/L4 Header Non-Compressed (20 bytes for IP, 8 bytes for UDP, 12 bytes for RTP: for a total of 40 bytes for the L3/L4 Header)>
+4 bytes ←- frame relay header
-------------
= 64 bytes *8 bits per byte ←- convert to kilobits>
-------------
= 512 bits *50 ←- based on 50 pps>
-------------
25,600 bits per second or 25.6kbps per G729 call (round up to 26Kbps for QoS)
Scenario » Voice Bandwidth( Layer 2 Overhead), NO cRTP compression, ADD Frame Relay Fragmentation (FRF.12), sampling rate - 20ms:
20 bytes ←- G.729 media payload>
40 bytes ←- L3/L4 Header Non-Compressed (20 bytes for IP, 8 bytes for UDP, 12 bytes for RTP: for a total of 40 bytes for the L3/L4 Header)>
+8 bytes ←- frame relay header with FRF.12 compression
-------------
= 68 bytes *8 bits per byte ←- convert to kilobits>
-------------
= 544 bits *50 ←- based on 50 pps>
-------------
27,200 bits per second or 27.2kbps per G729 call (round up to 28Kbps for QoS)
Scenario » Voice Bandwidth( Layer 2 Overhead), NO cRTP compression, ADD use MLPPP over Frame Relay, (No FRF.12 - not compatible with MLPPP anyhow), sampling rate - 20ms:
20 bytes ←- G.729 media payload>
40 bytes ←- L3/L4 Header Non-Compressed (20 bytes for IP, 8 bytes for UDP, 12 bytes for RTP: for a total of 40 bytes for the L3/L4 Header)>
13 bytes ←- MLPPP header +8 bytes ←- frame relay header
-------------
= 77 bytes *8 bits per byte ←- convert to kilobits>
-------------
= 616 bits *50 ←- based on 50 pps>
-------------
30,800 bits per second or 30.8kbps per G729 call (round up to 31Kbps for QoS)