会话初始协议(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的具体内容。所以实际上本流程根本就不可用。

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之后，媒体就可以流通。

图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之后，媒体就可以流通。

图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播放早期放音媒体