摘要：SIP协议是用于建立、更改和终止呼叫的应用层协议，在IMS系统中使用非常广泛。而Fork是SIP中一个非常实用非常重要的功能，本文阐述了在Fork功能的基本原理，并在已有的SIP架构上，分析了此功能的实现方法和具体的流程。
关键词：SIP; Fork; TU
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传递。
一、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响应，则根据协议规定的优选的原则选择响应码发送到主叫终端，结束整个会话。
二、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。
