《IP网络多媒体通信技术及应用》课件第8章

第8章视频会议通信控制技术

8.1会议终端通信协议及过程8.2视频数据实时传输控制技术8.3网守控制的会议终端通信过程8.4网守的设计与实现 8.1会议终端通信协议及过程

8.1.1终端间通信原理

两个H.323会议终端间一次完整的通信过程包括5个阶段:呼叫建立过程、能力交换和主从确定过程、媒体信道建立过程、媒体流传输过程和呼叫中止过程。

呼叫建立过程可以不经过网守,直接在两个终端间进行。在多点视频会议中,由于会议终端数量较多且能力不同,因而会议终端管理及呼叫建立过程一般通过网守进行。呼叫建立过程使用H.225.0呼叫信令协议。能力交换和主从确定过程使用H.245协议。能力交换过程用来保证传输的媒体信号是能够被接收端接收的。这要求每一个终端的接收和解码能力必须被对方终端知道。终端不需具备所有的能力,对于不能处理的要求可以不予理睬。终端通过发送它的能力集合使对方知道自己的接收和解码能力,接收方可以从中选择某种方式。主从确定过程通过主从终端判断来保证当一个呼叫中出现两个终端同时初始化一个相同事件时不会产生冲突。终端的状态一旦确定,在整个呼叫过程期间都不会改变。在能力交换过程完成后,主叫和被叫之间就可以根据对方的接收能力发起媒体信道建立过程,包括单向信道打开过程和双向信道打开过程。媒体信道建立过程主要涉及RTP/RTCP协议。

媒体流传输过程主要是指在媒体信道上传输媒体信息流(包括音频、视频和数据流)。媒体流是直接在终端与终端之间或终端与MCU之间传输的,不涉及网守,但在H.323系统跨越代理通信时需要重定向媒体流。在通信过程中,网守可以利用IRQ消息查询终端的状态,也可以在RCF消息或ACF消息中要求终端定期发送IRR消息以便网守查询终端状态。在通信过程中还可以利用H.245控制消息实现改变信道结构、能力、接收模式等功能。例如,可以通过BRQ消息改变逻辑信道的带宽。8.1.2

H.225.0呼叫信令协议及呼叫建立过程

1.H.225.0呼叫信令协议

H.225.0呼叫信令协议是以ISDN的Q.931/Q.932为基础制订的,其中尤以Q.931最为重要。Q.931是ISDN用户-网络接口(UNI)的第三层信令协议,用于基本呼叫控制。它和网络-节点接口(NNI)的7号信令ISDN用户部分(ISUP)配合,完成从主叫用户到被叫用户的端到端连接的建立、维护和释放。对于补充业务,ISDNUNI制订了通用功能协议Q.932,规定了各种补充业务的一般控制机制及相应的消息和信息单元。与之对应,H.323系统也采用同样的体系来处理补充业务。呼叫信令由多个信令消息组成,而消息中又包含了多个不同的信息单元。H.225.0呼叫信令消息和信息单元取自于Q.931和Q.932消息和信息单元。H.225.0与它们的主要差别是H.225.0对各个消息中用户－用户信息单元的内容根据H.323系统作了新的增补定义,另外对某些信息单元的个别字段的编码和含义作了一些扩充和界定。

由于H.323呼叫不承担连接控制的任务,许多Q.931和Q.932中的消息在H.225.0中已经失去意义,因此H.225.0消息是对Q.931和Q.932消息的一种精简。H.225.0呼叫信令消息如表8－1所示。表8－1

H.225.0呼叫信令消息

H.225.0消息可以分为四大类:呼叫建立消息、呼叫清除消息、其他消息和Q.932消息。其中前三大类消息继承于Q.931消息。对于每个消息的含义和用途可参阅相关资料。H.225.0呼叫信令消息的一般结构如图8－1所示。图8－1

H.225.0呼叫信令消息的一般结构公共的消息头部由三个部分组成:协议标志符、呼叫引用值(CallReferenceValue,CRV)和消息类型。其中协议标志符固定为80H,一个字节长度,表示是Q.931协议。CRV长度为2个字节,其值由主叫方产生并且保证惟一性,用于标识呼叫,仅在呼叫段上局部有效。例如,呼叫信令采用网守选路方式传送,则主叫终端-网守和网守-被叫终端这两个信令段的CRV值一般是不同的。若采用直接呼叫方式,则主叫终端和被叫终端的CRV值相同。为了予以区分，增设一个CRV标志位F，规定主叫侧发出的信令消息恒置F=0，被叫侧发出的信令消息恒置F=1。消息类型由Q.931统一编码,在H.225.0中也规定了一些扩展值。除了上述固定的消息头部外,每一个消息中包含了若干个信息单元(InformationElement,IE),其中某些是必备的,某些是任选的。H.225.0的信息单元共有16个,其中从Q.931继承了14个,从Q.932继承了2个。各信息单元名称与相应的功能如表8－2所示。表8－2

H.225.0信息单元及其功能

2.呼叫建立过程

呼叫建立过程包括呼叫控制和连接控制两部分。

(1)呼叫控制:执行呼叫信令协议(属于H.225.0),控制信道为呼叫信令信道(可靠信道)。呼叫建立成功后,在终端之间建立起H.245控制信道。

(2)连接控制:执行H.245控制协议,控制信道为媒体控制信道,简称控制信道(可靠信道)。在终端之间建立起具有一定带宽的一个或多个逻辑信道,如音频逻辑信道、视频逻辑信道。实时通信的逻辑信道均为不可靠信道,采用UDP连接。图8－2直接传递信令消息的呼叫建立过程两个会议终端直接传递信令消息的呼叫建立过程如图8－2所示。

终端1(主叫终端)首先根据终端2的IP地址和呼叫信令信道公认的TCP端口(终端默认为1720)向终端2发起呼叫,建立其至终端2的TCP连接,即建立起可靠的呼叫信令信道。

终端1在此呼叫信令信道上发送Setup消息。

终端2回送CallProceeding消息,指示呼叫已经抵达,正在处理之中。

终端2向终端1回送Alerting消息,等待用户应答。用户应答后,终端2向终端1发送Connect消息,消息中带有终端2的H.245控制信道TCP端口号。至此,呼叫建立完成。

之后,终端1会根据终端2发送的H.245控制信道TCP端口号,与终端2建立H.245通道。至此,呼叫信令信道建立完毕。8.1.3

H.245媒体控制协议及过程

1.H.245媒体控制协议

H.245是通用的多媒体通信控制协议,主要针对会议通信设计。H.323系统采用H.245协议作为媒体控制协议,用于控制通信信道的建立、维护和释放。在H.245中定义了两类信道:控制信道和通信信道。其中,控制信道也称为H.245信道,位于H.323实体上的两个H.245对等信令实体通过该信道传送H.245消息,以控制媒体信道的建立和释放。通信信道也称为逻辑信道,在其上传送用户通信信息。一般来说,两个实体间可有多条逻辑信道,可分别传送音频、视频、数据。在呼叫建立过程中,被叫终端向主叫终端回送Connect消息,传递被叫终端H.245控制信道TCP端口号。主叫终端通过该端口与被叫终端建立H.245控制信道,每个呼叫有且只有一个H.245控制信道,它伴随着呼叫信令信道的存在而存在,直到通信结束后才释放。在控制信道中,终端通过互相发送消息进行能力协商(CapabilityExchange),确定双方的接收能力和发送能力,即交换双方所能支持的编解码器类型信息,然后根据协商的结果,分别打开相应的逻辑信道,在逻辑信道上传送相应的音视频流。结束通信时,由发送方关闭逻辑信道,双方关闭H.245控制信道和呼叫信令信道。

H.245消息可以分为4种类型:请求、响应、命令和指示。请求和响应消息由协议实体使用,构成协议过程。请求消息要求接收方执行所要求的动作,并立即返回响应。响应消息是对请求消息的回复,可以是证实、拒绝和返回请求的结果。命令消息也要求接收方执行指定的动作,但不要求其回送响应。指示消息通常是终端的状态信息,它只传送信息,不要求接收方执行动作,也不要求其回复响应。

H.245几个主要协议过程中使用的H.245消息如表8－3所示。其中每个过程都有相应的请求消息。例如,能力集协商过程中,终端能力集请求消息,对应的有终端能力集证实(Acknowledge)和拒绝(Reject)两种响应消息,而Release消息是发出请求后超时未收到任何响应时,请求方发出的撤除该请求的指示消息。打开逻辑信道确认消息用于双向信道建立,因为这是一个三次握手过程。维护环路命令关闭消息是通知对方环路测试结束的命令消息。表8－3

H.245协议过程中所用的消息

H.245基本命令消息见表8－4。其中流量控制消息的功能是限制一个逻辑信道的比特率或者所有逻辑信道总的比特率。发送终端能力集命令的作用是在发生中断或其他不确定问题的情况下,请求远端终端发送能力集消息告知其发送和接收能力。加密命令用来交换加密能力,命令远端在信道上发送初始矢量。结束会话命令表示结束,终止H.245消息传输,通常是呼叫控制过程中的最后一个消息。表8－4

H.245基本命令消息表8－5

H.245基本指示消息

2.H.245主要协议过程

H.245控制信道建立以后,需要进行能力协商以确定应该打开哪些类型的逻辑信道,根据情况的不同,需要采用不同的协议过程。以下主要介绍H.245的几个最重要的协议过程:能力协商(交换)过程、主从确定过程和逻辑信道信令过程。

1)能力协商过程

能力协商过程是H.245控制信道建立后首先要执行的一个过程,它使通信双方了解对方接收和发送信号的能力。接收能力限定了对端发送信号的模式,发送能力给定了对端请求信号希望模式的协商范围。描述终端接收和发送能力的终端能力集消息不但给出终端可支持的各种媒体信号的操作模式,而且还给出了终端同时处理多种媒体信号的可能的组合操作模式。图8－3给出了终端能力集消息的数据结构。其中,序号由证实消息返回,发送终端据此可以确定与该证实消息匹配的终端能力集消息。协议标识指明H.245版本号。复用能力主要指示该终端的多点通信能力,用于会议通信。能力表(CapabilityTable)列出了终端所允许的操作模式,如G.711音频、G.722音频、H.261CIF视频等,每种模式对应能力表中的一个表项,赋予相应的序号,称之为能力序号。图8－3终端能力集消息的数据结构一个能力描述语集(CapabilityDescriptorSet)由若干个能力描述语(CapabilityDescriptor)组成,每个能力描述语由一个能力描述语序号(CapabilityDescriptorNumber)和一个同时能力(SimultaneousCapabilities)组成。同时能力由若干个可选能力集(AlternativeCapabilitySet)组成,可选能力集由若干个能力序号(CapabilityNumber)组成。对于可选能力集,终端可以按照其中的任何一种方式工作,如可选能力集{G.711,G.723,G.728}表示终端可以采用其中任何一种音频编码方式,但不同时使用多种工作模式。而对于同时能力,终端可以同时使用一组能力进行工作。例如,同时能力由可选能力集{H.261,H.263}和{G.711,G.723,G.728}组成,则表示终端可同时工作于一个视频信道和一个音频信道,视频信道有H.261和H.263两种可选模式,音频信道有G.711、G.723和G.728三种可选操作模式。若干个同时能力构成了能力描述语集,使得终端可能选用多种组合方式工作。在不同的组合方式下,各个信道允许的操作模式可能不一样,以满足不同的需求。例如,终端的能力描述语集中,一个同时能力为上述的{{H.261,H.263},{G.711,G.723,G.728}},另一个同时能力为{{H.262},{G.711}},它表示该终端的视频信道也可以采用H.262编解码,但此时音频只能采用G.711。

2)主从确定过程

主从确定过程确定哪个终端是主终端,哪个是从终端,避免信令过程中的冲突现象。其主要应用是会议通信中的MC仲裁。一个会议呼叫中只能有一个MC,如果两个参会的H.323实体都含有MC,则必须通过一定的规则确定其中一个是主MC。该协议过程也适用于双向信道建立时的主从终端确定。主从状态确定后,在整个呼叫中将保持不变。

在执行主从确定过程时,每个终端需生成一个随机数,称为状态确定号(StatusDeterminationNumber),其取值范围为0～224－1。为了确定主从关系,任一终端可向对方发送一个主从确定消息,该消息中包含两个参数:状态确定号和终端类型。终端类型亦为一个整型数,其值按表8－6的规定确定。表8－6用于主从确定过程的H.323终端类型取值对方收到主从确定消息后,执行主从确定计算。确定主从终端的规则是:首先比较两个终端的终端类型值,大者为主;如果终端类型值相同,再比较两个终端的状态确定号,大者为主;如果仍然相同,则判定为不可确定。一般主从终端是可以确定的,此时对方回送确定消息,告知判定结果;如果不可确定,则回送确定拒绝消息,告知理由为数字相同,此时,本地终端重新生成一个状态确定号,再次启动主从确定过程。

3)逻辑信道信令过程

能力协商完成后,终端就可根据对方的接收能力发起逻辑信道建立过程。以单向信道为例,其建立过程如图8－4所示。图8－4单向逻辑信道建立过程信道打开由发送方启动,它向接收方发送打开逻辑信道消息,消息中包含前向逻辑信道号和信道参数。其中,信道号必须由发送方赋值,证实消息返回此值,以和请求消息匹配。信道参数包括数据类型、媒体信息是否需要确保传送、是否执行静音抑制、目的地终端标记等。

对方接收到打开逻辑信道消息并确认后,回送打开逻辑信道证实消息,消息中包含前向逻辑信道号和前向复用证实参数。至此,两终端间建立起了前向逻辑信道,开始传送信号。这里,“前向”指的是打开逻辑信道消息发送方至接收方的方向。双向信道信令过程和单向信道基本相同,其主要差别在于消息中还包含反向信道参数。因此,一次消息交换同时建立两个方向的信道。此外,请求方收到对端的证实消息后,还需回发一个确认消息,表示反向信道建立成功,可以开始传送信号。

通信的双方都可以发起呼叫释放,但关闭逻辑信道只能由发送方完成。接收方如果遇到无法解码等特殊情况,可以向发送方发送关闭逻辑信道请求。

8.2视频数据实时传输控制技术

8.2.1

RTP/RTCP协议结构

两个终端间呼叫信令信道建立之后,H.245控制信道建立起来,然后通过能力协商,打开相应的H.245逻辑信道,其中传输视频数据的视频信道就是一种H.245逻辑信道。在视频会议系统中,如何提高音视频数据传输的实时性和通信的QoS,这是一个技术重点也是一个难点。在H.323视频会议系统中,采用了IETF提出的RTP(Real－timeTransportProtocol,实时传输协议)来保证QoS。

RTP为具有实时特性的音频视频通信提供了传输服务。它实际上包含两个协议:RTP本身和RTCP。RTP用以传送实时数据,提供净荷类型指示、数据分组序号、数据发送时间戳和数据源标识等。RTCP用于传送实时信号传递的质量参数,提供QoS监测机制,同时还可以传送会议通信中的参会者信息,为会议通信提供控制机制。本节将分别介绍RTP、RTCP及其头部结构。

1.RTP

RTP通常运行在UDP之上,二者共同完成传输层的功能。UDP提供复用及校验和服务,也就是通过分配不同的端口来传送多个RTP流。协议规定,RTP流应使用偶数(2n)端口号,相应的RTCP应使用相邻的奇数(2n+1)端口号。

RTP分组头部固定结构如图8－5所示。其各个字段的含义简单介绍如下,有关具体解释和说明可参阅协议规范文献。图8－5

RTP分组头部结构

V:版本号,2比特,用于标识RTP的版本号,其值一般为2。

P:填充指示位,1比特。如果P位置“1”,表示分组结尾含有1个或多个填充字节。两种情况下需要填充,一种是某些加密算法要求数据块大小固定;二是在一个低层协议数据包中载有多个RTP分组。

X:扩展指示位,1比特。如果X位置“1”,则固定头部后还有一个扩展头部。扩展头部提供各种应用,传送和净荷格式无关的附加的公共信息,建议不要使用。

CC:CSRC计数,4比特,指示固定头部后部的CSRC标识的个数。

M:标志位(Marker),1比特。标志位的含义一般由应用文档解释。例如,其在H.261视频流的应用中,一般作为帧边界标志。

PT:净荷类型(PayloadType),7比特。该字段标识RTP的净荷类型,值为0标识传输G.711u数据;值为8标识传输G.711A数据;值为4标识传输G.723数据;值为18标识传输G.729数据;值为31标识传输H.261数据。其值也可以由具体应用定义。一般在会话过程中,RTP源可以改变净荷类型。序号(SequenceNumber):16比特。每发送一个RTP分组,序号加1。序号可供接收方检测分组丢失和恢复分组顺序。序号的初值应为随机数,使得数据加密后不易受到攻击。

时间戳(Timestamp):32比特。时间戳指示的是RTP数据分组第一个字节的取样时刻。如同序号一样,时间戳的初始值也是随机数。如果几个相邻的RTP分组是同时产生的,则它们的时间戳值应相同,例如属于同一帧的数据时间戳相同。

SSRC(SynchronousSource):同步源标识,32比特。SSRC用于标识信号的同步源,其值随机产生,但要保证同一个RTP会话中任意两个同步源的SSRC标识都不相同。

CSRC(ContributingSource):分信源标识,32比特。CSRC标识由混合器插入,其值就是组成复合信号的每个分信号的SSRC标识,用于标识各个组成分信号的信源。CSRC的个数由CC字段指定,最多包含15个。采用RTP协议传送视频时,用UDP分组传送,每个数据包并不一定按照先后顺序到达,甚至会出现数据包丢失的现象。此时,可以利用序号字段来判断是否有数据丢失,如有丢失,则需要进行相应的处理。另外,利用序号字段也可以对数据包进行重新排序。根据M标志位字段,可以快速判断视频数据包是否到了帧的结尾。根据时间戳字段,可以统计出每帧数据采样的时间差,从而计算出发送端视频数据的采样速率。因此,采用RTP协议能快速得到一些统计信息,以便接收端采取相应的措施,保证数据传输的实时性和正确性。

2.RTCP

RTCP的基本思想是采用和数据分组同样的配送机制向RTP会话中的所有与会者周期性地传送控制分组,从而提供数据传送QoS的监测手段,并获知与会者的身份信息。RTCP主要有4大功能:提供数据传送质量的反馈信息,这是RTCP最主要和最基本的功能;传送RTP源传输层永久标识,此标识称为规范名(CanonicalName,CNAME),接收方可根据CNAME跟踪每个与会者;确定RTCP分组发送速率,一方面保证能及时提供监测信息,另一方面使RTCP分组不会多到影响音视频信号的传送;传送少量会话控制信息,如与会者标识等。

RTCP中定义了如下几个分组类型:发送者报告(SenderReport,SR)、接收者报告(ReceiverReport,RR)、源描述项(SourceDescription,SDES)、BYE(退出会话)和APP(应用特定功能)。每个RTCP分组由固定头部和若干个可变长度的数据单元组成。分组长度必定是32比特字的整数倍,且头部有长度字段,因此多个RTCP分组可以组装成一个复合RTCP分组,各分组间无需分界指示。

SR是由数据发送者发出的发送和接收统计数据,RR是由非数据发送者发出的接收统计数据。对于复合RTCP分组,第一个RTCP分组必须是SR或RR。即使尚未发送和接收任何数据,也必须发送一个空的RR。

(1)头部:长度为8个字节。头部包含以下字段:

·版本号V,2比特。这个字段标识RTP的版本号,其值一般为2。

·填充指示P,1比特,含义同RTP分组头。

·接收报告计数RC,5比特,指示分组中包含的接收报告块个数,可以为0。

·净荷类型PT,8比特。SR的净荷类型值为200,RR的净荷类型值为201。

·长度,16比特,其值加1表示RTCP分组的长度。长度单位为32比特字,包括头部和填充字节。

·发送方SSRC,32比特,为发送该SR分组站点的同步源标识。

(2)发送方信息:长度为20字节,是SR分组的必备部分。发送方信息包含以下字段:

·NTP(NetworkTimeProtocol)时间戳,64比特,指出该SR分组发出的绝对时间,它表示相对于1990.1.1零点的时间差值,单位为秒。前32比特高位字为整数部分,后32比特低位字为小数部分。根据此值和由其他接收端回送的NTP时间戳,就能测出至这些接收端的往返传播时延。

·RTP时间戳,32比特,它所指示的时间与NTP时间戳指示的时间相同,但时间单位和初始值与数据分组中的RTP时间戳相同。此值可用于NTP同步的不同信源之间的同步。

·发送方RTP分组计数值,32比特。其值为发送者自开始发送以来直至本SR分组生成为止发送的RTP数据分组总数。

·发送方RTP字节计数值,32比特。其值为发送者自开始发送以来直至本SR分组生成时为止发送的RTP数据分组的净荷字节数(不含头部和填充字节),该值可用来估算平均净荷数据速率。

(3)接收报告块:每个报告块提供来自指定同步源的接收数据的统计信息。接收报告块包含以下字段:

·SSRC－n,32比特,本报告块信息所属信源的SSRC标识。

·丢失率,8比特,自上次SR发送以来,由SSRC－n发来的RTP数据分组的丢失比率。

·累计丢失分组数,24比特,指示从开始接收以来丢失的来自SSRC－n的RTP数据分组总数。

·扩展的已接收最高序号,32比特,该值减去收到的初始序号就是期望收到的分组数。

·到达时延抖动,32比特,是一对分组接收端接收间隔和发送端发送间隔之差值的平均偏差。

·最末SR时间戳,32比特,为最近收到的来自SSRC－n的SR分组中NTP时间戳的中间32比特。

·最末SR后的时延,32比特,为收到最近一个来自SSRC－n的SR分组至发送本接收报告块的时延,单位为1/65535秒。

2)QoS性能监测

SR和RR中有许多有用的信息可供信号发送者、接收者和第三方监测QoS性能和诊断网络问题,并及时调整发送模式。这些信息可分为三类:累计信息、即时信息和时间信息。通过计算两个接收报告累计信息之差可以监测长期性能指标;由即时信息可以测量短期性能;时间信息可以用来计算比特率指标。例如,两个接收报告的累计丢失分组数之差给出了在这段时间中的丢失分组数;扩展最高序号之差为这段时间内的期望接收分组数;二者之比为这段时间内的分组丢失率。丢失分组数除以两个报告的NTP时间戳之差为每秒分组丢失率。期望接收分组数减去丢失分组数即为这段时间内收到的分组数。由期望接收分组数还可以判断丢失统计指标的可信度。由于上述测量都是基于两个接收报告之差的,因此即使曾发生报告丢失也不会影响测量结果。第三方即使没有接收实际音视频数据,通过收到的发送者信息也可计算出这段时间内的平均净荷数据率和平均分组发送率,两者之比即给出平均净荷大小。假定分组丢失率和分组大小无关,则由某个接收站接收分组数乘以平均净荷大小就得出该接收站的吞吐量。

H.323系统利用RTCP的SR和RR监测QoS。SR主要用于多RTP流,如音频和视频流的同步。与流同步的相关字段是RTP时间戳和NTP时间戳。RR用于监测QoS指标,包括长时间指标和短时间指标。如果分组丢失率高于设定值,就应降低媒体速率。如果接收报告间隔超过设定值,则根据RR分组中的丢失率判断是否网络拥塞。若是,应降低媒体速率或者进行其他相关的处理,如降低图像帧速率、关闭不重要的媒体等。需要注意的是,RTP和RTCP为音频、视频等实时数据提供端到端的传递服务,可以向接收终端传送实时信号必需的定时和顺序信息,并向收发双方和网络运营者提供QoS监测手段。但是,RTP本身并不提供任何保证QoS的机制,要确保通信的实时性还需要IP网络本身具有这方面的增强能力。8.2.2

H.261视频数据的RTP封装

1.RTP封装原理

针对具体的音视频标准的RTP封装,IETF制订了相应的净荷格式规范。现以H.261视频格式为例,分析如何对视频进行RTP封装。经过RTP封装后的H.261数据分组是一个如图8－7所示的三层结构。图8－7

RTP数据分组图8－8

H.261头部结构

H.261头部结构如图8－8所示,长度为4个字节,32位。每个字段含义如下:

·SBIT(StartbitPosition,开始位位置),3比特,H.261数据中第一个字节需要被忽略的位数,从第一位开始计算。

·EBIT(EndbitPosition,结束位位置),3比特,H.261数据中最后一个字节需要被忽略的位数,从最后一位开始计算。

·I为帧内编码标志,1比特。若数据流仅仅只有帧内编码块数据,则置“1”,否则置“0”。

·V为运动矢量标志,1比特。如果数据流使用了运动矢量,则置“1”,否则置“0”。

·GOBN为块组号,4比特,分组中开始数据所在的块组号。若分组以块组头开始,则置“0”。

·MBAP为宏块地址预测,5比特。

·QUANT为量化因子,5比特。若分组数据以块组头开始,最后5个字段值均置0。

·HMVD为水平运动矢量,5比特。若分组数据以块组头开始,最后5个字段值均置0。

·VMVD为垂直运动矢量,5比特。若分组数据以块组头开始,最后5个字段值均置0。如果每帧H.261数据都可以封装在一个RTP分组中进行传输,则RTP封装问题将会很简单,可以将一帧数据封装在一个RTP分组中。然而,由于一个RTP分组最大为2048字节,而通常一帧数据甚至是一个块组的数据都可能大到无法封装在一个RTP分组中进行传输。因此,需要将一帧数据分割成多个较小的数据包,再封装在RTP分组中进行传输。在国际标准中规定将宏块作为RTP分组封装不可分割的最小单位,多个宏块可以封装在同一个RTP分组中,并且只要分组大小允许,多个块组甚至多个帧都可以封装在一个RTP分组中。因为当数据量很小时,这样做可以减少数据包发送的频率。需要注意的是,不可将帧头和该帧中第一个块组分开封装在不同的RTP分组中,也不可将块组头和该块组中第一个宏块分开封装在不同的RTP分组中。另外,有时宏块并不是以整字节开始和结束的,而RTP封装是以宏块为最小分割单位的,所以在每个分组的H.261头中包含了两个3比特的整数SBIT和EBIT,分别标识封装后的H.261数据的第一个字节和最后一个字节中未被使用的比特位的个数。这些未被使用的位是用于补充成整字节的填充位。

2.RTP封装具体实现算法

在一般的H.261视频数据RTP封装中,均以宏块为最小分割单位。但是,在低带宽情况下,可以以块组为最小分割单位进行RTP分组,这种方法与以宏块为最小分割单位的方法原理相同,但是执行效率较高。

对H.261数据流进行RTP封装可以分为以下三步进行,其算法流程描述如图8－9所示。图8－9

H.261视频数据RTP封装的算法流程

(1)找帧头和块组头,并进行分组。当编码器产生H.261数据流后,将该数据流保存到源缓冲区m_srcBuffer中,并将连0计数器m_zeroCounter置0,目标缓冲区m_dstBuffer赋全0。根据H.261帧结构可知,帧起始码为00000000000000010000,共20位,块组起始码和块组号连接在一起为0000000000000001xxxx,也是20位(其中xxxx的值为块组号,从1变化到12)。变量m_zeroCounter标识连0的个数,当出现14个以上连0(H.261编码时保证了纯数据不会出现14个以上连0)且最后出现1时,则认为是找到了帧头或块组头,而1后面的4比特位(将其值保存到变量m_gobNum中)决定了是帧头还是块组头。当m_gobNum等于0时,则为帧头;若m_gobNum大于0且小于等于12时,则为块组头,且m_gobNum的值即为块组号;若m_gobNum值大于12,则认为是出错。在找帧头和块组头的同时,编码器不断从m_srcBuffer中读出下一比特位的值,赋给临时变量m_tmpBitValue,经过判断后将m_tmpBitValue写入到m_dstBuffer(目标缓冲区)对应的字节中对应的比特位,以完成从源缓冲区到目标缓冲区的数据拷贝。最终,m_dstBuffer中保存的值就是进行找帧头和块组头后的分组数据。

(2)分组后的H.261数据加入H.261头。此时需要在m_dstBuffer的分组数据前加入4个字节的H.261头,H.261头各个字段值由具体的数据内容所决定。由于m_dstBuffer是从第0个字节的第0位开始拷贝的,所以将字段SBIT的值置为000;而字段EBIT的值则由m_dstBuffer的最后一个字节有几个无效位(填充位)决定,其值在000～111之间变化。由于一般都采用帧内和帧间编码相结合的方式,所以字段I的值置0;H.261编码中一般采用运动检测,字段M置1。采用块组作为最小分割单位时,GOBN、MBAP、QUANT、HMVD、VMVD几个字段均置全0。

(3)在加入H.261头的基础上加入RTP头。H.261分组数据加上H.261头后,需要再添加RTP头。当找到帧头时,可以认为是上一帧数据的结束,则将m_markFlag(帧结束标志)置为1(修改RTP头的Mark标志位的值为1),再将加入H.261头的m_dstBuffer加入相应的RTP头。当找到块组1时,由于不能将帧头和块组1分开,所以在此处不作处理,继续找块组2的起始码。当找到块组2到12时,将m_markFlag(帧结束标识)置为0(修改RTP头的Mark标志位的值为0),再将加入H.261头的m_dstBuffer加入相应的RTP头。最后将加上H.261头和RTP头的H.261分组数据从视频逻辑信道中发送出去,在接收端按照与上述相反的过程去掉RTP头和H.261头即可得到视频数据。至此,完成视频会议系统中视频数据的实时传输。

在低带宽情况下,以块组为最小分割单位时能极大提高程序运行的效率;当带宽较大时,需要以宏块为最小分割单位,以此来保证传输的图像质量。当将块组作为最小分割单位时,若视频编码率小于384kb/s,则图像较为理想,基本不出现马赛克现象。当视频编解码速率大于768kb/s时,图像会出现比较严重的马赛克现象(因为处理时将大于2048字节的块组丢弃)。当视频编码率速率较高时,每个块组数据量很大,会超过2048字节,此时不能将一个块组数据封装在一个RTP包中,需要对块组进行拆分,将其分成多个宏块进行RTP封装。

8.3网守控制的会议终端通信过程

由网守控制的H.323终端之间建立通信一般要经过以下三个控制过程。

(1)呼叫接纳控制:执行RAS协议(属于H.225.0),控制信道为RAS信道(不可靠信道)。网守同意接纳后在终端和网守之间建立起呼叫信令信道,进入呼叫建立。

(2)呼叫控制:执行呼叫信令协议(属于H.225.0),控制信道为呼叫信令信道(可靠信道)。呼叫建立成功后,在终端之间建立起H.245控制信道。

(3)连接控制:执行H.245控制协议,控制信道为媒体控制信道,简称控制信道(可靠信道)。在终端之间建立起具有一定带宽的一个或多个逻辑信道,如音频逻辑信道、视频逻辑信道。实时通信的逻辑信道均为不可靠信道,采用UDP连接。8.3.1网守的功能

在H.323标准中,网守(GateKeeper,有时又称网闸)提供对端点和呼叫的管理功能,它是一个任选部件,但是对于公用网上实际运行的视频会议系统来说,网守是一个不可缺少的重要组件。在逻辑上,网守是一个独立于端点的功能单元,然而在物理实现时,它可以装备在终端、MCU或网关中。网守相当于H.323网络中的虚拟交换中心,其功能是向H.323节点提供呼叫控制服务。当系统中存在网守时,它必须提供以下基本功能:

(1)地址翻译。根据端点在网守注册时建立的翻译数据库表,将被叫终端或网关的别名地址翻译为传输层地址。网守运行期间,翻译数据库表不断地根据注册信息更新。别名可以是一些便于记忆的名字,比如昵称或电子邮件地址等,但更常用的别名是E.164地址(电话号码)。

(2)呼叫接入控制。当端点发起呼叫时,首先给网守发送接入请求消息(ARQ)。网守根据用户的权限和此时的可用网络带宽等条件判定是否允许该次呼叫请求,相应地回送接入证实(ACF)或接入拒绝(ARJ)消息。

(3)带宽管理。网守支持BRQ/BRJ/BCF消息,网守根据终端类型和网络带宽利用率对域中带宽的使用情况进行控制,并且可以根据端点的请求情况和网络实际运行情况动态地重新分配带宽。

(4)区域管理。域中所有的设备都要在网守上注册,网守提供对整个域(包括终端、网关、MCU、MC以及非H.323设备)的管理功能。

(5)呼叫控制。H.323协议规定终端至终端的呼叫信令有两种传送方式:一是经由网守转接的网守转发呼叫信令方式,双方不知道对端的地址,有利于保护用户的隐私权,网守介入呼叫信令过程;另一种是端到端的直接路由呼叫信令,网守只在初始的RAS过程中提供被叫的呼叫信令信道传输层地址,其后不再介入呼叫信令过程。

(6)呼叫管理。例如,网守可以保存一份正在进行的H.323呼叫清单,据此来判定被叫终端是否忙,并向带宽管理模块提供带宽使用信息。

(7)网络管理。网守可以向计费中心提供计费基础数据,向管理中心提供话务统计基础数据。

(8)其他功能,如终端带宽预留、目录服务、信息库管理等。8.3.2网守的层次结构

公用视频会议系统采用两级体系结构,即顶级网守和一级网守。在业务量大的地区可根据需要增加二级网守,形成三级体系结构。公用视频会议系统网守的体系结构如图8－10所示。图8－10公用视频会议系统网守体系结构顶级网守云可以包含多个顶级网守,顶级网守之间的连接、一级网守与顶级网守之间的连接以及不同运营者之间的连接由各运营者根据各自的情况自行确定其方式。当运营者网络规模不是很大时,顶级网守的功能可由其中一个一级网守完成。

(1)顶级网守。顶级网守负责管理属于该运营者的一级网守,主要负责一级网守之间的地址解析、不同运营者视频会议网之间的互通和地址交换;也负责国际业务的管理,即国际呼叫的建立和拆除。

(2)一级网守。一级网守主要负责该一级网守所管辖的全部二级网守以及IP电话终端代理间的地址解析工作。在两级网的情况下,二级网守的功能全部归入一级网守。

(3)二级网守。二级网守主要负责所属区域内用户的地址解析和认证,防止非法用户的接入和非法网关的登记;负责向所属网关提供路由信息,包括被叫网关的端口信息等。

(4)网守之间的互通。网守之间的通信完成不同区域之间的呼叫建立。顶级网守与一级网守之间,或一级网守与二级网守之间的互通采用RAS协议,主要传送用户地址解析信息。

(5)网守与网关之间的互通。网守与网关之间使用RAS协议进行通信,RAS信令采用H.225.0消息在网守与端点之间完成注册、接入控制、带宽转换、状态信息传送和切断等操作。RAS信令信道与呼叫信令信道和H.245呼叫控制信道无关。RAS信令信道为非可靠信道,使用UDP方式传送信令。8.3.3网守的RAS协议及过程

1.RAS协议

RAS协议是H.225.0协议的一部分,故又称H.225.0RAS协议。RAS协议为网守专用,故又称网守RAS协议。

RAS协议用于端点和网守或网守与网守之间,主要实现呼叫的设备管理、地址解析、计费和认证信息的传递。具体的RAS消息如表8－7所示。表8－7

RAS消息表8－7

RAS消息

RAS协议的管理功能主要包括设备的管理、呼叫管理和资源管理三部分。

设备管理分为搜索、登录和注销三个流程。搜索有动态搜索和静态配置两种,静态配置无需进行设备发现申请,直接通过设备间事先的手工配置进行。动态搜索则需要设备进行动态的发现流程,即请求上级设备提供可接入的设备的IP地址,同时交换双方的安全信息,协商加密算法,协商共享密码。呼叫管理包括接入控制序列、拆线序列和地址解析序列,主要用在网关和网守之间。接入控制序列由网守检查网关接入呼叫的信息,分为带卡流程和不带卡流程两种;拆线序列实现呼叫的释放、计费信息的提取和保护;地址解析序列根据被叫信息解析被叫对端网关的地址。

资源管理包括带宽管理、信息查询、资源可用性汇报序列。

2.RAS协议过程

RAS信道是不可靠传输信道(在IP网络上使用UDP),用于承载注册、认证、状态等RAS消息。RAS信道使用周知端口UDP1719。

1)网守查找

H.323提供一种自动查找网守的方法。终端广播一条网守请求消息GRQ,接收到GRQ消息的网守向该终端发出网守确认消息GCF;当网守不希望终端向其注册时就发出网守拒绝消息GRJ,如图8－11所示。如果一个终端收到多个GCF消息,它可以选择其中一个网守注册。图8－11网守查找

2)终端注册

注册是一个终端加入一个域并告知网守其传输层地址和别名地址的过程。终端发起呼叫之前必须先向网守注册。终端向网守发送登记请求消息RRQ,网守返回注册确认消息RCF或注册拒绝消息RRJ,如图8－12所示。图8－12终端注册终端可以向网守发送注销注册消息URQ以注销其注册。网守以注销注册确认消息UCF响应。当终端并未在该网守注册时,网守返回注销注册拒绝消息URJ。注销注册使终端可以改变其别名地址和传输层地址的关联。网守也可以通过发送URQ消息来注销终端的注册,这时终端必须返回UCF消息。此后终端应重新注册。终端重新注册时可以向另外一个网守注册。注销注册过程如图8－13所示。图8－13注销注册过程

3)终端定位

当一个终端或网守知道另一个终端的别名地址并想取得它的联系信息时,可以发出定位请求消息LRQ。LRQ消息可以发往指定网守的RAS信道,也可以向GRQ消息一样广播出去。另一个终端所注册的网守应发送定位确认消息LCF,该LCF消息包含了该终端或该终端所属的网守的联系信息。联系信息包括与该终端联系的呼叫信令信道和RAS信道地址。

当网守在其RAS信道上收到LRQ消息,而目标终端未向其注册时,网守应返回定位拒绝消息LRJ;当网守在其广播地址上收到LRQ消息,而目标终端未向其注册时,网守不必做出响应。

4)认证、带宽改变和脱离

RAS信道也用于传送认证、带宽改变、状态和脱离等消息。这些消息在终端和网守之间提供认证控制和带宽管理的功能。

认证请求消息ARQ制订了所需的呼叫带宽,这是发送和接收的媒体信道除去RTP头、RTP载荷、网络载荷以及其他开销的总的比特率上限。数据和控制信道不包括在此上限中。网守可以在认证确认消息ACF中降低呼叫带宽。终端应确保其发送和接收的媒体流的总比特率不高于呼叫带宽。终端或网守可以通过带宽更改请求消息BRQ来修改呼叫带宽。8.3.4网守转发呼叫信令过程

在没有网守的网络中,呼叫信令消息在主叫和被叫终端之间直接传送。主叫终端应知道被叫终端的呼叫信令信道传输层地址,以使它们能直接通信。呼叫信令信道可以使用周知端口TCP1720。

在包含网守的网络中,初始的认证消息在主叫终端和网守之间通过网守的RAS信道交换,网守在ACF消息中指示主叫终端呼叫信令是直接发往被叫终端还是通过网守转发。

1)呼叫信令信道路由

呼叫信令有两种传送方式:一种方式是网守转发呼叫信令,呼叫信令消息通过网守在两个终端之间转发,如图8－14所示;另一种方式是终端直连呼叫信令,呼叫信令消息在两个终端之间直接传送,如图8－15所示。采用哪种方式由网守决定。图8－14网守转发呼叫信令图8－15终端直连呼叫信令

2)H.245控制信道路由

当采用网守转发呼叫信令方式时,有两种方法转发H.245控制信令:一种是在两个终端之间直接建立H.245信道,如图8－16所示;另一种方法是在终端和网守之间建立H.245信道,由网守转发H.245控制消息,如图8－17所示。采用哪种方式由网守来选择。当采用终端直接呼叫信令方式时,H.245控制信道只能在终端之间直接建立。图8－16终端直接建立H.245控制信道图8－17网守转发H.245控制信道8.3.5呼叫中止信令过程

通信的任何一方都可以发起呼叫终止过程,而且网守也可以终止一个呼叫。

1)终端中止呼叫

终端中止呼叫的步骤如下:

(1)关闭所有媒体信道。

(2)在H.245控制信道中发送结束会话消息(EndSessionCommand),通知远端断开媒体信道连接,然后停止H.245控制消息的传输。

(3)等待接收远端的结束会话消息,然后关闭H.245控制信道。

(4)若呼叫信令信道是打开的,则发送ReleaseComplete消息并关闭此信道。

(5)如果终端已在网守注册,则还要向网守发送H.225.0脱离请求消息DRQ,网守以脱离证实消息DCF响应。这是因为网守需要知道带宽释放的情况。DRQ/DCF消息在RAS信道上发送。

如果未发出结束会话消息的终端收到了结束会话消息,它将执行上述除第(3)步外的其他4步,无需等待远端发送结束会话消息。

2)网守中止呼叫

网守可以向一个端点发送DRQ来中止呼叫。此终端应立即执行如下步骤:

(1)关闭所有媒体信道。

(2)在H.245控制信道中发送结束会话消息通知远端断开媒体信道连接,然后停止H.245控制消息的传输。

(3)等待接收远端的结束会话消息,然后关闭H.245控制信道。

(4)如果呼叫信令信道是打开的,则发送ReleaseComplete消息并关闭此信道。

(5)网守发送DCF消息。8.3.6快速协议过程

为加快逻辑信道的建立速度和节省资源,在H.323v4版本之中定义了快速连接(FastStart)方式和隧道机制(Tunneling)。

1)快速连接

常规的H.323系统协议过程是首先利用H.225.0信令建立呼叫,然后进行能力交换,最后才打开传输媒体流的逻辑信道,其过程比较繁杂。快速连接的特点是将信道建立过程和呼叫建立过程融合在一起,且省略了能力交换过程,从而有效地缩短了连接建立时间。快速连接的过程如下：主叫在Setup消息中置入“快速启动”(FastStart)数据单元,该单元由若干个“打开逻辑信道”(OLC)数据结构组成,每个OLC描述主叫提议的一个发送或接收媒体信道,包括立即打开此信道并在此信道上传输媒体信息所需的所有参数。如果被叫愿意执行快速连接过程,则可在主叫提议的OLC中选取它同意并能够支持的一个信道构成返回快速启动数据单元,置入后向消息(CallProceeding、Alerting或Connect等)之中返回给主叫,这样,凡是选中的信道就认为已经被打开。被叫在给主叫返回了包含返回快速启动数据单元的后向消息后,就立即可以开始在自己打开的反向信道上发送媒体信息,并准备好在它同意接受的前向信道上接收媒体信息。于此相应,主叫在发出Setup消息后必须准备在它提议的任一个反向信道上接收数据。如果被叫不能执行或者不愿执行快速启动,则可以拒绝使用此过程。方法是不在Connect及其以前的后向消息中包含任何返回快速启动数据单元。另外,如果主叫未在Setup消息中发送快速启动数据单元,被叫也不能自己生成返回快速启动数据单元。快速连接过程只能由主叫发起。

2)隧道机制

为了节省资源、融合呼叫信令和呼叫控制并缩短呼叫建立时间,H.323v4设计了在H.225.0呼叫信令信道上传送H.245消息的隧道机制。

隧道机制在呼叫信令消息之中新增一个“H.245隧道”单元,将H.245消息作为字符串复制、封装在该单元中。一个信令消息可以封装多个H.245消息,接收方按顺序逐个处理。如果在需要传送H.245消息时没有信令消息要发送,则用Facility消息封装传送。如果主叫要使用隧道机制,则应置Setup消息中的“H.245隧道”单元为真,其后所有信令消息中的该单元都须置真。如果被叫支持并愿意使用隧道机制,也要在响应Setup的所有后向消息中置“H.245隧道”单元为真。一旦某消息置此单元为假,则自此以后隧道机制失效。被叫可以用将此单元置假的方法来拒绝使用隧道机制。隧道机制不能和快速连接方式同时使用,因为隧道传送的H.245消息可以强制覆盖快速连接过程。

快速连接方式和隧道机制在H.323系统跨越代理通信的情形之中也要求能够理解其连接建立过程,并能够处理相应的消息。 8.4网守的设计与实现

8.4.1网守的系统设计

网守的结构如图8－18所示。这是一种较为完整的结构,适合大规模系统应用。此处我们只讨论能够为所有连接到LAN上的H.323端点提供基本服务的网守的实现问题。

1)标准性要求

网守设计应符合ITU－T制订的H.323协议和中国通信行业标准《IP电话网守设备技术要求》的要求,支持H.225.0、H.245、LAN通信协议(IEEE802.3或IEEE802.3u)、TCP/IP等;使用面向对象的编程技术,使系统具有清晰的逻辑层次结构,系统应具有较强的兼容性,易于维护和二次开发;能够和符合H.323协议的各种设备(网守、终端、MCU、网关)相兼容,并且可以为它们提供相应的服务。

2)功能性要求

网守应实现H.323规定的基本功能和部分可选附加功能,实现相关的所有协议,应具有记录网守运行日志的能力,能够提供计费所使用的原始通信纪录,实现计费功能,或提供运营商所需的计费接口。根据H.323协议中关于网守功能的规定,可将网守划分为五个功能模块:

·呼叫控制和管理(CallControlandManagement)

·地址翻译(AddressTranslation)

·带宽控制和管理(BandwidthControlandMangement)

·用户认证、授权和计费(Authentication,Authorization&Account,AAA)

·计费信息的采集(CallDetailRecordConvergence,CDRConvergence)

3)运行环境要求

系统要最大限度地适用于多种平台环境,兼容性要好,一般要求能够在Windows9x、Windows2000、WindowsXP、WindowsCE、UNIX等平台下运行。

4)使用维护要求

要求系统兼容性较强,结构简单,维护方便,升级容易,功能较强,组网灵活,成本较低。图8－18网守的结构8.4.2网守的实现方法

网守实现基于面向对象的编程方法,用VC++语言作为开发系统,采用Pwlib和OpenH323两个SDK动态连接类库。

软件实现平台采用Pwlib和OpenH323两个动态连接类库的原因在于:

(1)这两个库中封装了大量的通信类库以处理信令交互和报文收发,整个平台的设计遵循开放性原则(MozillaPublicLicense),能够很好地支持H.323协议。

(2)类库Pwlib是一个适度大小的类库,它的发展已有很长一段时间了,其最初的主要目的是形成一种同时可在MicrosoftWindows、UNIX、Linux等多种操作系统平台上运行的具有通用性的类库系统,然而它以后的发展却远远超越了最初的目的。I/O的封装类、多线程类、UNIX后台邮件收发类、基于NT平台的服务器类,几乎所有的互联网协议类均被逐渐地增加进来,同时遵循了开放性原则,因此Pwlib非常适合作为开发H.323系统的基础类库。

(3)类库OpenH323基于类库Pwlib之上,也是一种开放源代码的、可供互操作的、具备完整特性的、适度大小的、面向整个H.323协议栈的基础类库,是由澳大利亚一家叫EquivalencePtyLtd的公司发展起来的。在遵循开放性原则的前提下,所有对其感兴趣的团体、商业、个人均可免费使用该类库。

(4)开发人员可以通过互联网在开放性原则下共同使用这两个类库,相互交流,共同开发,共同提高,这使得我们可以最大限度地降低开发成本和减少开发周期,也使得网守与类库可实现同时升级。

网守的开发系统采用VisualC++6.0,数据库使用微软的Access。对于一个电信级会议系统,由于用户数很多,数据量很大,安全性要求很高,必须使用大型的数据库来完成各种信息的存取,通常可使用SQLServer、Oracle、Sybase等。使用Microsoft的Access数据库,主要基于以下考虑:

(1)微软在Windows和VisualStudios系列中对Access数据库的支持,让我们可以方便地操作Access数据库,并且它的效率也较高。

(2)面向小规模应用所设计的网守,数据量相对还不是很大,Access数据库完全满足应用要求。

(3)Access数据库的整个数据存放在一个文件中,移动和拷贝比较方便。

(4)采用适当的封装之后,在以后需要升级到大规模的应用数据库时,可以方便地从访问Access数据库向访问SQLServer或者Oracle数据库过渡转变。当然,如果使用ODBC数据库引擎访问数据库,这种转变将不再是问题。8.4.3网守的实现

1.模块说明

根据以上对网守功能结构的分析,我们在实现时把网守分解为以下几个主要的功能模块:RAS协议过程实现模块、呼叫信令路由模块、端点注册信息链表模块、计费模块、H.245协议处理模块等,如图8－19所示。图8－19网守主要模块的信息传递结构图

RAS协议过程实现模块用来处理RAS协议过程,它包括网守搜寻(采用多播机制完成)、端点登记、呼叫接纳、呼叫退出、带宽管理等过程,并且把相应的端点信息传送到端点注册信息链表模块。

呼叫信令路由模块用来与终端之间进行H.225.0呼叫信令过程,它包括呼叫建立、呼叫清除、Q.932消息处理等过程,并且支持呼叫转移功能,既可以进行一般的连接过程,又支持快速连接过程。建立呼叫路由之前首先要从端点注册信息链表模块中取得端点信息,在合法的情况下再去建立呼叫路由,然后再把呼叫信息传送到当前呼叫信息链表模块中,直至呼叫清除时再次传送信息给当前呼叫信息链表模块和计费模块去处理。端点注册信息链表模块用来储存注册终端的详细信息,包括别名、呼叫信令传输层地址、RAS端口地址、终端ID、终端类型、制造厂商代码等;还提供端点的插入、删除、更新、查询、类型判断、超时处理等大量的用户接口功能。

当前呼叫信息链表模块用来储存当前正在进行呼叫和通话的每一对呼叫的详细信息,包括主叫和被叫ID、呼叫ID、呼叫引用值、分配带宽、呼叫的发起时间等信息,同样也包括呼叫的插入、删除、更新、查询等大量的用户接口功能。计费模块从呼叫信令路由模块中取得呼叫信息,对每次的呼叫原始计费信息进行详细记录。这些信息至少包括呼叫起始时间、终止时间、主被叫E.164别名地址、主被叫IP地址、使用带宽等信息。

2.网守主程序

一个处于运行状态中的网守,其各个功能模块的瞬时运行状态都是随机并发的,每个模块内部又要同时处理若干个端点的请求或连接。因此网守最适合于使用多线程的编程方法来实现。网守在实现时,首先由主程序创建RAS处理线程、呼叫信令处理线程、多播接收处理线程这三个线程来启动相应的功能处理模块,然后在各线程内部当每接收一个请求或连接时,该模块便向系统申请所需的资源,然后在其内部产生一个专门用来处理此次请求或连接的子线程,直至此次请求或连接结束时,该子线程将自动停止运行,释放所占用的系统资源以备系统重新分配使用。网守的主程序完成的任务主要是生成网守的主控制台界面窗口,实现网守运行前的初始化过程,搜集所需的各项环境参数,建立终端注册表(EndpointTable)、当前呼叫信息表(CallDetailTable)等各功能块运行所必需的信息链表,启动网守各功能模块的相应线程,以及随时根据系统管理员发出的控制台命令对网守当前工作状态、运行日志进行查询、关闭或结束网守等动作。图8－20是网守的主控制台界面。图8－20网守的主控制台界面网守的主控制台界面主要包括四部分:菜单栏、图形按钮、网守所在主机IP地址显示窗、网守工作信息显示窗。菜单栏内包含很多命令，用于启动或关闭网守,查看注册终端表、当前呼叫信息表、工作日志等。图形按钮是最常用的菜单命令的快捷按钮。网守所在主机IP地址显示窗是网守启动后显示主机IP地址的窗口,该地址供各终端设置时查询使用。网守工作信息显示窗用于显示网守的工作状态以及各表项参数。

网守主程序的简要工作流程如图8－21所示。图8－21网守主程序简要工作流程下面是网守主程序中启动各功能块的关键语句以及简要说明,它们完成了各数据链表的建立和各工作线程的启动:

//建立注册终端信息表

MyEnviron.EPTable=newEndpointTable(MyEnviron);

//建立当前呼叫信息表

MyEnviron.CTable=newCallTable(MyEnviron);

//建立RAS日志

MyEnviron.Log=newOpengateLog;

//创建呼叫信令处理线程

CallThread*CThread=newCallThread(MyEnviron);

MyEnviron.MyCallAddr=CThread－>GetMyCallSignallingAddr();

//创建RAS信令处理线程

RasThread*RThread=newRasThread(MyEnviron);

//创建Multicastreceiver线程

MulticastThread*MCThread=newMulticastThread(MyEnviron);

3.RAS消息处理线程

RAS消息处理线程(RasThread)完成的功能实际就是RAS协议过程,它包括网守搜寻、端点登记等过程。RAS协议是端点和网守之间执行的协议,基本上实现管理功能。

网守赋予了一个公认TSAP标识(对于IP网络来说就是TCP/UDP端口号)作为RAS信道的TSAP标识,对于IP网络来说就是端口1719。一般的端点在启动时首先要向网守注册登记,因此必须事先知道网守的RAS协议的传输层地址(网络层地址+TSAP标识),也称为RAS地址。图8－22是RAS消息处理线程的简要流程。图8－22

RAS消息处理线程简要流程流程图中处理RAS消息是该线程的核心部分,完成了RAS协议的主要功能,包括端点登记、呼叫接纳和退出带宽管理等功能。

1)网守搜索

网守搜索有两种方式:人工方式和自动方式。自动方式是通过搜寻多播地址发送GRQ消息来实现的。人工方式通过对端点的配置来完成,将其归属的网守传输层地址预置入端点的配置文件或初始化文件中。

自动方式允许端点和归属网守的关系可以随时间而改变,当原有网守出故障时可以自动切换到替换网守上去,当所属网守改变后无需在每个终端上修改其配置文件。在自动方式中,端点采用搜寻多播地址发送GRQ消息,询问“谁是我的网守”。可以有一个或多个网守回送GCF消息,表示“我可以是你的网守”,并在消息中告知其RAS地址。不愿意该端点在其上登记的网守则返回GRJ消息。如果有多个网守回送GCF消息,端点可在其中任选一个作为其归属网守。如果超时仍未收到网守的响应,端点可重发GRQ消息,但两次相邻GRQ之间的时间间隔不能小于5秒。如果仍未收到响应,则改用人工搜寻。当然如果事先知道网守的IP地址,则可以直接使用人工搜寻。端点发送的GRQ消息包含端点类型、端点自身的RAS地址、希望在其上登记的网守标识等参数。若未含网守标识参数,就表示端点愿意在任何一个网守上登记。网守返回的GCF消息除了包含该网守标识和RAS地址外,还可包含“替换网守”序列参数并指定优先级顺序。如果至该网守的请求未予响应或被拒绝