CN101159519A - 一种会话初始协议第三方呼叫控制方法 - Google Patents

Abstract

本发明公开了一种会话初始协议第三方呼叫控制方法，包括以下步骤：(a)控制者向用户1发送邀请消息，不包含会话描述协议消息；(b)所述用户1向所述控制者发送应答并携带包含用户1的有效连接地址的请求消息1；(c)所述控制者向所述用户1发送响应，携带包含控制者的有效连接地址的应答消息1；(d)所述控制者向用户2发送邀请消息，将用户2返回的会话描述协议消息转发给用户1，并将用户1返回的会话描述协议消息转发给用户2，向用户1返回应答，在所述用户1和所述用户2间建立实时传输协议通道。采用本发明的方法，不会有因超时而导致呼叫失败的问题；对控制者的智能要求不高。

Description

一种会话初始协议第三方呼叫控制方法

技术领域

本发明涉及通讯领域，尤其涉及会话初始协议第三方呼叫控制方法。

背景技术

互联网工程任务组(IETF，The Internet Engineering Task Force)提出的会话初始协议(SIP，Session Initiation Protocol)，是在IP网上进行多媒体通信的应用层控制协议，用于发起、建立以及释放会话。SIP协议可以与SDP协议(会话描述协议，Session Description Protocol)配合使用，用来协商会话的媒体属性，很易于实现第三方呼叫控制。

第三方呼叫控制(3pcc，Third Party Call Control)指的是由第三方控制者在另外两者之间建立一个会话，由控制者负责会话双方的媒体协商。使用SIP协议可以借助3pcc来完成许多业务，如会议、接线业务、点击拨号、通话过程中放音等等，而且实现起来非常方便。

RFC3264(Request For Comments，请求注解)中定义了一种提供/应答模式，使两个实体之间可以使用SDP协议的请求/应答(offer/answer)模式进行会话协商，其中offer和answer都是SDP消息，用于携带用户希望建立会话的媒体类型、媒体格式、传输协议以及接收媒体流的端口和IP地址。

目前，根据SIP协议的机制，有下面三种通用的第三方控制实现方法，其各有优劣。

如图1所示，第一种SIP第三方呼叫控制方法包括以下步骤：

步骤101，控制者向SIP User1(SIP用户1)发送一个不携带SDP的INVITE消息(邀请消息)，触发SIP User1振铃；

步骤102，SIP User1应答之后，产生200 OK响应并包含一个请求消息(offer)；

步骤103，控制者将来自SIP User1的offer包含在发送给SIP User2(SIP用户2)的INVITE消息中，触发SIP User2振铃；

步骤104，SIP User2返回200OK响应并包含应答消息(answer)；

步骤105，控制者再向SIP User2发出的ACK(响应)中包含answer作为应答；

步骤106，控制者再向SIP User1发出的ACK中包含上述answer；

步骤107，RTP即实时传输协议通道建立成功。

如图2所示，第二种SIP第三方呼叫控制方法包括以下步骤：

步骤201，控制者向SIP User1发送一个没有SDP的INVITE，触发SIPUser1振铃；

步骤202，SIP User1返回应答消息，并且应答的200 OK中包含一个offer1；

步骤203，控制者在对SIP User1的ACK消息中产生一个“黑洞”SDPanswer1(包含的连接地址是一个无效的连接地址)应答；

步骤204，控制者向SIP User2发送一个没有SDP的INVITE；

步骤205，SIP User2返回200 OK响应消息，返回的响应消息中包含一个offer2；

步骤206，控制者基于offer2向SIP User1发送一个re-INVITE，包含offer2；

步骤207，SIP User1收到并返回200 OK响应，其中携带answer2；

步骤208，控制者向SIP User2发送ACK响应，其中包含answer2，answer2是作为对SIP User2的offer2的应答；

步骤209，控制者向SIP User1发送ACK响应；

步骤210，RTP通道建立成功。

如图3所示，第三种SIP第三方呼叫控制方法包括以下步骤：

步骤301，控制者首先向用户SIP User1发送INVITE消息，包含offer1，用来创建一个初始的“黑洞”媒体流并触发SIP User1振铃；

步骤302，SIP User1返回200 OK应答消息，包含answer1，其中包含的是一个有效的连接地址，但此时仍没有媒体流流向控制者；

步骤303，控制者向SIP User1发送ACK响应；

步骤304，控制者向SIP User2发送INVITE消息；

步骤305，SIP User2返回200 OK响应，其中包含一个offer2；

步骤306，控制者向SIP User1发送re-INVITE消息，包含offer2；

步骤307，SIP User1在200 OK响应中包含应答answer2；

步骤308，控制者向SIP User2发送ACK响应(携带answer2)；

步骤309，控制者向SIP User1发送ACK响应；

步骤310，RTP通道建立成功。

这三种实现流程都具有其优缺点和实际的应用范围。

对于第一种呼叫控制方法，优点是设计简单，不需要控制者产生SDP，不必考虑控制者自身对媒体类型的要求。缺点是该流程存在着一个非常严重的超时问题。如果SIP User2不能立即响应，控制者就无法马上给SIP User1发送ACK，有可能导致SIP User1定时重发200 OK，而根据RFC3261，如果多次超时之后还没有收到ACK，这次呼叫就失败了，所以该流程只能用于SIP User2可以立即对INVITE进行响应的情况下，在网络延时比较严重的情况下，很可能出现超时。这种流程对网络和终端的要求较高。

对于第二、三种呼叫控制方法，优点是所有最终响应都可以被立即确认，不会有因超时而导致呼叫失败的问题。缺点是控制者必须预先知道本次呼叫所要使用的媒体类型，来创建初始的“黑洞”SDP；第二，“黑洞”SDP是一种扩展的机制，并不能确定所有的终端能否支持这种机制以及如果收到这样的地址能做何反应。这两种流程对控制方的智能要求比较高。

发明内容

本发明要解决的技术问题是提供一种会话初始协议第三方呼叫控制方法，不会因超时而导致呼叫失败，且对控制方的智能要求不高。

为了解决上述问题，本发明提供了一种会话初始协议第三方呼叫控制方法，包括以下步骤：

(a)控制者向用户1发送邀请消息，不包含会话描述协议消息；

(b)所述用户1向所述控制者发送应答并携带包含用户1的有效连接地址的请求消息1；

(c)所述控制者向所述用户1发送响应，携带包含控制者的有效连接地址的应答消息1；

(d)所述控制者向用户2发送邀请消息，将用户2返回的会话描述协议消息转发给用户1，并将用户1返回的会话描述协议消息转发给用户2，向用户1返回应答，在所述用户1和所述用户2间建立实时传输协议通道。

进一步地；所述步骤(d)中包括以下步骤：

(d1)所述控制者向所述用户2发送携带所述请求消息1的邀请消息；

(d2)所述用户2返回包含应答消息2的响应；

(d3)所述控制者向所述用户1再次发送邀请消息，包含所述应答消息2；

(d4)所述用户1返回包含应答消息3的响应；

(d5)所述控制者向所述用户2发送携带所述应答消息3的响应；

(d6)所述控制者向所述用户1发送响应，在所述用户1和所述用户2间建立实时传输协议通道。

进一步地；所述步骤(d)中包括以下步骤：

(D1)所述控制者向所述用户2发送邀请消息；

(D2)所述用户2返回包含请求消息2的响应；

(D3)所述控制者向所述用户1再次发送邀请消息，包含所述请求消息2；

(D4)所述用户1返回包含应答消息2的响应；

(D5)所述控制者向所述用户2发送携带所述应答消息2的响应；

(D6)所述控制者向所述用户1发送响应，在所述用户1和所述用户2间建立实时传输协议通道。

进一步地；在所述步骤(d3)中，所述控制者对所述应答消息2进行媒体行修改后包含在邀请消息中，向所述用户1重新发送邀请消息。

进一步地；在所述步骤(d5)中，所述控制者对所述应答消息3进行媒体行修改后，包含在响应中向所述用户2发送。

进一步地；所述媒体行修改是指所述控制者向目标用户转发发送用户的会话初始协议消息前，在所述会话初始协议消息中增加目标用户相对于发送用户中缺少的音频行或视频行，并将端口置为0。

进一步地；在所述步骤(d)中，如果所述控制者将所述用户1返回的会话描述协议消息转发给用户2后，所述用户1和所述用户2之间没有共同的媒体，所述控制者中断呼叫。

进一步地；所述请求消息和应答消息中包含用户的本地IP地址、端口、媒体类型信息。

进一步地；在所述步骤(c)中，所述控制者向所述用户1发送响应后，向所述用户1发送等待音。

进一步地；所述方法适用于IPv4或IPv6网络。

采用本发明的方法，所有最终响应都可以被立即确认，不会有因超时而导致呼叫失败的问题；控制者不需要知道终端的媒体类型和报文内容，对其智能要求不高，流程比较简单，对SIP终端的智能程度没有要求，对网络的实时性要求不高。

附图说明

图1是现有技术的第一种SIP第三方呼叫控制方法的流程图；

图2是现有技术的第二种SIP第三方呼叫控制方法的流程图；

图3是现有技术的第三种SIP第三方呼叫控制方法的流程图；

图4是实施例一中SIP第三方呼叫控制方法的流程图。

具体实施方式

本实施例提供了一种SIP第三方呼叫控制方法，使控制流程既能不受网络延时的影响也不会受到控制者智能程度的限制。

如图4所示，实施例一中SIP第三方呼叫控制方法包括以下步骤：

步骤401，控制者首先向用户SIP User1发送INVITE(邀请消息)，不包含任何SDP；

控制者事先不知道终端媒体类型，所以向用户SIP User1发送的INVITE消息不包含SDP信息。

步骤402，SIP User1振铃并返回200 OK响应，包含offer1，offer1中包含的是SIP User1的一个有效的连接地址；

offer1中还包括用户1的本地信息，SIP User1的本地信息是指用户1的本地IP地址、端口、媒体类型等信息。其中，本地IP地址是为SIP User1的有效的连接地址。

步骤403，控制者向SIP User1发ACK响应，携带一个SDP消息answer1，包含控制者的有效连接地址，建立与SIP User1的媒体连接；

之后，控制者向SIP User1发送等待音，通知SIP User1等待与SIP User2连接；

控制者向SIP User1发出ACK响应后，发送等待音，目的是为了提示用户等待连接。控制者也可以不向SIP User1发送等待音，是否发送等待音由用户和控制者之间事先约定。

步骤404，控制者向SIP User2发送INVITE消息，包含offer1；

步骤405，SIP User2振铃，应答之后产生的200 OK响应中包含一个answer2(包含SIP User2的本地信息)；

其中，用户2返回的answer2是对步骤404中offer1的应答；

SIP User2的本地信息是指用户2的本地IP地址、端口、媒体类型等信息。

步骤406，控制者向SIP User1发送re-INVITE，包含answer2；

控制者可以对answer2进行修改以适应用户1的媒体行后，包含在re-INVITE发送。对媒体行修改是指控制者向目标用户转发发送用户的会话初始协议消息前，在所述会话初始协议消息中增加目标用户相对于发送用户中缺少的音频行或视频行。例如offer1中包含一个音频行和一个视频行，而answer2中仅包含一个音频行，那么控制者就在answer2中增加一个视频行并将其端口设置为0。

re-INVITE和INVITE是指同一类消息，此处表示再次发送INVITE。这个re-INVITE请求会被很快回应(协议规定，INVITE消息必须在32秒内被响应)。

步骤407，SIP User1在200 OK响应中包含的应答answer3；

answer3携带的内容是用户1的本地IP地址、端口、媒体类型等信息。

answer3是对answer2的响应，用于将用户1的本地信息传递给用户2，以便后续媒体类型协商和媒体通道的建立。

步骤408，控制者向SIP User2发送ACK，携带answer3；

控制者可以对要携带的answer3进行适应用户2的媒体行的修改后，包含在ACK消息中发送。

如offer1中仅包含一个音频行，而answer2中包含一个音频行和一个视频行，answer3中仅包含一个音频行，控制者在向用户2转发answer3前，对answer3作适应用户2的媒体行修改，在answer3中增加一个视频行并将其端口设置为0。

在步骤407和408中SIP User1和SIP User2可协商出他们是否有共同的媒体。如果没有共同的媒体，则直接通过BYE消息中断呼叫。

步骤409，控制者再向SIP User1发送ACK响应；

步骤410，此时媒体通道接通，SIP User1和SIP Ucer2之间通话开始。

在步骤407、408、409中，是SIP User1和SIP User2完成会话协商建立RTP通道过程。

在上述每个步骤中的offer和answer都是一个SDP报文，包含终端的IP地址、端口号、媒体类型等信息。

在实施例二中，控制方法的前半部分与图4所示的步骤401至步骤403相同，后半部分和现有技术图2中所示的步骤204至步骤210相同。

实施例一中步骤404中在INVITE消息中携带了用户1向控制者发送的offer1，并在后续步骤中相应进行消息应答和消息转发，这样相比实施例二中的处理方法，使媒体协商的进行速度加快。

在整个流程中控制者始终不需要了解两个终端的媒体类型，也不需要关心终端发出的SDP报文的主要内容，这样就降低了对控制者智能要求。

采用上述方法，所有最终响应都可以被立即确认，不会有因超时而导致呼叫失败的问题；控制者不需要知道终端的媒体类型和报文内容，其智能要求不高；流程比较简单；对SIP终端的智能程度没有要求；对网络的实时性要求不高。

上述方法适用于IPv4(互联网协议第四版)网络和IPv6(互联网协议第六版)网络。

本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明做出各种相应的改变和变形，这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (10)

1.一种会话初始协议第三方呼叫控制方法，其特征在于，包括以下步骤：

(a)控制者向用户1发送邀请消息，不包含会话描述协议消息；

(b)所述用户1向所述控制者发送应答并携带包含用户1的有效连接地址的请求消息1；

(c)所述控制者向所述用户1发送响应，携带包含控制者的有效连接地址的应答消息1；

(d)所述控制者向用户2发送邀请消息，将用户2返回的会话描述协议消息转发给用户1，并将用户1返回的会话描述协议消息转发给用户2，向用户1返回应答，在所述用户1和所述用户2间建立实时传输协议通道。

2.如权利要求1所述的方法，其特征在于：

所述步骤(d)中包括以下步骤：

(d1)所述控制者向所述用户2发送携带所述请求消息1的邀请消息；

(d2)所述用户2返回包含应答消息2的响应；

(d3)所述控制者向所述用户1再次发送邀请消息，包含所述应答消息2；

(d4)所述用户1返回包含应答消息3的响应；

(d5)所述控制者向所述用户2发送携带所述应答消息3的响应；

(d6)所述控制者向所述用户1发送响应，在所述用户1和所述用户2间建立实时传输协议通道。

3.如权利要求1所述的方法，其特征在于：

所述步骤(d)中包括以下步骤：

(D1)所述控制者向所述用户2发送邀请消息；

(D2)所述用户2返回包含请求消息2的响应；

(D3)所述控制者向所述用户1再次发送邀请消息包含所述请求消息2；

(D4)所述用户1返回包含应答消息2的响应；

(D5)所述控制者向所述用户2发送携带所述应答消息2的响应；

(D6)所述控制者向所述用户1发送响应，在所述用户1和所述用户2间建立实时传输协议通道。

4.如权利要求2所述的方法，其特征在于：

在所述步骤(d3)中，所述控制者对所述应答消息2进行媒体行修改后包含在邀请消息中，向所述用户1重新发送邀请消息。

5.如权利要求2所述的方法，其特征在于：

在所述步骤(d5)中，所述控制者对所述应答消息3进行媒体行修改后，包含在响应中向所述用户2发送。

6.如权利要求4和5所述的方法，其特征在于：

所述媒体行修改是指所述控制者向目标用户转发发送用户的会话初始协议消息前，在所述会话初始协议消息中增加目标用户相对于发送用户中缺少的音频行或视频行，并将端口置为0。

7.如权利要求1所述的方法，其特征在于：

在所述步骤(d)中，如果所述控制者将所述用户1返回的会话描述协议消息转发给用户2后，所述用户1和所述用户2之间没有共同的媒体，所述控制者中断呼叫。

8.如权利要求1所述的方法，其特征在于：

所述请求消息和应答消息中包含用户的本地IP地址、端口、媒体类型信息。

9.如权利要求1所述的方法，其特征在于：

在所述步骤(c)中，所述控制者向所述用户1发送响应后，向所述用户1发送等待音。

10.如权利要求1所述的方法，其特征在于：

所述方法适用于IPv4或IPv6网络。

Images