基于SIP的VoIP网络电话终端.docx

基于SIP的VoIP网络电话终端VoIP的定义 网络电话，即VoIP(Voice over Internet Protoco1)，是一种数字电话，通过对语音信号的模数转换、压缩编码和打包分组，以Internet作为传输媒介，从而实现语音通信业务。 VoIP的数据处理流程： 数据处理的几个阶段： (1)模数转换(AD) 对模拟语音信号进行PCM编码，然后把PCM码流送到缓冲存储区中。 (2)数据到IP包的转换 一旦语音信号进行数字编码，下一步就是对语音包以特定的帧长进行压缩编码。编码后，将压缩的帧合成一个压缩的语音包进入网络处理器。网络处理器为语音包添加IP包头、级别和其它信息后，通过IP网络一站一站地转发到目的地。 (3)IP包到数据的转换 本地接收到IP语音包后，在网络层提供一个可变长度的缓冲器，来调节网络产生的抖动。该缓冲器可包容许多语音包，具体太小可由用户调节。编码器将接收的压缩包解压，然后分帧后送入解码缓冲器中。在这个处理过程中，主要进行包拆分，去IP包头，保留原始语音信息，然后把语音数据提供给语音编码器。 (4)数模转换(DA) 语音解码器将输入的PCM数据转换成模拟信号，然后接上电话机或者扬声器就可以听到声音了。 VoIP关键技术 IP是一种无连接的技术，只能提供尽力而为的服务，无法保证服务质量。同时，语音属于实时业务，对时序、时延等有严格的要求，因此IP网络中传输语音可能会出现分组丢失、错序到达、延时抖动的情况。必须采取特殊的措施以保证一定的服务质量。IP电话的关键技术有：信令技术、语音编码技术、实时传输技术、服务质量保证技术、以及网络管理和安全技术等。 (1)信令技术 信令技术保证电话呼叫的顺利实现和话音质量，目前电信级的IP电话中比较流行的是H323和SIP，当然也有一些自行定制的通信协议，如最近互联网上非常流行的基于P2P技术的IP电话软件Skype等。 (2)编码技术 带宽是影响语音质量的关键因素。要解决这个问题：一是提高网络带宽；二是尽量降低语音传输所需要的带宽。这就要求系统终端能够将语音数据进行压缩，以低比特率发送到网络上。语音编码的基本策略是提取最能表示语音特征的参数，而尽量去掉冗余或者人耳不敏感的信息。具体策略有：尽量减少语音信号中的冗余度；充分利用人耳的听觉特性减少编码信息：静音压缩。 目前，主要编码技术有ITU-T的G.711、G.7231、G.729a等。其技术特性比较如下表： (3)实时传输技术 采用RTP。RTP是提供端到端的包括音频在内的实时数据传送协议。RTP包括数据和控制两部分，后者叫RTCP。RTP提供了时间标签和控制不同数据流同步特性的机制，可以让接收端重组发送端的数据包。 (4)QoS保障技术 RTCP协议虽可提供QoS(0uality of Service，服务质量)的监视手段，但要确保通信实时性还需要IP网络增强能力。目前主要有两类技术：一是RSVP(Resource ReSerVation Protocol，资源预留协议)，根据用户需要和网络资源可用性为每个呼叫保留所需带宽；另一个是业务区分技术，根据类别对业务流提供不同等级服务。 (5)网络管理和安全技术 首先是直接跟呼叫有关的管理功能，如带宽管理、用户登记和状态管理等。其次是网络运营管理，包括计费、话务统计、运营商之间的互操作等。 安全管理是IP电话有别于传统电话的一个重要特点。由于IP网络是一个开放式的网络，因此必须防止用户受到恶意攻击以及用户资料信息被泄漏等。其功能应包括用户鉴权、授权、信息加密等。 VoIP信令协议 对于诸如语音、视频等多媒体实时数据的传送，往往要求承载这些业务的网络有一定的机制来控制传输时延、减少抖动及降低数据丢失率。为了使语音信号在这种网络下传输，就必须使用其他一系列的协议在高层上对语音的实时性进行保证。这些协议协同工作，便构成了VoIP网络的协议体系，如下图所示： 由上图可见，VoIP协议栈中，信令控制协议主要包括H323协议和SIP协议两种，媒体控制协议主要有RTP、RTCP和RTSP。信令控制协议类的传输层承载协议可以是TCP协议或UDP协议。通常情况下，使用可靠性较高的TCP协议来承载信令控制协议。媒体控制协议的主要作用是对实时媒体数据进行封装然后交由下层进行传输。一般以UDP协议作为实时媒体数据的载体。其中，语音数据所用到的传输协议为RTP和RTCP。 SIP的网络结构 SIP是一个客户服务器协议，呼叫控制请求发出方称为客户，请求接受并处理方称为服务器。SIP端系统包括一个客户协议程序和一个服务器协议程序，分别称为用户代理客户(UAC)和用户代理服务器(UAS)。在网络中有两类服务器： (1)代理服务器(Proxy Server) SIP请求可以经过多个代理服务器，每一个代理服务器接收请求后转发给下一跳服务器，下一跳服务器可能是代理服务器，也可能是最终的用户代理服务器。 (2)重定向服务器(Redirect Server) 其功能是通过响应告诉客户下一跳服务器的地址，然后由客户根据此地址向下一跳服务器重新发送请求。 下图是Iptel(IETF的工作组)采用的CS网络结构。 实际上，代理服务器和重定向服务器在确定下一跳服务器时都可能向定位服务器(Location Server)发出查询请求。定位服务器本身不属于系统的范围，是Internet中的公共服务器。考虑到用户移动性，用户可能会在多个主机上登录，因此定位服务器有可能返回多个位置信息。如果重定向服务器收到多个位置指示，则将这些位置信息全部回送给客户。如果代理服务器收到多个位置指示，则可按顺序方式或并行方式逐一试探，直至呼叫成功或被用户拒绝。 SIP的功能 SIP主要支持以下5个方面的功能： 名字翻译和用户定位：检查终端用户的所在位置，用于通信； 用户能力交换：确定所用的媒体类型和媒体参数； 用户可用性判定：确定被叫方是否空闲和是否愿意加入通信； 呼叫建立：“ringing”邀请和提示被叫，在主被叫之间传递呼叫参数； 呼叫管理：发送、终止和呼叫转交(transfer)，修改会话参数，激活服务等。 SIP协议栈 SIP在多媒体网络体系中的位置如下图所示。 媒体传送层将PCM话音码流经RTP封装后在IP网上传送，信令协议采用SIP。SIP并非集成的通信系统，它要和其它IETF的协议组成一个多媒体架构。RTP来传输实时数据，SDP(Session Description Protocol，会话描述协议)具体描述多媒体会话。同时，用RSVP和RTCP检测传送QoS。 SIP基本消息体 SIP消息主要分为两大类，即请求消息(Request)和应答消息(Response)。 一个基本的SIP消息包括起始行、一个或多个头字段、说明头字段结束的空行和一个可选的消息体。一般格式为： Generic-message=start-line *message-header CRLF message-body 起始行给出SIP版本、调用的请求操作(方法)、被邀用户当前地址、响应类型等。消息头部分为4类：通用头部、请求头部、响应头部和实体头部。空行表示消息头部字段的结束。消息体主要是SDP会话描述。上面描述中的符号“*”表示该字段可有多个。 请求消息格式 请求消息=请求起始行 *(通用头部|请求头部|实体头部) CRLF(空行) 消息体 其中，请求起始行=方法+空格+请求URI+空格+SIP版本号+空行 即为：Request-Line=Method SP Request-URI SP SIP-VERSION CRLF SIP共定义了6个方法，分别如下： INVITE：用来邀请用户或应用程序加入某会话，会话描述含于消息体中； ACK：用于证实客户机已收到对于INVITE请求的最终响应； OPTIONS：用于询问服务器的能力； BYE：用户代理客户程序用此方法指示释放呼叫； CANCEL：用于取消一个尚未完成的请求； REGISTER：客户程序用该方法在SIP服务器登记列于To字段中的地址。 主要头部字段 From：指示请求的发起者。 该字段的一般格式为From：显示名<SIP-URI>；tag=xxxx 其中，显示名为用户界面上显示的字符，如果系统不予显示，应置显示名为“匿名”(Anonymous)。显示名为任选子字段。tag称为标记，为16进制数字串，中间可带连字符“"。当两个共享同一SIP地址的用户实例用相同的Call-ID发起呼叫邀请时，就需用此标记予以区分。标记值必须全局唯一。 To：指明请求的接收者，其格式和From相同，仅第一个关键词代之以To。 Call-ID：用以唯一标识一个特定的邀请或标识某一客户的所有登记。 CallID的一般格式为Call-ID：本地标识主机 其中，主机应为全局定义域名或全局可选路IP地址，此时，本地标识由在“主机”范围内唯一的URI字符组成。否则，本地标识必须是全局唯一的值，以保证Call-ID的全局唯一性。Call-ID字符需区分大小写。 Cseq：Cseq称之为命令序号。它由请求方法和一个十进制序号组成，该序号由请求客户选定，在Call-ID范围内唯一确定。序号初值可为任意值，其后具有相同Call-ID值，但不同请求方法、头部或消息体的请求，其Cseq序号应加l。 Via：该字段用以指示请求历经的路径。 Via字段的一般格式为Via：发送协议方；隐藏参数；生存期参数；多播地址参数；接收方标记；分支参数 其中，发送协议的格式为：协议名协议版本传送层。协议名和传送层的缺省值分别为SIP和UDP。 Contact：用于INVITE，ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息。 Contact字段的一般格式为Contact：地址；q参数；动作参数；失效参数；扩展属性 其中，地址的表示形式和To，From字段相同，扩展属性就是扩展名。动作参数只有两个取值：代理或重定向。失效参数可用秒表示，也可用SIP日期表示。 响应消息格式： 响应消息=状态行 *(通用头部|响应头部|实体头部) CRLF(空行) 消息体】 其中，状态行的格式为：状态行=SIP 版本+状态码+原因短语 即为：Status-Line=SIP-VERSION SP STATUS-CODE SP Reason-Phrase CRLF 其间，状态码是3位整数，指示请求执行的结果。原因短语给出状态码的简短的文字描述，便于使用者理解。 状态码共分6类，第l位数字指示响应类别，后两位表示该类中的具体响应。 (1)lxx(Provisional)：临时响应。呼叫进展响应。表示响应已收到、正处理； (2)2xx(Suecessful)：成功响应(即200 OK)； (3)3xx(Redirection)：重定向响应： (4)4xx(Request Failure)：客户端出错； (5)5xx(Server Failure)：服务器错误； (6)6xx(G10bal Failure)：全局故障。 SIP呼叫流程 SIP终端注册流程 用户在发起呼叫请求的第一步是要在服务器上注册(REGISTATION)，告知服务器该用户能够被访问的SIP地址。下图说明了一个典型的注册过程。在这一过程中，用户Angel向自己网域中的本地服务器SIP注册。各字段内容如下： Via：包含了本地服务器的域名、SIP版本和采用协议； From：表明该注册用户的地址； To：注册过程中也为该用户自己的地址，表示该用户向服务器注册自己； Call-ID：在本地注册服务器中的值应该是相同的，表示所有的用户向服务器注册这一请求是一个相同的会话； Cseq：作用是区分在相同的Call-ID时不同的消息，当用户A在该服务器上注册多个终端的时候，在注册过程中请求和返回的内容是相同的。 注册请求中并不包含消息体，因为注册会话是一个特殊的会话类型。在内容长度字段值也相应的为零。如果注册成功，注册服务器向用户返回的成功信息200 OK，返回信息中的Via，From，To，Call-ID，Content Length是相同的。 另外，Angel用户的信息表明，在处理呼叫Angel用户时，其呼叫将被路由指定到sip：angelSIPsudacom上去。注册时间由Expire字段来限定，以秒为单位表示此次注册有多长时间的有效期。 呼叫建立流程 SIP呼叫信令过程一般可以分为两种方式：两个UA之间直接进行呼叫、通过代理服务器两个UA之间的呼叫。 (1)两个UA之间直接进行呼叫： 当用户Angel向用户Jeanva发出一个INVITE请求时，这一消息包含了Via，To，From，Call-ID，Cseq，Subject以及Content字段，其中To字段和INVITE字段相同，都是被呼叫方的地址。这些字段上的文本附加信息可以被SIP解释器解析，并且可以在被呼叫方的用户终端上显示诸如呼叫者姓名呼叫主题等内容。INVITE在被呼叫方Jeanva以振铃做出反应，同时返回一个状态编码为180的振铃信息给呼叫发起者Angel。如果用户Jeanva对用户Angel发出的INVITE请求作出了应答，则由被呼叫方发出一个200 OK信号返回。当呼叫方Angel收到这个200 OK消息后，向用户Jeanva发出ACK消息表示连接正确建立，当ACK消息发出后，Angel和Jeanva之间就可以进行会话了。 (2)通过代理服务器两个UA之间进行呼叫： 当用户Jeanva在网域bjtu中呼叫网域suda中的用户Angel时，Angel首先向Jeanva所在的网域的代理服务器Proxy发出一个INVITE请求，代理服务器收到请求后将该请求的请求地址改成Jeanva的地址后向前转发，并将自己的地址加入Via字段，同时向Angel返回一个编码为100 Trying的消息，表示正在尝试连接Jeanva。当用户Jeanva接受代理服务器的呼叫后，向服务器发出200 OK确认消息，服务器再将该确认消息转发给呼叫方用户Angel；用户Angel在收到消息之后向服务器发出确认连接信号ACK，服务器在向用户Jeanva转发出确认信号后，呼叫建立。 另外需要注意的是，在这个“接收转发"的过程里，Via字段的值在经过服务器向前转发时，服务器会将自己的主机名加入到Via路径中。Via字段的作用是标明到现在的节点处该消息所经过的路径。在向前传输中每一个接收到请求消息的服务器都需要将自己加入到Via表中。如果服务器监测到Via表中已经存在了自己的主机名时，表明一个环路己形成，向该请求消息发送一个“482”编码的状态返回消息表示监测到环路，因此可以避免一些路由的死循环产生。 呼叫释放流程 呼叫释放过程比较简单，终止请求可以由参与会话的任何一方提出，终止会话时用户需要向对方发出一个BYE请求，在BYE请求得到确认后，由接收方向发送方发送一个确认信号200 OK，整个会话过程便结束，呼叫释放完成。 SDP协议 SDP由IETF和MMUSIC(多方多媒体会话控制)工作组定义。其目的是在媒体会话中传递媒体流信息，允许会话描述接收者参与会话。SDP基本是在Internet上工作。它定义了会话描述的统一格式，但并不定义多播地址的分配和SDP消息的传输，不支持媒体编码方案协商,这些功能均由下层传送协议完成。 SDP包括以下一些方面：会话的名称和目的；会话存活时间；包含在会话中的媒体信息(包括：媒体类型、传输协议、媒体格式、多播或远端(单播)地址和端口)、为接收媒体而需的信息、使用的带宽信息，等。 SDP描述的信息封装在传送协议(本系统为SIP)中发送SDP是一个文本描述，它的每个文本行的简化格式均可表示为：<type>：<value> 一个会话描述由一个会话级描述和若干媒体级描述组成。前者以“V=”开头，直到第一个媒体级；而媒体描述以“m=”行开始直到下一个媒体描述或到整个会话描述结束。一个会话描述包含如下各行内容且固定了顺序，标有*的是可选项： (1)会话描述(共12个，如下表31所示)： (2)时间描述(共2个，如上表32所示)： (3)媒体描述(共6个，如上表33所示)： 在上述会话级部分。如果不被媒体描述中的同名属性或连接信息覆盖，连接(“c=”)和属性(“a=”)可用于这个会话的所有媒体。 RTP及RTCP协议 和SIP一样，RTP也是由IETF发布，是针对Internet上多媒体数据流的一个传输协议，其目的是提供时间信息和实现流同步。RTP用来承载具有实时特性的话音数据，提供端到端的传输服务，这些服务包括负载类型标志、序列号和传递监听，RTP自身不提供任何机制来保证及时传送或服务质量，而是依赖于更低层的服务。在实现流媒体在IP上的实时传送时，要采用相应的实时传输协议，主要有：数据流部分的实时传输协议RTP和用于控制部分的实时传输控制协议RTCP。含有RTPRTCP的流媒体服务协议结构如下图36所示： RTPRTCP并非作为一个单独层，只是作为传输层协议的一部分(但位于UDP、TCP之上)。RTP的实现一般是在应用层组包通过传输层的协议逐层向下传送，它依赖底层的协议来提供RTP包和RTCP包的复用。在传输过程中，首先将流媒体数据打包成RTP包，然后依次将RTP包封装成UDP包及IP包。其过程如图37： RTP、RTCP的数据报的头部格式分别见以下两表： RTP只提供协议框架，开发者可根据具体要求对协议进行扩展。应用程序开始RTP会话时将用两个端口，RTP使用偶数端口来传递数据，RTCP使用比它大1的奇数端口控制流传送，监视网络流量和阻塞。发送方在发送媒体流时由应用程序组帧，在RTP包的包头填上时间戳、序列号、负载类型、源标志符等信息。RTP会给第一个分组一个随机序列号，后续分组的序号顺序递增，接收方在收包后，根据包的序列号重构。在网络中，从发端到接端不同的时延常导致接收方的抖动。 用RTP时间戳信息可进行流间或流内同步，能使接收端时延抖动缓冲区根据分组的时间戳值，对来得太快的分组加上一些附加时延，从而平滑数据发送。接收端还可以根据负载类型按相应的方法对其进行解码，按照正确的速率恢复成原始的实时数据流以回放。上述工作都是在应用程序中完成，RTP本身不管。 VoIP网络电话硬件平台设计 采用USB接口与PC机相连，作为计算机外接设备使用。该设备可通过10/100 Base-T的RJ45接口接入Internet中，完成服务器的搜索、用户的注册，以及语音数据的转换、分组、高层协议封装、UDP封装、IP封装、Mac层封装，并通过网络进行实时传输。 终端设备的功能 一个VoIP终端至少需要以下几部分的支持：信令协议、标准语音编解码和实时媒体信息的传输。 如下图41所示VoIP终端设备功能图。 其中，信令协议使得Terminal-Terminal(终端-终端)、Terminal-Server(终端-服务器)之间得以交换信息。本系统的目标是实现以SIP为信令协议的VoIP电话终端。标准的语音编解码(采用A律G.711)使得通信双方都可以正确解析对方的媒体数据。 实时媒体传输，则使得语音信息可以实时地到达对方终端。 由功能需求，可以确定该IP终端设备的开发流程，如下图所示： VoIP网络电话软件程序设计 一个完整的VoIP通话过程 首先要理解利用终端设备，在IP网上采用SIP协议进行一个完整的VoIP通话的全过程。整个通话流程如下图所示： 可见，这个流程的软件主要完成了SIP、RTP协议的实现和PCM编解码实现。同时，因为涉及到硬件终端，也应包含键盘的扫描电路程序。 选用oSIP作为协议栈 oSIP是按照RFC3261(SIP)和RFC2327(SDP)标准，并使用标准c编写的一个SIP 协议栈。它是一个公开源码的免费协议栈。oSIP协议栈结构简单而小巧，它并不提供高层的SIP会话控制的API，它主要提供一些解析SIP/SDP消息的API和事务处理的状态机。 oSIP支持线程安全，既可以用于多线程的编程模式，也可以用于单线程的编程模式；oSIP 可以用来开发User Agent，IP soft-phone 和SIP Proxy等等。 oSIP结构 oSIP主要包括三大部分的内容：状态机模块、解析器模块和工具模块。 状态机模块的功能：完成对某个事务状态记录，并在特定状态下触发相应的事件或回调函数。 解析器模块的功能：主要完成对SIP消息结构剖析、SDP消息的结构剖析以及URI结构的剖析； 工具模块的功能：提供一些SDP等处理的一些工具。 oSIP的模块结构图如下： 状态机(Finite State Machines)模块 oSIP 状态机(Finite State Machines)主要分为四类，分别为： ICT - Invite Client (outgoing) Transaction NICT - Non-Invite Client (outgoing) Transaction IST - Invite Server (incoming) Transaction NIST - Non-Invite Server (incoming) Transaction ICT 状态机 注： cb_ict_Nxx_received中N 为:3、4、5、6 NICT 状态机 cb_nict_XXX_sent中XXX 为：register bye options info cancel notify subscribe unknown cb_nict_Nxx_received中N 为：2、3、4、5、6 IST 状态机 cb_ist_Nxx_sent中N 为：3、4、5、6 NIST 状态机 注： cb_nist_XXX_ received中XXX为：register 、bye、options、info、cancel 、notify、subscribe、 unknown cb_nist_Nxx_ sent中N 为：2、3、4、5、6 解析器(Parsers)模块 SIP Parser oSIP 的SIP Parser 处理的SIP 头域(SIP Header fields)及其相应的操作功能列表如下： 注：标示“”表示 oSIP 支持该头域(SIP Header fields)解析处理，未注的表示目前还没有解析处理，可能会在后续版本中逐步补充。 SDP Parser SDP 的格式一般为： <type>=<value> type 通常为一个英文字母，其取值如下： Session description v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) b=* (bandwidth information) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t= (time the session is active) r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) 在 oSIP 中处理的type 和相应操作功能如下： 另外，oSIP还包含对SDP包的一些基本操作set, get, init, parse, 2char, free, clone,及对各类type的init和free操作 URL Parser 这里的URL是指SIP中的URI，URI有很多参数格式，在RFC3261中列举了一些比较例子： 在oSIP中处理SIP URI有比较多的操作函数提供，主要有对host, port, username, password, scheme 的get和set，以及对参数的初始化设置和剖析处理。详细函数名称请参考源代码中的url.h。 工具(Facilities)模块 SDP negotiator SDP 协商工具(SDP negotiator)帮助end point 提供协商codec 等功能 Dialog management 对话管理工具(Dialog management)是oSIP 提供的一个比较强大的辅助工具，主要用于有能力应答呼叫的end point。对话管理工具(Dialog management)能够帮助记录请求和响应消息，利用这个工具使end point 能够快速准确的作出应答。 oSIP特点 优点 (1)没有给开发者限定在特定的某个执行模式下，能够使开发者选定一个比较适合自己的模式。 (2)各个模块是相对清晰、独立的，因而去掉某个模块时也比较容易。 (3)其解析器提供了较为完善的API，包含了消息的构造、修改和产生等。 缺点 (1) 目前版本源代码结构、定义比较混乱，并且缺乏文档，阅读比较困难；该问题将在oSIP2中得到改善。 (2)不提供任何快速产生请求消息和响应消息的方法，所有请求消息和响应消息的形成必须调用一组sip message api 来手动组装完成，关于这方面的缺陷，osip作者可能在以后会开发一个eXoSIP 的API来完成。 (3)由于oSIP结构简单，外围相关模块需要用户自己开发，如SIP消息的接收和发送，RTP/RTCP的语音数据的处理等。 oSIP应用结构图 其中： ：初始化 oSIP 和注册CALL BACK 函数； ：添加事件 A; ：执行事务 ：取消事件 A ：解析消息 ：触发 CALL BACK 函数 ：接收/发送消息 A：保存状态 B：接收/发送语音包 oSIP使用概述 初始化oSIP 在使用 oSIP 前必须先初始化oSIP，主要调用函数osip_global_init和osip_init，具体 操作代码如下： 注册CALL BACK 函数 需要注册的 call back 函数主要包含发送消息、结束事务、发送失败、4 个状态机(ICT、 NICT、IST、NIST)相关函数。 注册发送消息的 CALL BACK 函数： 注册结束事务的 CALL BACK 函数： 注册发送失败的 CALL BACK 函数： 注册 ICT、NICT、IST、NIST CALL BACK 函数： Transaction 操作 在注册完CALL BACK 函数后，应用程序可以建立调用oSIP 的解析器和状态机模块的操作，来实现不同应用程序的需求。 oSIP2的改进 oSIP的最新版本是209，结合oSIP2的优点、缺点以及视频会议的需要，本文对其进行了以下修改，以满足视频会议的需要。 增加SIP消息的发送和接收 消息收发的过程包括接收和发送两个过程。接收过程主要包括以下几个步骤(如图57所示)： (1)TCPUDP接收线程从传输层中获得一个SIP消息，这个SIP消息是经过编码的，它将会被解码并生成一个该消息的对象。 (2)若该消息是请求消息，它将被发往发送应答数据库中；若该消息是应答消息则发往发送请求数据库。然后数据库会检查这个消息是否是重发的消息。若是的话，这个消息将会被抛弃，然后这个消息接收的过程将结束；若不是，则转入下一个过程。 (3)消息被发送到消息队列中等待应用层接收处理。 (4)应用层通过协议栈的应用编程接口(API，Application Programming Interface)函数从消息队列中获得该消息。 对于发送过程，它主要包括以下几个步骤(如图所示)： (1)应用层生成一个对接收到的消息的应答或发出一个新的请求。 (2)若是应答消息，应用层通过协议栈的API函数将该应答消息发送到发送应答数据库中；若是请求消息，则发往发送请求数据库。 (3)该应答消息或请求消息被发送到发送消息队列中等待。 (4)TCPUDP发送线程从队列中取得该应答消息，然后通过网络发送出去。 在协议栈中，建立了2个UDP发送线程和2个TCP接收线程，如下图5-9所示： 对oSIP2进行分层封装 本文根据上面提出的协议栈模型，兼顾协议栈的可扩展性以及可重用性，对SIP协议栈组织分为应用接口层、对话层、SIPSDP消息编解码解析层和传输层4个层次，每层提供相应的API。下层的API供上层调用。 (1)应用接口层 提供高层应用的API接口，针对视频会议的需要，每个基本功能对应一个API，这为视频会议上层的开发提供方便，同时使上层开发人员不需要关心底层，SIP协议栈的升级，只要接口不变，上层开发代码亦不需要修改。提高了系统的可维护性。本层需要新增代码。 (2)对话层 创建对话(Dialog)管理对话内的所有SIP消息，对这些消息进行处理，创建请求并生成响应。本层也创建并管理事务对象。每个事务对象负责维持状态，收发消息和使用传输层重传消息。本层提供的API可以创建、终止和修改对话，还可以处理对话内的不同消息。 由于oSIP2只做到了transaction层次的协议过程解析，缺少call、session、dialog等过程的解析，所以本层需要增加对call、session、dialog的解析，同时提供丰富的回调函数。 (3)SIPSDP消息编码解析层 SIP请求和响应消息是基于文本的消息，本层处理SIP消息(包含SDP会话描述信息)的编码和解析。本层提供的API可以方便地操作SIP消息和SDP描述符的各个部分。 oSIP2提供了丰富的消息编解码函数，所以只需作少许改动，就可实现。这也正是为什么本文选择oSIP2为基础开发的一个很重要的原因。 (4)传输层 管理套接字(SOCKET)和网络连接，可以使用面向连接和无连接的协议，如TCP或UDP来传输数据，本层提供收发消息的简单API。本层功能需要新增，上节已描述，主要使用UDP实现。 优化SIP消息的解析策略 首先是SIPSDP解析。本协议栈使用了一种“懒汉”解析策略，当从网络上收到一个原始的SIP消息时，消息被解析成很多“关键字和关键字值对”，如图5-10所示。关键字是请求行或SIP头域名，关键字值是没有解析的请求行和头域值。在应用程序要访问请求行或某个头域时，才会对其完全解析。这种处理方法极大地提高了那些需要处理繁重网络流量的应用，比如SIP代理服务器或者网关的效率。在这类应用中，对SIP消息的大多数头域和消息体都不感兴趣，对这些头域不需要进行解析，与解析全部头域相比，可以大大提高效率。而且，这也提高了程序的稳定性，对于不支持的头域不进行处理，实现对程序的透明支持。对于SIP消息体的解析，如果是SDP描述符，则一次完全解析；对于其他的类型，则只提供原始的字符串，不进行解析。 544 扩充回调函数 从网络上接收到SIP消息时，本协议栈采用回调函数的方式为应用程序提供接口。采用这种方式，用户可以很方便地使用本协议栈，在回调函数中实现自己的应用逻辑，就可以实现自己的应用。因此，本文对oSIP2协议栈增加了更多的回调函数，扩充了对外的接口，提供的这些回调函数，充分考虑到了在视频会议中的应用。 545 增强并发处理 由于SIP的各种服务器可能同时收到多个呼叫请求， 因此需要并发处理机制以支持多个呼叫的实时处理。为此，我们采用了两级并发机制，第一级并发为层间并发， 即A、B、C、D各层的分层处理：第二级并发为层内的多线程并发。下面以有状态的代理服务器为例， 讨论SIP协议栈中多线程对第二级并发的支持。 (1)二级并发机制 如图5-11所示，代理服务器的B、C、D各层分别设置多个负责SIP消息处理的线程。例如， D层可根据用户或应用程序的要求设置多个Proxy Client和Proxy Server线程。每个Proxy Client和Proxy Server线程无限循环地从CD的响应和请求队列中读取消息并处理。这样， 线程的数目是固定的，与处理呼叫个数无关。而且，由于一个线程负责多个呼叫，一个线程出错时，可能影响多个呼叫， 软件错误限制区较大。线程的数目、同步机制以及各线程的 优先级都会对整个协议栈的性能造成一定的影响。因此，需对上述各种因素进行调整，使协议栈达到最佳处理性能。 (2)一级并发机制 如图5-12所示，由于SIP的各种服务器可能同时收到多个呼叫请求，因此需要并发处理机制以支持多个呼叫的实时处理，为此我们采用了一级并发机制，一个呼叫由一个线程完整负责，可避免同步问题，软件错误限制区仅限于各呼叫对应的线程，即当一个线程出错时，只影响该线程负责的呼叫，不会影响其他呼叫，提高了系统的可靠性。 然而，当呼叫较多时，一级并发机制使整个协议栈的线程个数随呼叫个数相应增加，导致操作系统调度和管理线程的负荷增大，造成协议栈处理能力大幅度下降。 综上所述，本文认为SIP协议的不同实体可采用不同的多线程并发机制。对于代理服务器、重定向服务器和注册服务器，由于处理的呼叫多，实时性要求高，宜采用二级并发机制。用户代理，由于面向终端用户，处理呼叫较少，宜采用一级并发机制。 SIP消息的解构及RTP数据的收发 (1)SIP消息的构造 利用oSIP提供的API函数对osip_message进行操作，通过调用解析模块的API，完成SIP消息的构造与解析。其过程大致分为以下几步，如下图所示： 初始化结构体； 调用SIP Parser API为结构体各成员赋值； 调用osip_message_clone函数创建结构体副本(以备重发)； 调用osip_message_to_str 函数将结构体转化为消息文本： 若发送成功，则释放结构体。 (2)SIP消息的解析 SIP消息的解析大致可分