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

《基于sip协议的forking功能的研究和实现》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、基于SIP协议的forking功能的研究和实现　　摘要：SIP协议是用于建立、更改和终止呼叫的应用层协议，在IMS系统中使用非常广泛。而Fork是SIP中一个非常实用非常重要的功能，本文阐述了在Fork功能的基本原理，并在已有的SIP架构上，分析了此功能的实现方法和具体的流程。　　关键词：SIP;Fork;TU　　SIP简介　　SIP(会话初始协议，RFC3261)是IETF定义的通过IP网络建立和管理多媒体会话的协议，它采用的是众所周知的客户机服务器模式，它借鉴了SMTP(简单邮件传送协议，RFC2821)以及HTTP(超文本传送协议，RFC2616)的原理，而这两个协议是因特

2、网上最成功的协议，同时，SIP是一个基于文本的协议，这意味着它更易于扩展、纠错和构建各种业务。因此，在IMS(IP多媒体子系统)中，选择SIP作为其会话控制协议，更易于建立具有更大承载能力的业务。　　根据协议标准定义及实际研制经验，协议平台的SIP协议分析划分为以下几部分内容：SIP事务用户层(TU，TransactionUser)，事务层(TR，TRansaction)，传输层(TP，TransPort)，编解码模块(SIPPARSER/SDPPARSER，SIP协议编解码及SDP编解码)，信令压缩模块(SIGP)几个协议主体部分。除了这几个协议主体以外，SIP还需要实现和上层

3、业务、数据库以及底层承载之间的接口，方便进行数据以及消息的交互。　　SIP协议的TU层是SIP协议主体的重要组成部分，它的功能包含几个方面：(1)负责SIP消息到上层应用进程的消息分发;对上层应用屏蔽底层协议实现和分布式处理的细节;(2)对于需要创建对话的，维护对话的生命周期，管理对话的事务列表;(3)完成UAC，UAS或者代理proxy的协议栈行为。　　SIP采用的是一种offer/ans，To以及Call-ID中的信息将都会保存在leg中。　　数据区的创建根据协议栈的行为分为UA和proxy两种情况。　　Proxy方式下会存在一人一出两个Leg对象，人呼侧由TU收到事务层的初

4、始请求而创建人呼侧Leg对象，消息通过人呼侧Leg处理后上报上层应用，上层应用处理结束后，转发初始请求到TU的出呼侧，TU进而创建出呼侧Leg对象以及下发SIP消息。　　UA方式下，作为被叫网元，TU协议栈收到事务的初始请求后，创建人呼Leg后，通过初始请求消息上报上层业务，上层业务处理完业务逻辑后，通过人呼Leg回送响应到事务层。后续请求和响应都是通过人呼Leg传送。作为主叫网元，上层应用调用发送初始请求接口到TU，TU创建出呼侧Leg后，初始请求消息通过该Leg发送至事务层，后续请求和响应都是通过出呼侧Leg传递。　　一、forking功能　　fork即常说的分叉，一个请求可

5、以分叉为发往多个目标地址的请求。假定B用户为一号多机用户，即一个SIP用户可以同时在很多终端上注册，每种终端可以实现不同的功能，比如便携PC支持视频而固定SIP电话可能功能简洁，B用户多个终端同时在线，当A用户呼叫B用户时，那么B用户的多个终端都会收到呼叫请求，它的任意终端都可以去响应这个呼叫。A最终会选择一个终端创建会话。　　在IMS中实现fork功能涉及到的网元类型分为终端(UA行为)以及代理服务器(proxy)行为，根据协议的描述，梳理不同网元的处理原则。　　1.1终端处理原则　　(1)请求　　根据协议的描述，只有初始对话(独立事务)请求才会发生fork。终端可以在初始请求

6、INVITE的码流中的通过添加Request-Disposition头部中指示代理进行fork的相关处理。同时，当被叫终端注册了多个时，主叫终端可以添加Accept-Contact，Reject-Contact参数，指示代理选择符合用户偏好的被叫以及优先级更高的被叫。　　(2)响应　　当fork发生时，多个被叫终端都会对主叫产生响应，未创建对话前，主叫终端可以接受或拒绝任何被叫终端的Fork应答，如果终端拒绝fork临时应答，那么必须发送cancel或者bye请求，这些请求是针对每个终端即每一个fork的分支都需要发出。　　主叫终端如果接收到被叫终端一个fork分支的成功应答即2

7、xx响应，开始创建会话;应该释放其他fork分支的早对话和非早对话，具体释放的方式根据各个fork分支的不同而不同。其中对于已经收到了临时响应的fork分支，不管是否建立起了早对话，则发送CANCEL请求来释放;对于没有收到任何的临时响应的fork分支，则不能发送CANCEL请求，通过TU设置的保护定时器超时，来释放该分支的相关资源。　　主叫终端只能收到一条最终响应，如果收到2xx响应，则建立对话，如果为2xx以上的响应，则认为无法建立呼叫，则需要释放呼叫。　　1.2代理处理原则