The question of how much bandwidth does a call consume is something that has occupied the minds of many “collaboration” engineers over the years and specifically is something that you should be aware of if you plan on sitting the CCIE Collaboration lab exam. I’m going to tell you how to do it without referencing any resources.
To set the scene, I want to police Voice/RTP traffic from a phone in my Headquarters office. We shall call this HQ Phone 2.
The policer will be applied on the switchport of HQ Phone 2 (ingress). I am using a 3560X switch.
The details of the policer are as follows: we will assume that conforming packets are all RTP packets for 1 g722 call. Any traffic above and beyond what is needed by 1 call is going to be non-conforming and is subject to an “exceed” action within the policer. The conforming action of the policer is to set the DSCP to the PHB of Expedited Forwarding (EF) and transmit. The exceed action of the policer is to drop packets.
Let’s look at our configuration:
class-map match-all voice match ip dscp ef <<< Voice packets from the phones registered to UCM ! policy-map phone class voice set ip dscp ef police 87500 8000 exceed-action drop ! interface GigabitEthernet0/12 description HQ PHONE 2 switchport access vlan X switchport mode access switchport voice vlan Y service-policy input phone
We have gone with 87.5kbps for 1 g722 call (note that when you specify the value in the policer it is in bits per second). Using the per call bandwidth consumption document we have a value of 87.2kbps for 1 g711/g722 call over Ethernet with 802.1Q headers. You can only apply the policer in increments of 500bit/sec so 87200 would be rounded down to 87000 hence we have rounded up to 87500. NEVER ROUND DOWN when the exceed action is DROP!! We’ll come to that later.
And by the way, we don’t need to trust DSCP when we have a matching class within the service policy. The service policy determines the markings (using either trust or set).
Now it is time to test.
I have an active call from HQ Phone 2 to HQ Phone 1. The traffic from HQ Phone 2 is subject to the policer. So I am looking at the Call Stats on HQ Phone 1 (a 7965 phone – you can simply press the “?” button twice when you have an active call in order to access these stats).
Let’s take a look at those stats:
Not very good! Bearing in mind that the two phones in question are connected to the same Gigabit Ethernet switch, we have quite substantial packet loss. Take a look at the MOS score which provides an indication of call quality. We are at 3.29/5 when we should be way over 4/5. The reason we are seeing packet loss is down to the fact that we are dropping non-conforming. In other words one g711u call over Ethernet/802.1Q is actually consuming more than 87.5kbps.
If you change your policer and increase the policed bandwidth in increments of 500 bits/second (you can do this whilst the call is active) then you will see the rate of Lost packets on the destination phone decline and eventually come to a complete stop.
In my environment (g722/711 over Ethernet with 802.1Q headers) the minimum policed value that yields no packet loss is 90.5kbps. Here is what was done on the switch:
HQSW(config)#policy-map phone HQSW(config-pmap)# class voice HQSW(config-pmap-c)#police 88000 8000 exc drop HQSW(config-pmap-c)#police 88500 8000 exc drop HQSW(config-pmap-c)#police 89000 8000 exc drop HQSW(config-pmap-c)#police 89500 8000 exc drop HQSW(config-pmap-c)#police 90000 8000 exc drop HQSW(config-pmap-c)#police 90500 8000 exc drop ! 0 packet loss
Vik Malhi, CCIE#13890
Facebook: https://www.facebook.com/VikMalhi
Twitter: @vikmalhi
www.collabcert.com
nice post, Vik.
In my lab i’ve tested with no policer and one G711 call was consuming 89500bps when looking at port level with load-interval set to 30sec. That should also contain signalling as well.
The only question that bothering me and i’ve seen many people are asking about it , is x-amount of calls policer.
so if we want to allow 5 G711 calls for example , do we need to do the same calculations multiplied by 5 ?
The bothering part is that how it can be possible to have at a single point of time voice traffic coming from a single port where phone is connected for more than 1 call ?
If you put call on hold to make a second call, voice traffic will still be limited to one active call , since first call is inactive, no rtp packets are being sent/received.
Could you clarify it ?
Built-in bridge for barge = 3 calls from phone
i know built-in bridge would do this. I was referring w/o any bridge
@Nizami
BIB is an obvious valid reason, but then the next logical question is: When is the BIB used? Vik mentioned barge, and another example is media forking for Media Sense call recording.
I also like the fact that you’re thinking about signaling too. This is however handled by a different class of traffic, but it’s good that you mentioned it. You wouldn’t want to police all traffic on the port to just barely cover the media and then all of your call signaling is dropped.
Actually, speaking of barely covering the traffic, I would argue that one shouldn’t engineer to the minimum standards. If the requirement is for 3 calls worth of bandwidth, and each call is ~93kbps, then wouldn’t any value between ~280kbs and ~370kbps equally allow 3 calls, while penalizing the sender if a fourth call’s bandwidth were to hit the port? In that sense, including a little overhead, say 5%, is probably not a bad idea. This ensures your design will not drop packets accidentally, and at the same time, it protects your network from a flood of unwanted traffic.
@Vik
Great post you’ve put together here Vik. It certainly provokes my inner geek.
The Cisco Enterprise Qos SRND does have a table of voice call bandwidth consumption, including layer 2 overhead, and it lists 93Kbps as the suggested value for G711 @ 20ms (aka 50 packets per second). How they arrived at that value can be understood by reversing the calculations.
93,000 bits per Second / 8 bits in a Byte = 11,625 Bytes per Second
11,625 Bytes per Second / 50 Packets per Second = 232.5 Bytes per Packet
232.5 Bytes per Packet – the combined RTP/UDP/IP Headers of 40 Bytes = 192.5 Bytes per Packet
192.5 Bytes per Packet – the 160 Bytes in the 20ms of G711 payload = 32.5 Bytes left over for Ethernet.
Why they rounded down, I’m not certain. More importantly, they have accounted for CRC in that calculation, because there’s no way you arrive at 32 Bytes without doing so.
The link you provided in your article is stating that the Ethernet frame (including CRC of 4 Bytes) is only 18 Bytes. The wording is confusing here, but 18 Bytes is not the correct size if you’re including the 4 Byte CRC. We see more on that in a moment. For now, let’s reverse this document’s claim that Ethernet BW is 87.2Kbps.
87,200 bits per Second / 8 bits in a Byte = 10,900 Bytes per Second
10,900 Bytes per Second / 50 Packets per Second = 218 Bytes per Packet
218 Bytes per Packet – the combined RTP/UDP/IP Headers of 40 Bytes = 178 Bytes per Packet
178 Bytes per Packet – the 160 Bytes in the 20ms of G711 payload = 18 Bytes left over for Ethernet.
We can see then, that in the 87.2Kbps calculation, CRC is not being considered.
We should now see that there is a discrepancy about the Ethernet frame header size one should use to calculate bandwidth (18 vs 32). So, I took a closer look…
By the way, the Cisco Voice Codec Bandwidth Calculator (registration required) also states the same 87.2Kbps.
I was wondering how could an Ethernet frame w/ dot1q be 32 Bytes? According to the breakdown of the Ethernet frame structure, we can see that a Layer 2, a frame without CRC is 18 Bytes, with CRC it’s 22 Bytes and at Layer 1 (where by the way, it is referred to as an Ethernet Packet) it’s 26 Bytes without CRC and 30 Bytes w/ CRC. We’re still missing 2 Bytes that the QoS SRND is considering. Well, actuall, if you go with my above mentioned suggestion for a small 5% buffer: 5% of 30 Bytes is 1.5 Bytes, and rounding up gives us 32 Bytes!
But I still wanted to go deeper…
If we look at the end of the Ethernet frame/packet structure, there are 12 Bytes that don’t seem to carry any data. This is called the Interpacket Gap, and is required idle time on the wire to reduce/prevent collisions. It should also be noted that 12 Bytes is for FastEthernet, whereas GigabitEthernet has a requirement of only 8 Bytes. It doesn’t seem like anyone is considering this dead period on the wire, which is essentially BW you need to account for. That’s what I thought until I found this nice little online VoIP Bandwidth Calculator. Once you adjust the knobs for g711u @ 20ms of Ethernet w/ dot1q, the calculator tells you that 96.8Kbps is required for a single call. Let’ reverse it!
96,800 bits per Second / 8 bits in a Byte = 12,100 Bytes per Second
12,100 Bytes per Second / 50 Packets per Second = 242 Bytes per Packet
242 Bytes per Packet – the combined RTP/UDP/IP Headers of 40 Bytes = 202 Bytes per Packet
202 Bytes per Packet – the 160 Bytes in the 20ms of G711 payload = 42 Bytes left over for Ethernet.
42 Bytes – 30 Bytes of Ethernet w/ CRC at Layer 1 = 12 Bytes. Hey! That’s the 12 Byte Interpacket Gap for FastEthernet!
Of course, that calculator doesn’t allow me to select GigabitEthernet to adjust to 8 Bytes for Interpacket Gap, which if it did my calculation would be 95.2Kbps. Whose using that value?
In my opinion, that’s enough variance in researching network design to make me provision in a little overhead. If CRC wasn’t turned on today, bu could be in the future, or if access ports were 100Mbps today but changed to 1Gbps in the future, should I have to rewrite my QoS design and change the switch configurations on all of my switches?
Let me know if I made a mistake in my calculations, and thanks for posting on such an interesting topic! Please keep up the excellent work Vik!
nice post and good replies too. I have the same question as Nizami i.e. do you have to multiply it by the number of calls??
according to cisco medianet Qos design 4
“the VoIP and signaling traffic from the VVLAN can be policed to drop at 128 kbps and 32 kbps, respectively (as any excessive traffic matching this criteria would be indicative of network abuse)” which made me feel that this value is regardless of the number of calls on that port.
would be great if Vik or anyone else can do the same testing with multiple calls.
many thanks
VOIP at 128k and signaling at 32k are recommended values but they are conservative. It would be very difficult to generate 32kbps of signaling traffic from a single phone. 128k is for a single g711/g722 call which is very conservative too. It is best to be conservative as policing to a higher-than-actual value is better than policing to a lower-than-actual value.
In a lab environment you should just answer the task in front of you. So if you were asked to police traffic from a phone to 3 calls I would personally use 93kbps x 3 calls as my answer (assuming I can use g711/g722 as the codec). This may or may not make sense in real life as you may not have a need to police traffic from a phone to 3 calls but rather 1 call.
@Vik
great article
I’m wonder if in SB and SC where phones are attached to ESG card upper callculations for G.711 calls are identical ?