Question on Active Calls and SIP Bandwidth

[Jason Amick]

My company has a 10Mbps SIP trunk to the ITSP and would like to know how many concurrent calls we could take over that trunk before maxing it out. The SIP trunk is connected to a cisco 2921 and the codec we receive from the carrier (windstream) is G729.  By doing the math I would say if the full payload size for a g729 call is ~32Kbps so 10000/32 = 312.5.  We should be able to handle 312 concurrent calls without utilizing 100% of the circuit correct? My problem is the math does not add up when I do a "show sip-ua calls sum" see results below.

Total SIP call legs:233, User Agent Client:115, User Agent Server:118

Say I run this command on the gateway and if I am correct I would divide the total SIP call legs of 233 by 2 and get 116.5 total Active SIP calls, but when I look in solarwinds which provides the statistics on the circuit it would say 78% utilized but in theory I am not even hitting 50% of the concurrent calls supported.  I dont think its an issue on the solarwinds side becuase if I do a show int on the gateway my rxload is 188/255 which seems to be accurate to what solarwinds is responding with.  Am I possibly not running the correct command to see how many active SIP calls are in progress? Thanks for any additional help you can provide.

[Jonathan Schulenberg]

First off, you would be better off asking the ITSP how many concurrent call paths you have paid for. That is how nearly all SIP trunks are purchased.

Second the voice codec calculator tool can answer the question of how much bandwidth each call would consume.

https://tools.cisco.com/Support/VBC/do/CodecCalc1.do

Also, don't forget that some scenarios, namely a call on hold or in IVR, will re-renegotiate the call to g.711 instead of g.729. This will take way more bandwidth.

I don't see a problem with the command that you're using at first glance. Assuming that circuit isn't accidentally being chosen for other traffic, it likely just a mix of codecs. If you think that isn't the case then probably the best approach would be to setup a netflow export of the interface and see what solar winds shows for traffic. 

[Jason Amick]

Jonathan:

Thanks for the information I will run this question by our ITSP and see what I get back.  When I run the command sho sip-ua calls | inc Negotiated Codec I dont see any entry at anytime specifying that we have negotiated g.711 all g729r8.   Thanks!!

DR-2921-SIP-VGW#sho sip-ua calls | inc Negotiated Codec
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)
     Negotiated Codec         : g729r8 (20 bytes)

[Dennis Mink]

Jason,

as a matter of interest, how are you sampling the circuit stats using solarwinds?  are you using an SNMP OID and if so, which one?

sorry, I re-read your post and assume you use out of the box solarwinds, interface utilisation right?

cheers

[Mohammed al Baqari]

Hi,

Your codec BW calc is correct where G729 consumes 32 - 33 kbps per call over ethernet with 20msec payload.

Now, the max number of concurrent calls depends on your ITSP. You need to accommodate for 5% signaling as per SRND which will get the theoretical number of concurrent call bit lower than 312. But not necessary the case as this can be controlled by ITSP. You need to check with ITSP about how many calls do they allow.

Now, regarding solarwinds, not sure where you are looking exactly but solarwinds BW usage is based on configured bandwidth command on the interface versus the consumed bandwidth. Ideally, you interface should have bandwidth configured as 10 Mbps.

If you have netflow, can you check what traffic is passing over the SIP ethernet line? Ideally you should see calls and signaling only. But you might have a case of dynamic routing protocol updates or mulitcasting which is adding more bandwidth usage to the link. Netflow will help you to see what is causing the link to reach 78%.

[Jason Amick]

Thanks for all the information guys, I did reach out to our account team and the max call paths we have are set to 240.  I was always under the assumption it was strictly based on bandwidth and not regulated by call paths.  So I guess my question for all of you now would be if we are trying to do an upgrade on our SIP trunk to increase the call paths then how do we know what to set the bandwidth on the interface to?  Right now I have the bw set to 10000 with 240 call paths. 240 *32 = 7680 which is below the threshold of 10Mbps.  Would if we upgraded to 400 call paths which would be more than the configured 10Mbps?  I would assume on the carrier side they would have to adjust the bandwidth on the circuit as well as upgrade the number of call paths.  Sorry I was always under the impression the SIP trunk was based on BW alone.