Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VoIP capacity planning formulas...

Why exactly does Cisco recommend an additional 5% of overhead be added to the final bandwidth per call value that results from using their VoIP bandwidth formula (below)?  It seems arbitrary.  If anyone can explain the reasoning in more detail, I'd appreciate it.  Thank you.

____________________________

values in parentheses () below represented in Bytes

vPPS (voice-Packets-Per-Second) = codec_bit_rate/(voice_payload x 8)

VoIP bps_rate/call = (IP/UDP/RTP_header + voice_payload + L2_header + L2_flag) x 8 x vPPS

*** add 5% overhead for signaling (in bits) for TOTAL rate/call value ***

____________________________

Kevin

Everyone's tags (3)
6 REPLIES
VIP Super Bronze

Re: VoIP capacity planning formulas...

Because the calculator does not include the SIP or SCCP call signaling traffic; only the RTP with overhead bandwidth needs. I try to use 10% if using SIP because the packets are larger than SCCP but that's my own personal guideline.

New Member

Re: VoIP capacity planning formulas...

Thanks for the response, Jonathon.  Not quite clear on what you mean by "; only the RTP with overhead bandwidth needs".  Should I take it that SIP & SCCP associated signaling can't be measured in any finite way?  Is SIP or SCCP signaling analagous to H.323 signaling?

Kevin

VIP Super Bronze

Re: VoIP capacity planning formulas...

The audio payload itself is only part of the total packet size. By the time you add lower-layer protocol headers (RTP, UDP, IP, Ethernet) there is a fair amount of overhead. This is what the bandwidth calculator helps you determine.

SIP and SCCP signaling is separate from this and is analogous to H.323 although that is typically reserved for gateways in Cisco deployments. Every time you press a button on your phone, the phone rings, or any other event occurs a SCCP or SIP packet is generated in addition to the audio. The guideline to account for these signaling packets is 5% of a G711-based audio call bandwidth.

New Member

Re: VoIP capacity planning formulas...

When determining bandwidth need, can I assume 5% addn'l overhead when dealing with all G7xx codecs, not just G711?  Also, in your 1st reply back did you mean that SIP & SCCP signaling only comes into play when RTP is used to carry the actual audio from one IP-endpoint to another?

Your comments have been very helpful, Jonathon.  Thanks!

Kevin

VIP Super Bronze

Re: VoIP capacity planning formulas...

can I assume 5% addn'l overhead when dealing with all G7xx codecs, not just G711

Yes. I should have phrased it differently as I meant you should make your 5% calculation based on the quantity of calls at a 64kbps audio codec. I.E. do not adjust your signaling bandwidth allocation to be less just because you use G.729 or another lower-bandwidth codec.

Also, in your 1st reply back did you mean that SIP & SCCP signaling only comes into play when RTP is used to carry the actual audio from one IP-endpoint to another?

Every device has some type of signaling involved. Cisco IP phones are capable of using SCCP or SIP as their signaling protocol to CUCM. They use this signaling protocol to register, get settings, and make calls. Phones for all practicle purposes are just puppets; CUCM controls every action the phone makes through SCCP/SIP. RTP on the other hand is only used to carry audio between call participants. When you dial a number on your phone, it sends SCCP or SIP signaling packets to CUCM for every button you press. CUCM uses the signaling protocol to instruct each phone how to react (e.g. stop playing dial tone, ring, open UDP ports to receive/transmit on, show caller ID, etc). The phone has no intelligence or knowledge about the dial plan; all of that exists in CUCM.

New Member

Re: VoIP capacity planning formulas...

Appreciate you taking the time, Jonathan.  Thanks for clarifying things.

Enjoy the rest of your weekend!

Kevin

2916
Views
5
Helpful
6
Replies
CreatePlease login to create content