專利名稱：一種會話初始協(xié)議第三方呼叫控制方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通訊領(lǐng)域，尤其涉及會話初始協(xié)議第三方呼叫控制方法。
技術(shù)背景互聯(lián)網(wǎng)工程任務(wù)組(IETF, The Internet Engineering Task Force)提出的 會話初始協(xié)議(SIP, Session Initiation Protocol),是在IP網(wǎng)上進行多4某體通信 的應(yīng)用層控制協(xié)議，用于發(fā)起、建立以及釋放會話。SIP協(xié)議可以與SDP協(xié) 議(會話描述協(xié)議，Session Description Protocol)配合使用，用來協(xié)商會話 的媒體屬性，很易于實現(xiàn)第三方呼叫控制。第三方呼叫控制(3pcc， Third Party Call Control)指的是由第三方控制者 在另外兩者之間建立一個會話，由控制者負責(zé)會話雙方的媒體協(xié)商。使用 SIP協(xié)議可以借助3pcc來完成許多業(yè)務(wù)，如會議、接線業(yè)務(wù)、點擊撥號、通 話過程中放音等等，而且實現(xiàn)起來非常方便。RFC3264 (Request For Comments ,請求注解)中定義了一種提供/應(yīng)答 模式，使兩個實體之間可以使用SDP協(xié)議的請求/應(yīng)答(offer/answer)模式進 行會話協(xié)商，其中offer和answer都是SDP消息，用于攜帶用戶希望建立會 話的媒體類型、媒體格式、傳輸協(xié)議以及接收媒體流的端口和IP地址。目前，根據(jù)SIP協(xié)議的機制，有下面三種通用的第三方控制實現(xiàn)方法， 其各有優(yōu)劣。如圖l所示，第一種SIP第三方呼叫控制方法包括以下步驟步驟101，控制者向SIP Userl ( SIP用戶1 )發(fā)送一個不攜帶SDP的 INVITE消息(邀請消息)，觸發(fā)SIP Userl振鈴；步驟102， SIP Userl應(yīng)答之后，產(chǎn)生200 OK響應(yīng)并包含一個請求消息 (offer);
步驟103,控制者將來自SIP Userl的offer包含在發(fā)送給SIP User2( SIP 用戶2 )的INVITE消息中，觸發(fā)SIP User2振鈴；步驟104, SlPUser2返回2000K響應(yīng)并包含應(yīng)答消息( answer J ',步驟105，控制者再向SIP User2發(fā)出的ACK (響應(yīng))中包含answer作為應(yīng)答；步驟106,控制者再向SIP Userl發(fā)出的ACK中包含上述answer;步驟107， RTP即實時傳輸協(xié)議通道建立成功。如圖2所示，第二種SIP第三方呼叫控制方法包括以下步驟步驟201，控制者向SIP Userl發(fā)送一個沒有SDP的INVITE,觸發(fā)SIP Userl振鈴；步驟202, SIP Userl返回應(yīng)答消息，并且應(yīng)答的200 OK中包含一個 offerl;步驟203,控制者在對SIP Userl的ACK消息中產(chǎn)生一個"黑洞"SDP answerl (包含的連接地址是一個無效的連接地址)應(yīng)答；步驟204,控制者向SIP User2發(fā)送一個沒有SDP的INVITE;步驟205, SIP User2返回200 OK響應(yīng)消息，返回的響應(yīng)消息中包含一 個offer2;步驟206,控制者基于offer2向SIP Userl發(fā)送一個re-INVITE，包含 offer2',步驟207, SIP Userl收到并返回200 OK響應(yīng)，其中攜帶answer2;步驟208，控制者向SIP User2發(fā)送ACK響應(yīng)，其中包含answer2， answer2是作為對SIP User2的offer2的應(yīng)答；步驟209，控制者向SIP Userl發(fā)送ACK響應(yīng)；步驟210, RTP通道建立成功。 如圖3所示，第三種SIP第三方呼叫控制方法包括以下步驟步驟301,控制者首先向用戶SIPUserl發(fā)送INVITE消息，包含offerl, 用來創(chuàng)建一個初始的"黑洞"媒體流并觸發(fā)SIP Userl振鈴；步驟302， SIP Userl返回200 OK應(yīng)答消息，包含answerl，其中包含 的是一個有效的連接地址，但此時仍沒有々某體流流向控制者；步驟303，控制者向SIP Userl發(fā)送ACK響應(yīng)；步驟304,控制者向SIP User2發(fā)送INVITE消息；步驟305, SIP User2返回200 OK響應(yīng)，其中包含一個offer2;步驟306，控制者向SIP Userl發(fā)送re-INVITE消息，包含offer2;步驟307， SIP Userl在200 OK響應(yīng)中包含應(yīng)答answer2;步驟308,控制者向SIPUser2發(fā)送ACK響應(yīng)(攜帶answer2);步驟309,控制者向SIP Userl發(fā)送ACK響應(yīng)；步驟310， RTP通道建立成功。這三種實現(xiàn)流程都具有其優(yōu)缺點和實際的應(yīng)用范圍。對于第一種呼叫控制方法，優(yōu)點是設(shè)計簡單，不需要控制者產(chǎn)生SDP， 不必考慮控制者自身對媒體類型的要求。缺點是該流程存在著一個非常嚴重 的超時問題。如果SIPUser2不能立即響應(yīng)，控制者就無法馬上給SIP Userl 發(fā)送ACK,有可能導(dǎo)致SIP Userl定時重發(fā)200 OK,而根據(jù)RFC3261，如 果多次超時之后還沒有收到ACK,這次呼叫就失敗了，所以該流程只能用 于SIP User2可以立即對INVITE進行響應(yīng)的情況下，在網(wǎng)絡(luò)延時比較嚴重 的情況下，很可能出現(xiàn)超時。這種流程對網(wǎng)絡(luò)和終端的要求較高。對于第二、三種呼叫控制方法，優(yōu)點是所有最終響應(yīng)都可以被立即確認， 不會有因超時而導(dǎo)致呼叫失敗的問題。缺點是控制者必須預(yù)先知道本次呼叫 所要使用的i某體類型，來創(chuàng)建初始的"黑洞"SDP;第二，"黑洞"SDP是 一種擴展的機制，并不能確定所有的終端能否支持這種機制以及如果收到這 樣的地址能做何反應(yīng)。這兩種流程對控制方的智能要求比較高
發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提供一種會話初始協(xié)議第三方呼叫控制方 法，不會因超時而導(dǎo)致呼叫失敗，且對控制方的智能要求不高。為了解決上述問題，本發(fā)明提供了一種會話初始協(xié)議第三方呼叫控制方法，包括以下步驟(a) 控制者向用戶l發(fā)送邀請消息，不包含會話描述協(xié)議消息；(b) 所述用戶1向所述控制者發(fā)送應(yīng)答并攜帶包含用戶l的有效連接 地址的請求消息1;(c) 所述控制者向所述用戶l發(fā)送響應(yīng)，攜帶包含控制者的有效連接 地址的應(yīng)答消息1;(d) 所述控制者向用戶2發(fā)送邀請消息，將用戶2返回的會話描述協(xié) 議消息轉(zhuǎn)發(fā)給用戶1，并將用戶1返回的會話描述協(xié)議消息轉(zhuǎn)發(fā)給用戶2， 向用戶1返回應(yīng)答，在所述用戶1和所述用戶2間建立實時傳輸協(xié)議通道。進一步地；所述步驟(d)中包括以下步驟(dl )所述控制者向所述用戶2發(fā)送攜帶所述請求消息1的邀請消息； (d2)所述用戶2返回包含應(yīng)答消息2的響應(yīng)；(d3 )所述控制者向所述用戶1再次發(fā)送邀請消息，包含所述應(yīng)答消息2;(d4)所述用戶l返回包含應(yīng)答消息3的響應(yīng)；(d5)所述控制者向所述用戶2發(fā)送攜帶所述應(yīng)答消息3的響應(yīng)；(d6)所述控制者向所述用戶l發(fā)送響應(yīng)，在所述用戶l和所述用戶2 間建立實時傳輸協(xié)議通道。進一步地；所述步驟(d)中包括以下步驟(Dl)所述控制者向所述用戶2發(fā)送邀請消息；(D2)所述用戶2返回包含請求消息2的響應(yīng)；(D3)所述控制者向所述用戶1再次發(fā)送邀請消息，包含所述請求消息2 :
(D4)所述用戶1返回包含應(yīng)答消息2的響應(yīng)；(D5)所述控制者向所述用戶2發(fā)送攜帶所述應(yīng)答消息2的響應(yīng)；(D6)所述控制者向所述用戶l發(fā)送響應(yīng)，在所述用戶1和所述用戶2 間建立實時傳輸協(xié)議通道。進一步地；在所述步驟(d3)中，所述控制者對所述應(yīng)答消息2進行媒 體行修改后包含在邀請消息中，向所述用戶l重新發(fā)送邀請消息。進一步地；在所述步驟(d5)中，所述控制者對所述應(yīng)答消息3進行i某 體行修改后，包含在響應(yīng)中向所述用戶2發(fā)送。進一步地；所述媒體行修改是指所述控制者向目標(biāo)用戶轉(zhuǎn)發(fā)發(fā)送用戶的 會話初始協(xié)議消息前，在所述會話初始協(xié)議消息中增加目標(biāo)用戶相對于發(fā)送 用戶中缺少的音頻行或視頻行，并將端口置為0。進一步地；在所述步驟(d)中，如果所述控制者將所述用戶1返回的 會話描述協(xié)議消息轉(zhuǎn)發(fā)給用戶2后，所述用戶1和所述用戶2之間沒有共同 的媒體，所述控制者中斷呼叫。進一步地；所述請求消息和應(yīng)答消息中包含用戶的本地IP地址、端口、 媒體類型信息。進一步地；在所述步驟(c)中，所述控制者向所述用戶l發(fā)送響應(yīng)后， 向所述用戶l發(fā)送等待音。進一步地；所述方法適用于IPv4或IPv6網(wǎng)絡(luò)。采用本發(fā)明的方法，所有最終響應(yīng)都可以被立即確認，不會有因超時而 導(dǎo)致呼叫失敗的問題；控制者不需要知道終端的媒體類型和報文內(nèi)容，對其 智能要求不高，流程比較簡單，對SIP終端的智能程度沒有要求，對網(wǎng)絡(luò)的 實時性要求不高。


圖1是現(xiàn)有技術(shù)的第一種SIP第三方呼叫控制方法的流程圖；圖2是現(xiàn)有技術(shù)的第二種SIP第三方呼叫控制方法的流程圖； 圖3是現(xiàn)有技術(shù)的第三種SIP第三方呼叫控制方法的流程圖； 圖4是實施例一中SIP第三方呼叫控制方法的流程圖。
具體實施方式
本實施例提供了 一種SIP第三方呼叫控制方法，使控制流程既能不受網(wǎng) 絡(luò)延時的影響也不會受到控制者智能程度的限制。如圖4所示，實施例一中SIP第三方呼叫控制方法包括以下步驟步驟401，控制者首先向用戶SIP Userl發(fā)送INVITE (邀請消息)，不 包含任何SDP;控制者事先不知道終端々某體類型，所以向用戶SIP Userl發(fā)送的INVITE 消息不包含SDP信息。步驟402, SIP Userl振鈴并返回200 OK響應(yīng)，包含offer 1 ， offerl中包 含的是SIP Userl的一個有效的連接地址；offerl中還包括用戶1的本地信息，SIP Userl的本地信息是指用戶1的 本地IP地址、端口 、 J(某體類型等信息。其中，本地IP地址是為SIP Userl 的有效的連接地址。步驟403 ，控制者向SIP Userl發(fā)ACK響應(yīng)，攜帶一個SDP消息answerl, 包含控制者的有效連接地址，建立與SIP Userl的媒體連接；之后，控制者向SIP Userl發(fā)送等待音，通知SIP Userl等待與SlPUser2連接；控制者向SIP Userl發(fā)出ACK響應(yīng)后，發(fā)送等待音，目的是為了提示用 戶等待連接?？刂普咭部梢圆幌騍IP Userl發(fā)送等待音，是否發(fā)送等待音由 用戶和控制者之間事先約定。步驟404，控制者向SIP User2發(fā)送INVITE消息，包含offerl;步驟405， SIP User2振鈴，應(yīng)答之后產(chǎn)生的200 OK響應(yīng)中包含一個 answer2 (包含SIP User2的本地信息)；
其中，用戶2返回的answer2是對步驟404中offerl的應(yīng)答； SlPUser2的本地信息是指用戶2的本地IP地址、端口、媒體類型等信息。步驟406,控制者向SIPUserl發(fā)送re-INVITE,包含answer2;控制者可以對answer2進行修改以適應(yīng)用戶1的媒體行后，包含在 re-INVITE發(fā)送。對媒體行修改是指控制者向目標(biāo)用戶轉(zhuǎn)發(fā)發(fā)送用戶的會話 初始協(xié)議消息前，在所述會話初始協(xié)議消息中增加目標(biāo)用戶相對于發(fā)送用戶 中缺少的音頻行或一見頻行。例如offerl中包含一個音頻行和一個一見頻行，而 answer2中僅包含一個音頻行，那么控制者就在answer2中增加一個視頻行 并將其端口設(shè)置為0。re-INVITE和INVITE是指同一類消息，此處表示再次發(fā)送INVITE。這 個re-INVITE請求會被很快回應(yīng)(協(xié)議規(guī)定，INVITE消息必須在32秒內(nèi)被 響應(yīng))。步驟407, SIP Userl在200 OK響應(yīng)中包含的應(yīng)答answer3;answer3攜帶的內(nèi)容是用戶1的本地IP地址、端口、媒體類型等信息。answer3是對answer2的響應(yīng)，用于將用戶1的本地信息傳遞給用戶2, 以便后續(xù)媒體類型協(xié)商和媒體通道的建立。步驟408,控制者向SIP User2發(fā)送ACK,攜帶answer3;控制者可以對要攜帶的answer3進行適應(yīng)用戶2的媒體行的修改后，包 含在ACK消息中發(fā)送。如offerl中僅包含一個音頻行，而answer2中包含一個音頻行和一個3見 頻行，answer3中僅包含一個音頻行，控制者在向用戶2轉(zhuǎn)發(fā)answer3前， 對answer3作適應(yīng)用戶2的々某體行修改，在answer3中增加一個視頻行并將 其端口設(shè)置為0 。在步驟407和408中SIP Userl和SIP User2可協(xié)商出他們是否有共同的 媒體。如果沒有共同的媒體，則直接通過BYE消息中斷呼叫。步驟409,控制者再向SIPUserl發(fā)送ACK響應(yīng)；
步驟410,此時媒體通道接通，SIPUserl和SIP Ucer2之間通話開始。在步驟407、 408、 409中，是SIP Userl和SIP User2完成會話協(xié)商建立 RTP通道過程。在上述每個步驟中的offer和answer都是一個SDP報文，包含終端的IP 地址、端口號、媒體類型等信息。在實施例二中，控制方法的前半部分與圖4所示的步驟401至步驟403 相同，后半部分和現(xiàn)有技術(shù)圖2中所示的步驟204至步驟210相同。實施例一中步驟404中在INVITE消息中攜帶了用戶1向控制者發(fā)送的 offerl，并在后續(xù)步驟中相應(yīng)進行消息應(yīng)答和消息轉(zhuǎn)發(fā)，這樣相比實施例二 中的處理方法，使々某體協(xié)商的進行速度加快。在整個流程中控制者始終不需要了解兩個終端的媒體類型，也不需要關(guān) 心終端發(fā)出的SDP報文的主要內(nèi)容，這樣就降低了對控制者智能要求。采用上述方法，所有最終響應(yīng)都可以被立即確認，不會有因超時而導(dǎo)致 呼叫失敗的問題；控制者不需要知道終端的媒體類型和報文內(nèi)容，其智能要 求不高；流程比較簡單；對SIP終端的智能程度沒有要求；對網(wǎng)絡(luò)的實時性 要求不高。上述方法適用于IPv4 (互聯(lián)網(wǎng)協(xié)議第四版)網(wǎng)絡(luò)和IPv6 (互聯(lián)網(wǎng)協(xié)議 第六版)網(wǎng)絡(luò)。本發(fā)明還可有其他多種實施例，在不背離本發(fā)明精神及其實質(zhì)的情況 些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護范圍。
權(quán)利要求
1、一種會話初始協(xié)議第三方呼叫控制方法，其特征在于，包括以下步驟(a)控制者向用戶1發(fā)送邀請消息，不包含會話描述協(xié)議消息；(b)所述用戶1向所述控制者發(fā)送應(yīng)答并攜帶包含用戶1的有效連接地址的請求消息1；(c)所述控制者向所述用戶1發(fā)送響應(yīng)，攜帶包含控制者的有效連接地址的應(yīng)答消息1；(d)所述控制者向用戶2發(fā)送邀請消息，將用戶2返回的會話描述協(xié)議消息轉(zhuǎn)發(fā)給用戶1，并將用戶1返回的會話描述協(xié)議消息轉(zhuǎn)發(fā)給用戶2，向用戶1返回應(yīng)答，在所述用戶1和所述用戶2間建立實時傳輸協(xié)議通道。
2、 如權(quán)利要求1所述的方法，其特征在于 所述步驟(d)中包括以下步驟(dl)所述控制者向所述用戶2發(fā)送攜帶所述請求消息1的邀請消息； (d2)所述用戶2返回包含應(yīng)答消息2的響應(yīng)；(d3)所述控制者向所述用戶l再次發(fā)送邀請消息，包含所述應(yīng)答消息2;(d4)所述用戶l返回包含應(yīng)答消息3的響應(yīng)；(d5)所述控制者向所述用戶2發(fā)送攜帶所述應(yīng)答消息3的響應(yīng)；(d6)所述控制者向所述用戶1發(fā)送響應(yīng)，在所述用戶1和所述用戶2 間建立實時傳輸協(xié)議通道。
3、 如權(quán)利要求1所述的方法，其特征在于 所述步驟(d)中包括以下步驟(Dl)所述控制者向所述用戶2發(fā)送邀請消息； (D2)所述用戶2返回包含請求消息2的響應(yīng)；(D3 )所述控制者向所述用戶1再次發(fā)送邀請消息包含所述請求消息2 ;(D4)所述用戶l返回包含應(yīng)答消息2的響應(yīng)；(D5)所述控制者向所述用戶2發(fā)送攜帶所述應(yīng)答消息2的響應(yīng)；(D6)所述控制者向所述用戶1發(fā)送響應(yīng)，在所述用戶1和所述用戶2 間建立實時傳輸協(xié)議通道。
4、 如權(quán)利要求2所述的方法，其特征在于在所述步驟(d3 )中，所述控制者對所述應(yīng)答消息2進行媒體行修改后 包含在邀請消息中，向所述用戶l重新發(fā)送邀請消息。
5、 如權(quán)利要求2所述的方法，其特征在于在所述步驟(d5 )中，所述控制者對所述應(yīng)答消息3進行媒體行修改后， 包含在響應(yīng)中向所述用戶2發(fā)送。
6、 如權(quán)利要求4和5所述的方法，其特征在于所述媒體行修改是指所述控制者向目標(biāo)用戶轉(zhuǎn)發(fā)發(fā)送用戶的會話初始 協(xié)議消息前，在所述會話初始協(xié)議消息中增加目標(biāo)用戶相對于發(fā)送用戶中缺 少的音頻行或^L頻行，并將端口置為0。
7、 如權(quán)利要求1所述的方法，其特征在于在所述步驟(d)中，如果所述控制者將所述用戶l返回的會話描述協(xié) 議消息轉(zhuǎn)發(fā)給用戶2后，所述用戶l和所述用戶2之間沒有共同的i某體，所 述控制者中斷呼叫。
8、 如權(quán)利要求l所述的方法，其特征在于所述請求消息和應(yīng)答消息中包含用戶的本地IP地址、端口、媒體類型 信息。
9、 如權(quán)利要求l所述的方法，其特征在于在所述步驟(c)中，所述控制者向所述用戶l發(fā)送響應(yīng)后，向所述用 戶1發(fā)送等待音。
10、 如權(quán)利要求1所述的方法，其特征在于 所述方法適用于IPv4或IPv6網(wǎng)絡(luò)。
全文摘要
本發(fā)明公開了一種會話初始協(xié)議第三方呼叫控制方法，包括以下步驟(a)控制者向用戶1發(fā)送邀請消息，不包含會話描述協(xié)議消息；(b)所述用戶1向所述控制者發(fā)送應(yīng)答并攜帶包含用戶1的有效連接地址的請求消息1；(c)所述控制者向所述用戶1發(fā)送響應(yīng)，攜帶包含控制者的有效連接地址的應(yīng)答消息1；(d)所述控制者向用戶2發(fā)送邀請消息，將用戶2返回的會話描述協(xié)議消息轉(zhuǎn)發(fā)給用戶1，并將用戶1返回的會話描述協(xié)議消息轉(zhuǎn)發(fā)給用戶2，向用戶1返回應(yīng)答，在所述用戶1和所述用戶2間建立實時傳輸協(xié)議通道。采用本發(fā)明的方法，不會有因超時而導(dǎo)致呼叫失敗的問題；對控制者的智能要求不高。
文檔編號H04L1/16GK101159519SQ20071016341
公開日2008年4月9日 申請日期2007年10月22日 優(yōu)先權(quán)日2007年10月22日
發(fā)明者陳曉暉 申請人:中興通訊股份有限公司