本节书摘来异步社区《实施Cisco统一通信管理器（CIPT2）》一书中的第1章，第1.4节，作者： 【美】Chris Olsen 译者： 刘丹宁, CCIE#19920 , 卢铭 , 陈国辉 , 田果 责编： 傅道坤，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.4 带宽方面面临的挑战
实施Cisco统一通信管理器（CIPT2）
在多站点部署环境中，站点间是通过IP WAN（有时也通过MAN，如城域以太网）相互连接的。而WAN链路的带宽是比较有限的，而且往往价格昂贵。因此，我们的目标是希望能够将可用带宽尽量高效地加以利用。因此，我们可以使用内容过滤、防火墙功能和访问控制列表（ACL）来过滤掉IP WAN链路上的那些不必要的流量。另外，也可以考虑通过优化带宽来实现IP WAN网络的提速。因为只要网络中出现了拥塞的情况，就必然会影响网络的性能，解决的方法是在网络中部署QoS技术。
对于Cisco音频数据包来说，语音流是连续而且能够预测的。一般来说，为了有效利用带宽，在WAN链路上往往使用G.729编码。相比之下G.711音频编码需要64 kbit/s，而将G.711语音采样信息封装进IP/UDP/RTP包头需要16 kbit/s，另外还要加上前面封装的二层头部信息。
语音每20毫秒采样一次，因此每秒采样50个数据包（pps）。IP头部是20字节，UDP头部是8字节，RTP头部是12字节。这一共40字节的头部信息必须转换成比特数来计算数据包头部的速率。由于1字节是8比特，因此40字节乘以8等于320比特。这320比特以每秒50次的速率进行发送，也就是每20毫秒发送一次（1毫秒是0.001秒，20除以1000等于0.02）。因此：
0.02×50 = 1秒
320×50 = 16000 bit/s，或写作16 kbit/s1
注释：
上述计算中并没有考虑二层的封装。读者如果想要深入了解相关信息，可以阅读QoS Solution Reference Network Design（SRND）（http://www.cisco.com/go/srnd）或《Cisco QOS Exam Certification Guide,Second Edition》（Cisco Press，2004）。
相比于数据应用，语音数据包对带宽的利用可谓温和。数据应用会占满以太网数据帧的最大传输单元（MTU）（1518字节或9216字节，后者是启用了巨型帧的情况）。相形之下，语音数据包则比较小巧（当采样率为默认的20毫秒时，G.729为60字节，G.711为200字节）。
在图1-2中，会议桥被部署在了主站点中，远端站点则没有部署会议桥。如果远端站点中的3台IP电话需要加入电话会议，它们的RTP流就会穿越WAN网络发送给会议桥。然后，会议桥会将接收到的音频（无论使用软件还是硬件）流量混合在一起，通过IP WAN将3个相互独立的单播音频流发回给IP电话。会议桥会从发送给接收方的独立RTP流量中清除掉接收方的语音，这样就不会由于WAN链路传输过程以及混合RTP音频流过程导致的延迟，而使用户听到回声了。
集中式部署的会议资源会影响到带宽、延迟以及语音网络的性能。每个G.711 RTP数据流都需要80 kbit/s（还要算上二层的头部信息），于是这次语音会议总共需要消耗240 kbit/s的IP WAN带宽。倘若会议桥没有部署在IP WAN的另一端，那么流量就不需要穿越WAN链路，也就不会消耗这些带宽。如果CUCM中远端站点的地区参数（Region）配置为与主站点之间使用G.729编码，那么CUCM中的软件会议资源就无法为其混合音频会话了。为了实现G.729音频会议，就需要使用语音网关中的硬件会议资源或硬件编码转换资源。但本地的媒体资源可以消除这一需求。所有位于中心站点的媒体资源（MOH[音乐保持]、信号器（Annuncicator）、会议桥、视频电话会议和MTP）都会面临类似的带宽、延迟和资源耗尽的问题。
