基于SIP协议的forking功能的研究和实现
作者:佚名; 更新时间:2019-07-16

  摘要: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。

    Copyright@2000-2030 职称qq全自动抢红包神器期刊网 Corporation All Rights Reserved.
    《中华人民共和国信息产业部》备案号:ICP备07016076号;《公安部》备案号:33010402003207
    cnqika@163.com;zclwnet@126.com;zclwnet@163.com;
    本网站收录了海量免费qq全自动抢红包神器资料和上百个经国家新闻出版总署审批过的具有国内统一CN刊号与国际标准ISSN刊号的期刊杂志,供诸位查阅参考和选择,qq全自动抢红包神器版权属原作者所有,谨防侵权。