林美玉 王立言
一、引言
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的具体内容。所以实际上本流程根本就不可用。
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之后，媒体就可以流通。
图3 3pcc流程Ⅲ
本流程没有消息重发或者超时的问题(但是如果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)，所以除了扰民之外还将引发收费混乱的问题。
图4 3pcc流程Ⅳ
综上所述，流程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信令交互。
图5 用户B播放早期放音媒体
四、总结语
3pcc在多方通信中(例如会议)的应用也很广泛，SIP协议的3pcc功能应用灵活，使用一个控制者可以将多个用户联系起来进行通信，方便管理。但是目前3pcc实现上还有一些标准无法统一的问题，例如如何创建一个无效连接地址的SDP，亟待解决。目前我国正在积极的开展关于SIP协议对呼叫控制方面标准的制定，第三方呼叫控制作为呼叫控制的一个重要方面，也将成为一个不可或缺的研究重点。
摘自 泰尔网
|