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 ***
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.
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?
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.
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!
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.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...