Lync Server 2010所需媒体网络流量带宽详解和计算

如果在组织内部部署Lync Server 2010，那么最大的优势就是解决了组织内部的即时通讯需求，为什么这么说？因为纵观现在微软所推行的商业智能应用平台，可以非常直观的了解到实际上整个微软商业平台就是由Lync Server、Exchange Server以及SharePoint Server这三个解决方案来实现。Exchange Server主要用来实现企业的异步通讯，包括邮件、语音信箱、全球通讯簿等；Lync Server主要用来实现企业的即时通讯，包括在线文字聊天、语音会议、电话会议、视频会议、远程协助、远程演示等双方或多方的沟通；SharePoint Server主要实现的是企业信息、资源的融合，包括门户网站、工作流程、协同工作、企业搜索以及企业内容管理等。三大解决方案各施其职，共同构建企业的商业信息平台。

上面的内容有点偏题了，今天我们主要是来看下很多客户所关心的网络流量需求，对于一种沟通的方式我们不得不把网络流量需求记作沟通成本。Lync Server媒体流量的计算和评估我们可以根据不同的开销进行分别计算，主要将网络流量需求分为三类：音频编码器、视频分辨率及码率、流活动级别。我们下面就先来看下Lync Server的音频网络流量需求，在音频编码器中主要以下几种编码器：

音频编解码器	方案	音频负载比特率 (KBPS)	仅限于带宽音频负载和 IP 标头 (Kbps)	带宽音频负载、IP 标头、UDP、RTP 和 SRTP (Kbps)	带宽音频负载、IP 标头、UDP、RTP、SRTP 和前向纠错 (Kbps)
RTAudio 宽带	对等	29.0	45.0	57.0	86.0
RTAudio 窄带	对等，PSTN	11.8	27.8	39.8	51.6
G.722	会议	64.0	80.0	95.6	159.6
G.711	PSTN	64.0	80.0	92.0	156.0
Siren	会议	16.0	32.0	47.6	63.6

音频编码器指的是音频类型，比如PC到PC、PC到电话、PC到PC会议、PC到电话会议等等。需要说明的是RTAudio宽带和窄带这两种编码器，并不是我们通常所见的PC到PC语音编码器，而是微软针对Lync Server专门研发的。简单的介绍下RTAudio吧，这是一种针对基于IP的实时双向通讯语音程序专用的的高级语音编码，是微软首选的实时语音编码器，拥有性能、兼容性好、速率控制、延迟低以及前向错误纠正等功能。其中的前向错误纠正FEC需要额外的流量来实现，可以帮助维护音频流的质量。上表中的带宽数值基于 Siren 和 G.722 的 20 毫秒数据分包（每秒 50 个数据包），其中包含其他安全实时传输协议 (SRTP) 开销（在会议方案中），并假定流是 100% 活动的。 看完了音频我们再来看看视频，对于视频，只有一种解码器，那就是RTVideo。所需要、耗费的网络带宽取决于分辨率、编码率以及帧速率。每种分辨率都有两个相关的比特率： 最大负载比特率 Lync 2010 将此比特率用于该分辨率所能支持的最大帧速率的分辨率。此值可提供最高质量和最高帧速率的视频，因此十分重要。
最小负载比特率 Lync 2010 将此比特率用于大约每秒 1 帧的分辨率。通过此值可以了解在最大比特率不可用或不实际时，可能适用的最低值，因此十分重要。部分用户可能无法接受每秒 1 帧的视频体验，因此考虑使用这些比特率时应十分谨慎。
在了解最大负载比特率和最小负载比特率后，我们再来看下各种分辨率下的这两个值的需求：

分辨率	最大视频负载比特率 (Kbps)	最小视频负载比特率 (Kbps)
主视频 CIF	250	50
主视频 VGA	600	350
主视频 HD	1500	800
全景视频	350	50

在标准情况下，Lync的所有客户端节点在开启音视频会议时不会持续的传输数据包，根据场景的不同有所差异。 在对等方案中： 仅当用户通话时终结点才发送音频流。
参与双方都会接收到音频流。
如果使用视频，则双方终结点都会在整个呼叫过程中发送和接收视频流。
在会议方案中： 仅当用户通话时终结点才发送音频流。
所有参与者都会接收到音频流。
如果使用视频，则一次只有两个终结点发送视频流（活动讲话人和上一个活动讲话人）。
如果使用视频，则所有参与者都会接收到视频流。
也就是在标准环境，不使用第三方for Lync的软硬件设备时，Lync最多同时显示一个参会者的视频图像，即讲话人。通过音频激活来切换到其他参会人。 下面我们看下微软给出的流活动级别表格：

方案	媒体	估计流活动 (%)
对等会话	音频	61
对等会话	主视频 CIF	84
对等会话	主视频 VGA	83
对等会话	主视频 HD	80
对等会话	全景视频	74
会议	音频	43
会议	主视频 CIF	84
会议	主视频 VGA	83
会议	主视频 HD	80
会议	全景视频	74
PSTN	音频	65

这个流活动级别是微软估计出来的一个平均值，也就是说我们通过相应的媒体类型，乘以这个估算流活动就可以得到大概的流量耗费。我们下面举个例子： 在对等会话方案中使用RTAudio宽带编码器，在不使用FEC的情况下，即：57.0*61%+5=39.77Kbps；
同样在对等会话方案中使用RTAudio宽带编码器，在使用FEC的情况下，即：86.0*61%+5=57.46Kbps。
可能这里大家就蒙了，这个"5Kbps"流量耗费又是怎么回事？除音频和视频媒体的实时传输协议 (RTP) 流量所需的带宽之外，实时传输控制协议 (即RTCP) 也需要带宽。RTCP 用于报告 RTP 流的统计信息和带外控制。我们在做规划时，可以直接参考下表中的带宽数值规划 RTCP 流量。这些值代表用于 RTCP 的最大带宽，并且因控制数据不同，音频流和视频流的这些值也有所不同。

媒体	RTCP 最大带宽 (Kbps)
音频	5
视频	10

这里应该就很清楚这个5Kbps是怎么回事了吧，同理，对于视频的话就需要额外加10Kbps的流量作为评估容量的参考值。其实讲到这里相信各位朋友就应该会计算了吧，但这些其实微软早就为我们准备好了，并且分为使用FEC、不使用FEC以及经典值。 这里还是给大家明确说下不使用FEC最大流带宽和使用FEC最大流带宽这两个值的重要性： 不使用 FEC 的最大带宽 流将使用的最大带宽，包括不使用 FEC 的方案中的典型流活动和使用的典型编解码器。这是流处于 100% 活动状态，且没有因丢失数据包而触发使用 FEC 时的带宽。它对于计算为允许给定的方案使用编解码器而必须分配的带宽数量而言，十分重要。
使用 FEC 的最大带宽 流使用的最大带宽，包括使用 FEC 的方案中的典型流活动和使用的典型编解码器。这是流处于 100% 活动状态，且因丢失数据包而触发使用 FEC 以提高质量时的带宽。这对于计算为允许给定的方案使用编解码器，并且允许在数据包丢失的条件下使用 FEC 来维护质量而必须分配的带宽数量而言，十分重要。
然后再说下经典值：这是流使用的平均带宽，包括方案中的典型流活动和使用的典型编解码器。此带宽可用于估计给定时间内媒体流量使用的带宽量，但不应用于容量规划，因为活动级别高于平均水平时，个别呼叫会超过该值。经典值的计算方式就是我上面给大家计算的方式，这里就不再提了直接看下表。 对等会话的音频/视频容量规划

媒体	编解码器	典型流带宽(Kbps)	不使用FEC的最大流带宽	使用FEC的最大流带宽
音频	RTAudio宽带	39.8	62	91
音频	RTAudio窄带	29.3	44.8	56.6
主视频 CIF	RTVideo	220	260	不适用
主视频 VGA	RTVideo	508	610	不适用
主视频 HD	RTVideo	1210	1510	不适用
全景视频	RTVideo	269	360	不适用

会议的音频/视频容量规划

媒体	典型的编解码器	典型流带宽(Kbps)	不使用FEC的最大流带宽	使用FEC的最大流带宽
音频	G.722	46.1	100.6	164.6
音频	Siren	25.5	52.6	68.6
主视频 CIF	RTVideo	220	260	不适用
主视频 VGA	RTVideo	508	610	不适用
全景视频	RTVideo	269	360	不适用

PSTN 的音频容量规划

媒体	典型的编解码器	典型流带宽(Kbps)	不使用FEC的最大流带宽	使用FEC的最大流带宽
音频	G.711	64.8	97	161
音频	RTAudio 窄带	30.9	44.8	56.6

上面三个表中无论是经典值还是不使用FEC的最大流带宽和使用FEC最大流带宽，均已经包含了RTCP所需的流量，音频已经包含RTCP最大流量的5Kbps、视频包含RTCP最大流量的10Kbps。 我们可以根据以上的Lync Server所需的媒体网络流量带宽来评估计算生产环境中所需要的网络连接速率以及规划用户量、硬件设备等。好了，今天就讲到这里，感谢各位朋友的捧场！本文出自 “Reinember” 博客，谢绝转载！