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

时间:2020-10-16 18:01:52 网络工程毕业论文 我要投稿

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

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

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

  关键词: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。