基于SIP协议的forking功能的研究和实现

摘要：SIP协议是用于建立、更改和终止呼叫的应用层协议，在IMS系统中使用非常广泛。而Fork是SIP中一个非常实用非常重要的功能，本文阐述了在Fork功能的基本原理，并在已有的SIP架构上，分析了此功能的实现方法和具体的流程。

关键词：SIP； TU； Fork

中图分类号：TP393.0

文献标识码：A

DOI： 10.3969/j.issn.1003-6970.2015.07.025

0 SIP简介

SIP（会话初始协议，RFC3261）是IETF定义的通过IP网络建立和管理多媒体会话的协议，它采用的是众所周知的客户机服务器模式，它借鉴了SMTP（简单邮件传送协议，RFC2821）以及HTTP（超文本传送协议，RFC2616）的原理，而这两个协议是因特网上最成功的协议，同时，SIP是一个基于文本的协议，这意味着它更易于扩展、纠错和构建各种业务。因此，在IMS（IP多媒体子系统）中，选择SIP作为其会话控制协议，更易于建立具有更大承载能力的业务。

根据协议标准定义及实际研制经验，协议平台的SIP协议分析划分为以下几部分内容： SIP事务用户层（TU，Transaction User），事务层（TR，TRansaction），传输层（TP，TransPort），编解码模块（SIP PARSER/SDPPARSER，SIP协议编解码及SDP编解码），信令压缩模块（SIGCOMP）几个协议主体部分。除了这几个协议主体以外，SIP还需要实现和上层业务、数据库以及底层承载之间的接口，方便进行数据以及消息的交互。

SIP协议的TU层是SIP协议主体的重要组成部分，它的功能包含几个方面：（1）负责SIP消息到上层应用进程的消息分发；对上层应用屏蔽底层协议实现和分布式处理的细节；（2）对于需要创建对话的，维护对话的生命周期，管理对话的事务列表；（3）完成UAC， UAS或者pro xy的协议栈行为。

SIP采用的是一种offer/answer模型来描述会话。一个UA发起一个会话描述，称为offer，另一个UA以另一个会话描述来进行响应则为answer，一个offer/answer在一个Dialog上下文中进行交互，因为在具体实现SIP协议栈时，TU需要建立数据区来维护对话Dialog的相关信息，如图1所示，TU是通过建立leg模型来维护dialog的，TU建立的数据区称作leg，leg将会保存对于会话创建、会话释放，处理请求、处理响应所需要的一些关键信息，而这些信息是通过SIP消息从相应的头部中进行提取，和会话相关的主要头部From，To以及Call-ID中的信息将都会保存在leg中。

数据区的创建根据协议栈的行为分为UA和proxy两种情况。

Proxy方式下会存在一人一出两个Leg对象，人呼侧由TU收到事务层的初始请求而创建人呼侧Leg对象，消息通过人呼侧Leg处理后上报上层应用，上层应用处理结束后，转发初始请求到TU的出呼侧，TU进而创建出呼侧Leg对象以及下发SIP消息。

UA方式下，作为被叫网元，TU协议栈收到事务的初始请求后，创建人呼Leg后，通过初始请求消息上报上层业务，上层业务处理完业务逻辑后，通过人呼Leg回送响应到事务层。后续请求和响应都是通过人呼Leg传送。作为主叫网元，上层应用调用发送初始请求接口到TU，TU创建出呼侧Leg后，初始请求消息通过该Leg发送至事务层，后续请求和响应都是通过出呼侧Leg传递。

1 forking功能

fork即常说的分叉，一个请求可以分叉为发往多个目标地址的请求。假定B用户为一号多机用户，即一个SIP用户可以同时在很多终端上注册，每种终端可以实现不同的功能，比如便携PC支持视频而固定SIP电话可能功能简洁，B用户多个终端同时在线，当A用户呼叫B用户时，那么B用户的多个终端都会收到呼叫请求，它的任意终端都可以去响应这个呼叫。A最终会选择一个终端创建会话。

在IMS中实现fork功能涉及到的网元类型分为终端（UA行为）以及服务器（proxy）行为，根据协议的描述，梳理不同网元的处理原则。

1.1 终端处理原则

（1）请求

根据协议的描述，只有初始对话（独立事务）请求才会发生fork。终端可以在初始请求INVITE的码流中的通过添加Request-Disposition头部中指示进行fork的相关处理。同时，当被叫终端注册了多个时，主叫终端可以添加Accept-Contact，Reject-Contact参数，指示选择符合用户偏好的被叫以及优先级更高的被叫。

（2）响应

当fork发生时，多个被叫终端都会对主叫产生响应，未创建对话前，主叫终端可以接受或拒绝任何被叫终端的Fork应答，如果终端拒绝fork临时应答，那么必须发送cancel或者bye请求，这些请求是针对每个终端即每一个fork的分支都需要发出。

主叫终端如果接收到被叫终端一个fork分支的成功应答即2xx响应，开始创建会话；应该释放其他fork分支的早对话和非早对话，具体释放的方式根据各个fork分支的不同而不同。其中对于已经收到了临时响应的fork分支，不管是否建立起了早对话，则发送CANCEL请求来释放；对于没有收到任何的临时响应的fork分支，则不能发送CANCEL请求，通过TU设置的保护定时器超时，来释放该分支的相关资源。

主叫终端只能收到一条最终响应，如果收到2xx响应，则建立对话，如果为2xx以上的响应，则认为无法建立呼叫，则需要释放呼叫。

1.2 处理原则

（1）请求

提取码流中fork和用户喜好相关的字段，处理fork请求，比如到被叫的归属的服务器，需要将初始INVITE请求分叉为多个发送到被叫终端，对于非初始请求，需要进行转发。

（2）响应

立即转发除100（Trying）以外的任何临时响应。立即转发能成功建立对话的第一条2xx成功响应，如果其中任意一个地址接收呼叫，该网络服务器应该向其它地址发送CANCEL消息，如果由于网络时延而导致在服务器接收到多个200消息，服务器应当将后续的200消息拒绝掉，不应当后向转发，这样能保证只有一个终端能够建立对话。

对于3xx类以上的非成功响应，根据响应码的具体含义进行处理，比如3xx需要优先传到主教终端进行重定向，而对于4xx、5xx、6xx等非成功相应，即先保存这些响应，如果最后没有收到任何2xx响应，则根据协议规定的优选的原则选择响应码发送到主叫终端，结束整个会话。

2 SIP中fork的实现原理

SIP协议实现fork的基本逻辑功能：包括fo rk呼叫状态维护，管理多个临时响应创建的对话，并在会话创建之前维持多个早对话出/人呼侧消息的正确关联关系。上层业务维护多个Contact的上下文与分叉呼叫之间的关系，分别对早对话进行承载控制。

2.1 确定是否发生fork

当被叫终端注册了多个Contact地址时，SIP协议需要去提取码流中的相关字段，通过Accept-Contact，Reject-Contact参数确定好被叫目标集，并按照优先级将多个被叫终端进行排序，进一步的提取Request-Disposition头部的关键信息，对是否需要进行fork进行确定，该头部的内容如下：

proxy-directive=”proxy”

fork-directive="fork"/"no-fork"

parallel-directive="parallel"/"sequential"

其中proxy-directive确定当前的网元是否为proxy，fork-directive是用来指示是否需要fork，当指示为”no-fork”时，虽然被叫有多个，但是初始请求只会发送给优先级最高的被叫终端并不会产生分叉，如果指示为”fork”时，则进一步的读取parallel-directive指示的值，parallel-directive若为“parallel”为并行fork，并行fork则需要被叫归属的服务器将初始的INVITE请求同时发送给多个被叫终端，既并行呼叫；若为“sequential”为串行fork，串行fork则不需要服务器将初始请求同时发送给多个被叫终端，而是逐个的发送，先发给第一个优先级最高的被叫，如果接通，则不需要进行后续处理，如果没有成功接续，则继续发送给第二个被叫，依次类推。

2.2 TU中会话的维护

从前面SIP的简介我们得知，TU需要去维护会话dialog，而对于dialog的维护，TU需要创建数据区Leg去保存相应的信息，fork情况下，可能存在同时发起多路fork分支的呼叫，而多个被叫终端的对话信息是不完全相同的，如果把所有的信息都保存在简单情况下的一个Leg数据区里，则容易引起一些误操作，逻辑很不清楚，所以，可以采用TU维护多对数据区的方式来解决。

普通呼叫情况下，SIP的TU层只需要维护人呼侧和出呼侧的一对Leg即可，这样所有的消息都通过这一对Leg来进行关键信息的记录以及转发。而fork情况下，由于终端有多个，而每个终端都可以传送不同的请求和响应到主叫终端，为了对每个终端的信息进行彼此独立的进行保存，TU为每一个终端建立对应的数据区Leg，具体如图2所示，图2和图1比较可以看出，fork情况下，TU的人呼侧和出呼侧分别有多个Leg，而且人呼侧和出呼侧是一一对应的，比如In Leg（0）和Out Leg（0）是对应第一个被叫终端，用来记录第一个别叫终端和主叫之间的会话信息，并进行这一分支呼叫的消息转发，而In Leg（l）和Out Leg（l）是为主叫终端和第二个被叫终端服务的。当然，不管是fork的第一个分支还是第二个分支和主叫发生联系，这都是属于当前的这一个完整的会话，因此两路分支之间也可能有信息的交互，此时可以通过CALL这样的一个空间来保存两者的数据区索引，方便通过一个人呼叫的Leg能很快的访问到另一个分支的Leg。

3 具体流程

SIP的具体流程要分为并行和串行两种情形，分别进行介绍：

3.1 并行流程

在并行流程中主叫的请求会同时被发送给两个别叫用户，具体流程如图3所示，其中User AgentA为主叫用户，User Agent B，C为被叫用户，Proxy Server是IMS系统中的某个具体的网元，是服务器，主要是起到消息转发以及完成fork功能的作用。

各步骤的具体含义如下：

主叫用户A发起请求INVITE到服务器，对应图上消息（1）；

假定此服务器是被叫归属地的网元，它能检测到有多个被叫联系contact地址，同时通过Request-Disposition确定为发生并行fork，于是，向两个被叫用户B和C发起INVITE请求，对应图上消息（2）和（3）；

两个被叫用户收到INVITE请求后，提示用户并振铃，都发送180（ Ringing）消息通过服务器传给主叫用户，主叫用户能同时听到两个被叫的回铃音，对应图上消息（4）（5）（6）（7），此时，两路别叫的180消息中的To头部的tag值是不一样的，这样服务器中实现SIP的TU层就可以维护两个leg，来保存两路的不同会话信息；

两个被叫用户都会送响应，上图中被叫用户B接通呼叫，产生2000K的应答，而被叫用户C则回送4XX消息，显示忙，服务器接收到两个被叫的不同应答，需要进行处理，它主动地对被叫用户C回送ACK，以结束被叫用户C之间的呼叫，同时将被叫用户B的200 OK转发到主叫侧，具体对应图上的（8）（9）（10）（11）；

主叫收到成功响应后，回送ACK消息到被叫用户B予以证实，呼叫建立，对应图上的（12）和（13）；

主叫挂机，发送BYE消息，被叫回应200 0K响应，整个通话结束，对应图上的（14）（15）（16）（17）。

3.2 串行流程

在并行流程中主叫的请求会按照优先级先后发送给两个被叫用户，具体流程如图4所示：

各步骤的具体含义如下：

主叫用户A发起请求INVITE到服务器，对应图上消息（1）；

假定此服务器是被叫归属地的网元，它能检测到有多个被叫联系co ntact地址，同时通过Request-Disposition确定为发生串行fork，就需要根据两个被叫用户的优先级，优先级通过Accept-Contact，Reject-Contact等参数按照RFC3841协议规定的原则进行权值的计算，假定用户B的优先级高于用户C，服务器现将INVITE转发给用户B，对应图上消息（2）；

被叫用户B收到INVITE请求后，提示用户并振铃，并发送180（Ringing）消息通过服务器传给主叫用户，主叫用户能听到被叫用户B的回铃音，对应图上消息（3）（4）；

被叫用户B忙，因此回送4XX消息，服务器接收后，由于是fo rk情况，因此不将此失败响应发送给主叫用户，直接给被叫用户回送ACK确认，并将此初始请求消息INVITE继续发送到第二个用户C，对应图上消息（5）（6）（7）；

被叫用户C收到INVITE请求后，提示用户并振铃，并发送180（Ringing）消息通过服务器传给主叫用户，并进一步的发送200 0K响应接续通话，对应图上消息（8）（9）（10）（11）；

主叫收到成功响应后，回送ACK消息到被叫用户B予以证实，呼叫建立，对应图上的（12）和（13）；

主叫挂机，发送BYE消息，被叫回应200 0K响应，整个通话结束，对应图上的（14）（15）（16）（17）。

4 结束语

总体来说，fork功能的实现是比较复杂的，SIP协议层面要考虑非常多的异常情况，比如所有被叫用户都无法建议呼叫、或者两个被叫同时回送2000K成功响应等情况，而且整个功能的完成，还需要底层以及上层业务的配合，比如考虑如何对两个被叫都建立媒体通道等问题，这些在本文中没有阐述，本文主要介绍的是在现有的SIP架构的基础上，通过TU层维护多路呼叫的数据区的方法去实现fork功能，目前此方案已经在企业中采用并实现。