SIP 会话初始协议第三方呼叫控制的研究


一、引言
IETF提出的会话初始协议(SIP),是在IP网上进行多媒体通信的应用层控制协议,可以用来发起、建立以及释放会话 。SIP协议灵活简单的特性以及其灵活强大的呼叫控制的功能吸引了越来越多的厂商和运营商 。SIP协议还可以与SDP协议配合使用,用来协商会话的媒体属性,因此更易于实现第三方呼叫控制 。
第三方呼叫控制(3pcc)指的是由第三方控制者在另外两者之间建立一个会话,由控制者负责会话双方的媒体协商 。3pcc是一种非常灵活的控制方式,在PSTN网中,第三方呼叫控制通常用于会议、接线业务(接线员创建一个连接另外双方的呼叫) 。同样,使用SIP协议也可以借助3pcc来完成许多业务,例如点击拨号、通话过程中放音等等,而且实现起来非常方便 。RFC3264中定义了一种提供/应答模式,使两个实体之间可以使用SDP的提供/应答(offer/answer)模式进行会话协商 。
二、第三方呼叫控制方法
SIP消息可以携带SDP消息体 。SDP(会话描述协议)是用来描述与媒体流相关的参数以及与会话相关的信息,其中包括对会话的描述以及媒体类型、数据发送到的端口、传输协议(例如RTP)以及媒体格式(例如RTP载荷格式)的描述 。3pcc的实现要害就在于控制者如何在会话双方之间使用SDP消息协商即将建立的会话 。根据SIP协议的机制,可以有下面四种方法实现3pcc 。
1.流程Ⅰ
该流程图中的offer和answer都是SDP消息 。下面解释消息流程 。
控制者首先向用户A发送一个没有SDP的INVITE,A的电话振铃,A应答之后,产生的200 OK响应中将包含一个ofrerl,携带用户A所希望建立会话的媒体类型、媒体格式、传输协议以及接收媒体流的端口和IP地址 。控制者将来自A的offerl包含在发给B的INVITE中,B振铃应答之后产生对rfferl的应答answerl 。最后控制者向用户A发出的ACK中包含answer1作为应答 。
 
图1 3pcc流程Ⅰ
该流程优点是非常简单,不需要控制者产生SDP,不必考虑控制者自身对媒体类型的要求 。
缺点是该流程存在着一个非常严重的超时问题 。假如B不能立即响应,控制者就无法马上给A发送ACK,有可能导致A定时重发200 OK 。因为根据RFC3261,假如走时之后还没有收到ACK,这次呼叫就失败了 。所以该流程只能用于用户B可以立即对INVITE进行响应的情况下 。
2.流程Ⅱ
 
图2 3pcc流程Ⅱ
流程图中的“黑洞”SDP指的是包含的连接地址是一个无效的连接地址,例如rtp.invalid或者0.0.0.0,也就是想建立一个空的媒体流,因为这个媒体流实际上并没有媒体或者RTCP包从A流出 。
该流程中,控制者首先向用户A发送INVITE,包含SDP1,用来创建一个初始的“黑洞”媒体流,A振铃并产生应答记为SDP2,其中包含的是一个有效的连接地址,但此时仍没有媒体流向控制者 。控制者向A发出ACK 。控制者向B发送INVITE,携带SDP2作为对B的offer 。B振铃,应答之后产生的200 OK响应中包含一个SDP3,也就是对SDP2的应答 。控制者向B发送ACK 。
控制者向A发送re-INVITE,包含SDP3作为offer 。假设用户A不想改变原来的会话属性,在200 OK响应中包含的应答应该仍是SDP2 。控制者发送ACK之后,就可以有媒体从A流向B 。
本流程所有的最终响应都可以被立即确认,不会有因超时而导致呼叫失败的问题 。
缺点是控制者必须预先知道本次呼叫所要使用的媒体类型,来创建初始的“黑洞”SDP;第二,“黑洞”SDP是一种扩展的机制,并不能确定所有的UA能否支持这种机制以及假如收到这样的地址能做何反应;第三,流程完成的前提是假设用户A对re-INVITE的响应中仍然包含的是SDP2 。假如不是SDP2的话,控制者还需要向A再发送re-INVITE,然后有可能从B得到另一个不同的SDP,然后还需要向A再发送re-INVITE,如此等等,可能形成一个无限循环的会话协商 。当然,可以采用一个智能UA,要求其固定的返回SDP2,或者采用一个智能的控制者能够分析收到的SDP确定有无必要发送re-INVITE,但是为简单起见,应尽量避免控制者了解SDP的具体内容 。所以实际上本流程根本就不可用 。

推荐阅读