平台化思路下SIPTU的设计与实现

曾丽君　魏丽　闵芳

摘要：会话初始协议（SIP）是一种应用层控制协议，在IMS系统中应用广泛。研究了一种平台化SIP的实现方案，这种方案使得SIP在不同的产品中能屏蔽上层和底层的实现，通过提供不同的接口层给上层应用使用，使得SIP更具通用性。基于此种思路，进一步实现了SIP分层结构中非常重要的组成部分SIP TU的基本功能和关键技术，具体包括UAC、UAS以及proxy行为的支持等。

关键词：SIP TU UA proxy

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9416（2016）09-0179-02

近几年来，移动网和互联网有效的结合起来，既能向人们提供无处不在的多媒体业务，也能对通信网络实施有效的管理。为了实现通信以及多媒体的相关业务，3GPP标准定义了一些协议来配合业务的实现，涉及到的常用协议有SIP协议（协议标准为RFC3261），H248协议（协议标准为RFC3525），DIAMETER协议（协议标准为RFC3588）等。目前这些协议应用的项目有固网产品（包括软交换、分组交换服务、SBC、BGW等），IMS产品（包括CSCF，MGCF，PDF，HSS等）；移动核心网产品（CDMA2000、MSCe，WCDMA、TD-SCDMA等）；由于这些协议应用的产品众多，则可以采用平台化的设计思路来对这些协议进行实现，以便人力共享，经验共享，成果共享，在企业中也能准确快速的响应产品需求。

众多协议中，SIP协议定义的目的，是为了建立、修改和终止一个多媒体的通话，它是信令的控制协议[1]，和其他协议配合，共同实现IMS中相关通信业务。

1 SIP平台实现架构

基于平台化的设计思路，遵从IETF标准组织的RFC3261协议的描述对SIP协议进行构建。其整体架构如图1所示。

如图1所示，协议平台主要由两部分组成，第一部分是协议平台的主体实现部分：SIP事务用户层（TU，Transaction User），事务层（TR，TRansaction），传输层（TP，TransPort），以及协议涉及到的配合模块：编解码模块，操作维护模块等。另一部分为协议接口层，协议接口层是为了屏蔽外部接口及功能的变化而由协议平台实现的封装部分，此部分设计目的在于最大程度的对可能使用SIP平台的外部需求进行整合统一，使外部功能变化的波及最大程度的限制在接口层中，以减少对协议平台主体实现的冲击，提供良好的可扩展性。具体包括TU与上层业务用户的接口部分（TUUI，TU User Interface）；以及SIP与数据库之间的接口部分（SIP DB），SIP与操作系统支撑之间的接口部分（SIP OSS），SIP与底层IP承载之间的接口部分（SIP BRS），SIP与操作维护OMC之间的接口部分（SIP OMC）。

2 TU总体介绍

2.1 TU在SIP平台中的位置

平台化的思路主要针对是不同的上层应用，而SIP TU又是直接和上层应用进行交互的，所以平台化思路下，SIP TU的实现就成了最为核心的部分，SIP TU设计的合理化，可以是的SIP的应用更加通用化。TU模块在整个SIP平台系统中的位置如图2所示。

与TU模块相关的各构件及接口有：（1）编解码模块：SIP是一个基于文本的协议，底层传输的都是字符流，编解码模块完成SIP信令字符流形式到结构化的转换（解码）和结构化SIP消息到字符流形式SIP消息的转换（编码）。（2）操作维护模块：用以协助解决和规避SIP平台运行过程中可能遇到的问题，并在发生故障的时候予以警示和提供收集定位问题相关信息的手段。（3）SIP事务层[2]：事务层处于TU层下面，服务器事务负责从传输层接收请求消息，并传递给SIP TU，同时也负责从SIP TU接收响应，并传递给传输层发出。（4）SIP传输层：正常情况下，传输层从底层承载获得消息后，都是传送给事务层，某些情况下，SIP作为无状态代理，协议平台所做工作仅仅是进行消息的转发，此时TP和TU之间会直接进行交互。（5）上层应用：SIP平台的使用者，不同的网元上层应用所实现的业务不同，对于SIP平台而言，综合考虑使用网元的应用情况，提供对应的接口供上层应用使用，比如业务进程的注册接口，上行消息的上报接口，下行消息的发送接口，不同功能的信息传递接口等。这样实现后，上层应用对于SIP的内部实现是不可见的，只是通过接口来SIP之间进行交互。

2.2 TU模块功能划分

2.2.1 进程管理功能

SIP TU层功能较多，因此将其设计为单独的一个模块，单独的一个进程，进程管理功能负责分发支撑的各种消息到各个不同的子模块的分发入口函数中，这样使得对于和上层以及事务层交互的消息的处理都很独立很清晰。

2.2.2 TU层协议功能

根据协议要求需实现的功能包括[3]：（1）完成UAC的功能，主动创建请求并处理对应的响应。（2）完成UAS的功能，接收请求，检查请求并对请求中的方法进行识别，创建对应的应答；（3）有状态和无状态proxy的支持，能正确的对消息转发，有状态时能正确的提取参数维护状态机。（4）会话管理，会话INVITE的传输和终结，通过状态机修改和管理会话参数。（5）基本功能：路由处理、路由重选、路由刷新等。（6）支持SIP REGISTER方法、SUBSCRIBE方法、REFER方法、OPTIONS请求等。（7）数据区的保活，容灾和主备倒换机制的支持等。

3 TU关键技术

第三部分从总体上对TU层在SIP协议平台中的作用进行了说明，接下来详细的介绍以下TU层的几个关键实现技术。

3.1 TU数据区机制

无论SIP是有状态的proxy或者是UA情况下，为了维护一个对话，都必须保留消息中的先关信息，SIP平台机制中是通过在TU层建立数据区来保存对话的相关信息，这个数据区我们就用Leg来进行表示，Leg对象表示一个半呼叫分支[4]。TU层通过Leg来接受SIP消息或者发送SIP消息，同时TU通过Leg来保存对话的相关信息。具体的Leg模型如图3所示。

Proxy方式下，主要是实现消息的转发，因此会存在一入一出两个Leg对象，入呼侧Leg由TU收到事务层的初始请求而创建，TU层提取请求消息中的关键信息进行保存，TU进一步的将此消息上报上层应用。到了出呼测，TU接收到上层应用发送的初始请求进而创建出呼侧Leg对象，提取关键信息进行存储后，下发SIP消息到事务层。UA方式下，如果是UAS，TU协议栈收到事务的初始请求后，创建入呼Leg后，通过初始请求消息上报上层业务，上层业务处理完业务逻辑后，通过入呼Leg回送响应到事务层。后续请求和响应都是通过入呼Leg传送。如果是UAC，上层应用调用SIP平台的接口发送初始请求到TU，TU创建出呼侧Leg后，初始请求消息通过该Leg发送至事务层，后续请求和响应都是通过出呼侧Leg传递。

通常情况下，存储在Leg中的对话状态信息由对话ID、本地序列号、远端序列号、本地URI、远端URI、远端目的地、路由集、对话状态等组成，这些信息也是通过收到的请求或者响应进行赋值和修改。以入呼侧Leg为例，比如SIP平台收到请求后，SIP TU会对收到的消息进行编解码，这样就能准确的获取到消息流中各个头部来保存，比如远端目的地通常从请求消息的Contact消息的URI获取，对话ID由Call-ID、From头部中的tag值以及To头部中的tag值组成；本地序列号为空；远端序列号从CSeq头部中获取，远端URI设置为From消息头中的URI，本地URI设置为to消息头中的URI，路由集通过route头部获取。同样，对于出呼侧Leg信息的提取也是类似处理。

3.2 UAC行为的支持

UA是SIP的一个重要角色，当作为UAC发出请求时，请求消息会通过一些代理服务器被转发到UAS，而UAS产生一个响应后，响应消息会以同样的方式被转发到UAC。因此，对于UAC的基本行为包含几个方面：产生请求消息、请求消息的发送以及响应消息的处理。

（1）产生请求消息：由UAC产生一个有效的SIP请求消息，首先要包含的是请求行Request-URI，其次需要包含必选的头字段：To、From、CSeq、Call-ID、Max-Forwards和Via字段，当然也可以包含用于SIP扩展的一些字段，比如Require头和Supported头等。因此，对于TU而言，要主动的产生一个消息，就要去构成这些字段，其中Request-URI和To头部填写的是目标地址，通常为目的用户已注册的公用地址，可以通过网管上配置的数据获取。From消息头填写的是发送者本身的地址，同时需要添加tag参数用来标识对话。CSeq由一个请求方法和一个序列号构成，请求方法和对应的请求消息类型一致，序列号为随机产生的一个整数。Call-ID是用来将消息分组的唯一标识，SIP平台采用一定的方法随机生成Call-ID，保证全局唯一。Max-Forwards填写为典型值70。Via头字段主要是标识了传输协议以及响应消息应该发往的地址，因此需要将当前SIP协议栈的地址添加到Via中去，同时Via头字段必须包含一个branch参数来标识当前请求所建立的事务，对于branch参数的生成也需要做到全局唯一。（2）请求消息的发送：主要是确定请求消息发送的目的地，对于UAC而言，可以有一个预置的路由集，这个通过本地策略进行配置，代表的是UAC希望请求在到达目的地之前途径的中间节点的集合，读取配置将此路由集放在请求消息的Route头中。除了通过本地策略以外，还可以通过DNS查询来获取请求需要发往的IP地址和端口。（3）响应消息的处理：UAC还需要对它所发出的请求的响应进行处理，这些响应可能是成功响应，也可能是临时响应或者是错误响应等，TU对响应消息的处理主要依赖于请求方法，但也有一些通用的处理原则，比如消息在事务层出错，无法到达TU层，TU定时器超时后，收到的为408的超时响应。

3.3 UAS行为的支持

SIP支持UAS的行为，所做的工作主要是处理请求以及针对请求的情况，产生对应的响应，具体包含以下情况。

（1）对请求进行检查：UAS收到请求后，可以对请求中的方法进行识别，比如如果不支持某种请求方法，则需要回送一个405（不允许的请求方法）响应。同时还要检查Request-URI和To头部以确定自己是否是这个请求的目的地，如果不是，就可拒绝从而产生一个403（禁止）响应。（2）对消息内容进行处理：UAS要检查消息体和描述消息体内容的头字段，主要涉及到的头字段有Content-Type（指示消息体类型）、Content-Language（指示语言）、Content-Encoding（指示编码）等字段进行检查。（3）产生响应：除了对请求检查出错回送对应的异常响应以外，针对部分请求可以发送临时响应，比如INVITE请求，可以回送100（正在尝试）、180（振铃）等临时响应。但是成功或者失败的最终响应只有一个。

3.4 proxy行为的支持

SIP平台除了实现UA的角色外，还可以实现网络代理服务器proxy的角色，此时，SIP平台作为一个中间实体，正常情况下，请求和响应不是终结在SIP平台，则SIP平台所做的主要工作主要实现请求和响应的转发，此时对消息的转发可以工作在有状态模式下，也可以工作在无状态模式下。

无状态模式下，SIP平台只是根据请求消息进行简单的路由分析和路由决策，然后直接将消息发送到下个目的地。有状态模式下，TU层会通过维护状态机来维护整个对话，对于请求和响应，会建立Leg来存储会话的相关信息，这些会话信息的存储将会影响它对后续的、与先前接收的某一请求相关的消息的处理。

上述TU对于UAC、UAS、proxy等关键技术涉及到TU对各种正常以及异常流程的支持和处理，下图4简单描述建立SIP会话的基本流程图，进一步明确TU的这几项功能。

图4中，主叫用户A和被叫用户B都是支持SIP业务的终端，发起会话时，主叫A充当UAC的角色，根据生成请求的原则产生请求消息INVITE。Proxy代理服务器接收到消息，对于INVITE消息则在有状态模式下进行处理，保存该消息的相关信息，并将消息转发至被叫用户B，被叫为UAS角色，根据收到请求的相关信息产生临时响应180及最终响应200 OK，建立呼叫。

4 结语

在SIP平台机制下，对于上层应用都是屏蔽的，而SIP的内部机制中，对于协议规定的基本功能都是满足的，上层应用可以根据网管上的配置，来选择是作为UA的角色还是作为proxy的角色，协议平台的TU层会根据配置建立数据区进行对应的处理，这样就实现了同一套代码的SIP平台能应对IMS系统中的多个网元，比如CSCF，PSS，MSCe等。协议平台通用性增加，可维护性也大大提升，目前此设计在很多大型的通讯软件中都获得了应用，效果良好。

参考文献

[1]Rosenberg J.， Schulzrinne H.， Camarillo G.， Johnston A.， Peterson J.，Sparks R.， Handley M. and Schooler E. RFC 3261，SIP： Session Initiation Protocol[s].June 2002.

[2]周海华，边恩炯.SIP原理与应用[M].北京：机械工业出版社，2006：45-65.

[3]毕厚杰，李秀川.IMS与下一代网络[M].北京：人民邮电出版社，2005：105-119.

[4]望玉梅，董文宇，周胜.IMS：IP多媒体概念和服务[M].北京：机械工业出版社，2007：289-299.