The question is specifically regarding the amount on signalling bandwidth required not the amount of bandwidth required for either G.711 or G.729 Calls.
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.
Equation 1 and all other formulas within this section include a 25% over-provisioning factor. Control traffic has a bursty nature, with peaks of high activity followed by periods of low activity. For this reason, assigning just the minimum bandwidth required to a control traffic queue can result in undesired effects such as buffering delays and, potentially, packet drops during periods of high activity. The default queue depth for a Class-Based Weighted Fair Queuing (CBWFQ) queue in Cisco IOS equals 64 packets. The bandwidth assigned to this queue determines its servicing rate. Assuming that the bandwidth configured is the average bandwidth consumed by this type of traffic, it is clear that, during the periods of high activity, the servicing rate will not be sufficient to "drain" all the incoming packets out of the queue, thus causing them to be buffered. Note that, if the 64-packet limit is reached, any subsequent packets are either assigned to the best-effort queue or are dropped. It is therefore advisable to introduce this 25% over-provisioning factor to absorb and smooth the variations in the traffic pattern and to minimize the risk of a temporary buffer overrun. This is equivalent to increasing the servicing rate of the queue.
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.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...