随着全球经济的不断发展, 互联网不断融入人们的生活, 视频通话越来越受人们青睐, 多方音视频通信成为一种很受欢迎的通信方式. 在各通信系统的媒体流传输中, 存在两种网络传输方式: 一种是星状网络拓扑, 另一种是网状网络拓扑. 但现有的通信方案往往只选取其中一种方法作为媒体流传输方式, 没有充分融合两种方式的各自优势来提高系统对媒体流的处理能力.

实验室现有视频会议系统方案采用星状网络拓扑这种传统传输方式, 系统客户端采用WebRTC技术^[1]进行音视频处理, 服务端通过SIP信令集中模式对视频会议进行会议控制, 并运用WebRTC与SIP的转换网关实现双方互通, 使视频会议系统音视频通话质量有所保障, 同时能够更容易对接到IMS网络^[2], 满足融合通信的基本要求. 本系统虽然能够正常提供音视频通话, 但当会议组遇到网络拥塞或系统负载过重时, 系统本身无法改变媒体流转发方式, 更不能自适应调整媒体流控制方式, 使部分通话无法正常进行^[3].

本文通过对当前音视频通话方案所存在的问题进行研究与分析, 并基于实验室现有视频会议系统进行改进, 提出了一种多方通话动态控制技术, 充分运用会议组网络中星状拓扑和网状拓扑的各自优点, 一方面在网络通畅并且用户数量较低情况下, 发挥网状拓扑的便捷性, 减轻服务器压力; 另一方面当系统发生网络拥塞时, 充分利用星状拓扑中服务器集中收发媒体流的优势, 节省网络带宽并保持通话畅通.

1 相关技术介绍 1.1 SIP协议分析

SIP(会话初始化协议)是IETF提出的一种支持多媒体会话的信令控制协议, 在IP网络中以其简单、易扩展的特性被广泛应用, 具体工作流程如图1.

SIP采用文本编码方式, 其独立于传输层, 属于应用层控制协议, 主要由SIP服务器和SIP用户代理两个组件构成, SIP服务器包括代理服务器、注册服务器以及重定向服务器^[4]. 在消息会话过程中, 各系统以SDP(会话描述协议)传递消息内容, 各部分协同工作, 让会话更为流畅和高效^[5].

1.2 MCU简介

MCU全称为Multi Control Unit, 即多点控制单元, 主要功能为协调和控制多个终端间的音视频传输, 为用户提供群组会议服务. 如图2.

MCU将各终端的信息流同步分离, 分析并提取音视频数据和信令等信息, 然后将信息送入各模块进行处理, 完成相应的音视频混合与交换、路由选择和会议控制等过程, 最后将各会议场点所需的各种信息重新组合, 发送给各客户端.

1.3 会议系统网络拓扑结构

SIP会议系统模型^[6]分为松耦合模式和紧耦合模式. 在紧耦合模式中存在两种网络拓扑形式, 分别为网状拓扑和星状拓扑.

在一个全联通的网状网络中, 存在N*(N–1)个连接, 各端点之间相互连通能够直接进行数据通信, 如图3. 这种网络的优点在于各端点之间不需要媒体中继服务器进行媒体分发与管理, 即可实现多方通信. 但缺点在于无法为大型会议系统提供通信服务, 系统的音视频转码和混合在终端完成, 且随着网络中参与者的增加, 将大量消耗终端的CPU、内存以及带宽等资源.

星状网络最广泛的应用是通过一个多点控制单元集中整合各终端媒体流, 然后发送到每个端点, 如图4. 此类网络对于网络中任意客户端, 只需传输单个流, 节省了带宽并且减轻了CPU负载^[7]. 但当更多客户端进入会议后, 服务器将对更多路媒体流进行整合与转发, 大量消耗服务端资源, 因此服务器承载能力会成为此类网络扩展的瓶颈.

2 动态控制方法的设计与实现 2.1 系统总体结构设计

本系统采用SIP信令集中处理模式, 实现视频会议的会议控制功能, 并支持SIP和WebRTC两种类型客户端, 其中SIP客户端可直接连接会议服务器进行会话控制, 而WebRTC客户端在连接到WebRTC服务器后, 通过WebRTC与SIP转换网关实现双方会议控制信息的转换, 再与会议服务器进行交互^[8]. MCU主要用来控制终端媒体流收发, 建立流畅的会议通话. 系统总体结构如图5.

系统利用终端采集本地网络数据以及终端资源占用情况, 并对SIP消息进行扩展, 以扩展后的SIP消息为载体向会议控制服务器发送各终端数据.

SIP客户端直接与会议服务器进行连接, WebRTC客户端则需要经由网关转换信息后才能上传到会议服务器^[9].

会议服务器包含SIP通信控制器和动态控制器两部分, SIP通信控制器用来进行会议控制, 同时解析各终端数据, 并将其会话信息存入数据库中. 动态控制器用来对终端提供的数据进行计算和处理, 建立系统终端连接状态图, 并对各会议组成员进行网络和资源评估, 分析会议组媒体流控制方式的各种条件, 决定会议组媒体流由MCU进行集中管理还是通过各终端自行分发.

2.2 会议服务器设计

多方通话的动态控制技术以服务器为基础, 实现媒体流控制变换, 该系统的会议服务器由SIP通信控制器和动态控制器两部分组成, 图6为服务器总体架构图.

SIP通信控制器分为用户代理模块^[10]、注册服务模块、重定向服务模块和数据写入模块: 1) 用户代理模块, 主要作用是根据目标用户的位置信息将SIP信令代理转发给目标用户. 2) 注册服务模块, 实现对用户进行认证并登记用户的位置信息. 3) 重定向服务模块, 作用为向用户代理返回最新访问地址列表, 让用户代理与新的访问地址进行通信. 4) 数据写入模块, 作用是将客户端传来的SIP消息进行提取, 从中解析出SWIT CHINFO消息内容, 并存入数据库.

动态控制器包含数据读取模块、图分析模块和动态调整模块3部分: 1) 数据读取模块, 主要作用为提取数据库中存放的通话信息, 并传递给图分析模块. 2) 图分析模块, 将数据读取模块传来的信息分析处理, 进行系统会话连接图的还原操作, 掌握系统现存会话状态及各终端网络数据, 并结合终端CPU和内存资源使用状况, 采用基于带宽估计的拥塞检测方法实现对终端拥塞情况的计算与评估. 3) 动态调整模块, 根据终端网络状况以及MCU资源占用情况, 对系统现存会议组网络最终作出评估, 决策各会议组媒体流控制方式是否做出调整.

2.3 终端会议状态信息采集方案设计

多方通话动态控制技术通过终端向服务器发送各用户网络状况和资源占用情况等数据, 因此需要一种消息载体实现终端和服务器之间的数据传递. 针对以上问题, 系统对SIP消息进行扩展, 增加SWITCHINFO消息, 由终端每5 s采集数据, 通过SWITCHINFO消息为服务器传递实时数据.

SWITCHINFO消息内包含sip_id, conference_id, contact_points, conference_type, 和network_ condition五种数据. sip_id为各客户端在服务器中的唯一标识, conference_id 为多方通话中各会议唯一标识, contact_points 为各客户端媒体流分发时连接的所有端点, 内部数据存储为各连接端点的sip_id. conference_ type为通话类别, 此类别分为“focus”和“dispersion”两种, 根据客户端之间媒体流连接状况, 当终端检测到没有其他端点与自己连接时, 将conference_type赋值为“focus”, 代表该会议组利用MCU为每个客户端收发媒体流, 选择了集中控制的方式; 当检测本终端与若干通话终端有媒体流交互时, conference_type被赋值为“dispersion”, 表明该终端媒体流处理方式为基于网状网络的分散处理模式.

network_condition则包含了各端点网络状况及CPU、内存的使用情况, 此消息中所包含字符串较多, 由SIP通信服务器解析后会有以下参数存入数据库, 分别为max_bandwidth、time_interval、consumption_ send、consumption_receive、num_package、time_delay、cpu_alltime、cpu_freetime、ram_maxcapacity和ram_usedcapacity. 以上各参数会分别应用于图分析模块和动态调整模块中.

下面给出SWITCHINFO方法工作流程, User A向SIP Server发送SWITCHINFO消息, 向服务器传递各终端网络信息, SIP Server响应并返回200 OK, 表明系统服务器已经接收到了来自User A的SWITCHINFO消息, 如图7.

2.4 图分析方案设计与实现

动态控制器每5 s向数据库读取数据, 进行会话分析及终端网络评估, 并以30 s为时间段检测终端和MCU资源占用情况, 在此时间段中得出6次处理结果, 并根据这6次统计结果综合判断会话媒体流控制方式是否做出调整.

在媒体流控制方式调整过程中, 图分析模块获得最新数据后, 立即执行系统图分析及还原操作, 并采用基于带宽估计的拥塞检测方法计算各终端的可用带宽及资源占用情况, 得出其拥塞程度指标.

数据读取模块将SIP会议控制器存储在数据库中的各项数据进行提取, 发送给图分析模块进行系统的图还原操作. 图分析模块以conference_id作为会议群组区分, 如果contact_points不为空且conference_ type值为“dispersion”, 控制器将各端点contact_points内包含的端点解析出来并存储在邻接链表中, 以无向图构造算法还原各点连接状况, 并计算正在进行的各会议组内终端数量participant_ count, 以4端点连接为例, 相关结构如图8和图9.

图分析模块对各终端network_condition解析出的10种参数进行转换和计算, 利用基于带宽估计的拥塞检测方法, 求取拥塞程度指标Q. 采用基于带宽估计的拥塞检测方法可实时估计终端带宽使用情况, 并将终端CPU使用率和内存占用率一起纳入终端拥塞判定标准, 以加权形式得到最终计算值Q, 具体原理如下.

检测终端最大带宽表示为B, 终端由于排队延迟所占用的带宽表示为B_i, 外部应用占用网络带宽为B_e, 则终端可用带宽为.

B_e所表示占用带宽为接收占用带宽和发送占用带宽的总和, 设T为采样时间间隔, T_r为间隔内接收数据消耗时间, T_s为间隔内发送数据消耗时间, 由公式(1)可以得出一个采样间隔内网络占用带宽计算值.

${B_c} = \left( {\frac{{{T_r} + {T_s}}}{T}} \right)B$

(1)

同时系统采用指数加权平均算法对实时网络占用带宽B_e进行计算 ${B_e}(k) = (1 - \alpha ){B_e}(k - 1) + \alpha {B_c}(k) $ , α为常数且 $\alpha \in (0,1)$ .

排队延迟造成的占用带宽B_i可通过 ${B_i} = m\frac{{\sum\limits_{i = 1}^n {T(i)} }}{n}B $ 来表示, 其中m代表队列存在的数据包, n代表采样数据包数量, T_i代表第i个包的传输延迟, B代表终端最大带宽. 已知B_i与B_e便可计算出B_a, 进一步求得终端带宽使用率 $ {P_b} = 1 - \frac{{{B_a}}}{B}$ .

检测终端CPU在T₁到T₂时间段内, 总使用时间表示为T, 空闲使用时间表示为T_a, 可估计出CPU即时利用率 $ {P_t} = 1 - \frac{{{T_a}}}{T}$ . 根据从数据库提取的参数可知终端最大内存空间为R, 已使用内存空间为R_e, 可计算出内存使用率 $ {P_r} = \frac{{{R_e}}}{R}$ . 由公式(2)计算得出终端拥塞程度指标Q, β和γ均为加权系数, $ \beta \in (0,1)$ , $ \gamma \in (0,1 - \beta )$ .

$Q = \beta {P_b} + \gamma {P_t} + (1 - \beta - \gamma ){P_r}$

(2)

图分析模块以5 s为时间单位对数据读取模块传来的更新数据进行处理, 重构系统端点连接图并重新对各终端网络进行评估, 并将计算出的各终端拥塞程度指标Q连同系统连接图一并交给动态调整模块进行下一步操作.

2.5 动态调整方案设计与实现

动态调整模块接收由图分析模块传来的数据, 同时向MCU发出消息请求, 获取MCU的CPU使用率、内存使用率和通化路数等数据. 并通过MCU资源占用的综合评估法, 得出MCU资源占用指标M, 具体方法如下.

动态控制器将MCU所传递数据进行解析, 获得CPU即时利用率E_c, 内存使用率E_r和通化路数H_e. 已知MCU最大支持通话路数H, 已存在通话路数为H_e可得通话线路使用率 $ {E_h} = \frac{{{H_e}}}{H}$ . 系统为更全面衡量MCU资源占用情况, 将3个参数进行加权处理, 综合评估当前MCU负载能力, 得出MCU资源占用指标M, 具体公式为 $M = \alpha {E_c} + \beta {E_r} + \gamma {E_h} $ , $\alpha \in (0,1) $ , $ \beta \in (0,1)$ , $ \gamma \in (0,1)$ .

动态调整模块以conference_id作为通话组区分, 利用各通话组连接图寻找各组成员, 并以各终端拥塞程度指标Q和MCU资源占用指标M作为标准, 对各会议群组的媒体流控制方式进行评估, 采用公式 $ Z = \alpha Q + (1 - \alpha )M$ , $\alpha \in (0,1) $ , 得出综合评判指标Z.

当conference_type值为“dispersion”时, 表明会议组网络为网状网络, 若会议组内所有终端存在participant_count/2以上数目综合评判指标Z>0.8, 表明会议组内多数终端出现网络拥塞状况, 则该会议组必须做出调整. 若会议组内存在participant_count/2以上数目终端综合评判指标0.6<Z<0.8, 判断会议组网络将要发生拥塞, 此时系统对本会议组进行标记, 进入观察状态. 若会议组内存在participant_count/2以上数目终端综合评判指标Z<0.6, 则表明会议组无需进行调整.

当conference_type值为“focus”时, 若会议组participant_count<=5且MCU资源占用指标M>0.6, 则适合会议组媒体流控制方式进行调整.

动态控制器每5 s对各会议组进行评估并记录, 以30 s为时间段所得到的6次评估结果作为最终决策标准.

若会议组6次评估结果中存在3次及以上符合调整条件, 动态调整模块向SIP会议控制器发送调整消息, 由SIP会议控制器对该会议组进行媒体流控制方式的调整, 实现网状网络与星状网络之间的切换, 如图10为媒体流控制方式切换过程图.

3 测试

本次实验采用5台相同配置WebRTC客户端进行测试, 选用10 Mbps网络带宽进行数据流传输, 客户端配置如表1.

多方通话建立之初, 系统采用分散控制方式对媒体流在客户端之间进行收发, 网络中则形成20条进行数据交互的数据通路. 5台客户端音视频效果均能够满足通话需求, 系统运行流畅.

然后在各客户端运行笔者编写的Python程序, 提高客户端内存和CPU占用比, 将客户端两种资源占用率分别提高到70%和80%, 同时使用WANem网络模拟工具自定义网络带宽, 将各客户端可用带宽比率控制在20%以下, 此时发现客户端音视频通话出现卡顿现象, 媒体流丢包严重. 后台管理系统从图分析模块获取实时数据, 经过处理得到当前会议组网络状况图, 如图11.

经过30秒后, 系统服务器做出响应和决策, 对会议组媒体流控制方式进行切换, 将会议组网络由网状网络切换为星状网络, 控制台输出信息如图12.

此时, 后台管理系统的会议组网络状况图发生变化, 具体如图13, 表明该会议组媒体流控制方式已经改变, 并且通过分析端点颜色含义, 说明各客户端网络状况良好, 系统音视频通信运行流畅, 达到用户通话的满意效果.

4 结语

本文通过对SIP会议模型中网络拓扑结构的深入研究, 设计了一种基于多方通话的动态控制技术, 将集中式和散布式两种媒体流控制方式进行有效结合, 并在实验室现有视频会议系统中予以实现. 通过最后的测试结果, 验证了该技术的可行性以及优越性, 当终端发生网络拥塞时系统能够合理调整媒体流传输方式, 使用户获得流畅通话体验.