对SIP协议第三方呼叫控制的研究

一、引言



　　该流程优点是非常简单，不需要控制者产生SDP，不必考虑控制者自身对媒体类型的要求。

　　缺点是该流程存在着一个非常严重的超时问题。如果B不能立即响应，控制者就无法马上给A发送ACK，有可能导致A定时重发200 OK。因为根据RFC3261，如果走时之后还没有收到ACK，这次呼叫就失败了。所以该流程只能用于用户B可以立即对INVITE进行响应的情况下。

　　2.流程Ⅱ



　　流程图中的“黑洞”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的具体内容。所以实际上本流程根本就不可用。

　　3.流程Ⅲ

　　本流程中，控制者向A发送一个没有SDP的INVITE。A应答的200 OK响应中包含一个offerl，控制者立即在ACK消息中产生一个“黑洞”SDP应答。

　　控制者再向B发送一个没有SDP的INVITE。B应答的200 0K响应中包含一个提供offer2，控制者应该基于offer2向A发送一个re-INVITE，注意。offer2可能需要稍作修改来满足媒体要求。例如如果offer1包含一个音频和一个视频行，而offer2只有一个音频行，控制者就需要在offer2中增加一个视频行(端口设为O)来构成offer2’。由于这是一个re-INVITE，所以通常应该能立即收到响应。A的200 0K响应中包含的answer2’，可能也需要稍作修改作为offer2的应答answer2。控制者向A发送ACK之后，媒体就可以流通。



　　本流程没有消息重发或者超时的问题(但是如果UA不能对re-INVITE立即进行响应，还是会出现这种问题)，而且不需要控制者预知用户本次呼叫所使用的媒体类型。

　　缺点：首先是控制者需要对SDP进行操作，按照接收到的offer1构建一个具有相同媒体组成的“黑洞”answer1,还要对offer2进行重排列或者修改，构建一个适合用户A的offer2’。来自B的offer2可能跟来自A的offerl没有相同的编解码或者媒体流，控制者需要识别这一情况并能及时的结束呼叫。第四，需要使用扩展的invalid机制，UA有可能不支持。第五，该流程复杂的多，除了信令的交互相对流程I较多外，主要表现在对控制者要求较高，增加了控制者的复杂性。

　　4.流程Ⅳ

　　本流程实际上是流程Ⅲ的简化版，消息流程完全相同，只有SDP的组成不同。初始的INVITE中的SDP没有m行，这表明本次会话所用的媒体需要在随后的re-INVITE中建立。后面流程跟流程Ⅲ完全相同，但是将offer2转变成offer2’还有answer2’转变成answer2比流程Ⅲ简单多了，因为根本不需要再对媒体行进行任何操作了。

　　缺点：首先是要得到answerl，就需要用户A在没有任何媒体的情况下就被振铃，用户A将不能根据媒体类型来决定是否拒绝该请求。第二点，如果A、B之间经过协商发现并没有共同的媒体类型，而在得知这一情况之前，A、B都已经响应了呼叫请求(发出了200 OK)，所以除了扰民之外还将引发收费混乱的问题。



　　综上所述，流程I是最简单且有效的流程。如果控制者预先知道B是自动应答的能够立即响应，例如B是媒体服务器、会议服务器等等情况下，使用本流程是最好不过了。

　　如果控制者无法预知被叫的类型，就可以使用流程Ⅳ或者流Ⅲ来实现3pcc，但是一般不会使用流程Ⅱ。使用IV、Ⅲ时对控制者的智能性要求比较高。

三、3pcc应用

　　SIP协议的突出优点就在于灵活的多媒体会话的控制功能，配合使用3pcc就可以比传统电话网更加灵活方便的实现各种补充业务和新业务。

　　3pcc的应用非常广泛，例如可以方便对信令的控制，易于实现点击拨号、早期媒体放音(early media)、通话过程中播放语音通知的业务等等。

　　点击拨号业务是最典型的3pcc的应用实例。用户浏览网站时，可以直接点击网页上的链接地址，使用HTTP启动控制者对客服代表和SIP用户之间的第三方呼叫控制。然后控制者就可以使用上述四种方法在两者之间建立起媒体会话。

　　通话过程中播放语音通知，可以使用控制者将媒体服务器跟正在通话的用户之间连接起来，播放通知。

　　下面以播放早期放音媒体为例，选用最简单的流程I来介绍3pcc的应用。实际应用中，应该根据具体的情况考虑使用其它流程对下图进行修改。

　　Early media指的是呼叫建立之前已经建立的会话，通常用来传递关于呼叫进程的语音通知。图5便是用户B在应答呼叫之前已经建立了Early media媒体通道进行放音(图中(1)处)。用户B对呼叫进行应答之前用户A和控制者之间，B和控制者之间都分别已经进行过一轮媒体的交互了。当B接受呼叫之后，由于会话状态并没有改变，因此并不需要重新与用户A进行SDP信令交互。



四、总结语

　　3pcc在多方通信中(例如会议)的应用也很广泛，SIP协议的3pcc功能应用灵活，使用一个控制者可以将多个用户联系起来进行通信，方便管理。但是目前3pcc实现上还有一些标准无法统一的问题，例如如何创建一个无效连接地址的SDP，亟待解决。目前我国正在积极的开展关于SIP协议对呼叫控制方面标准的制定，第三方呼叫控制作为呼叫控制的一个重要方面，也将成为一个不可或缺的研究重点。