專(zhuān)利名稱(chēng)：會(huì)話?；罘椒把b置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及到通訊領(lǐng)域，具體而言，尤其涉及到會(huì)話?；罘椒把b置。
背景技術(shù)：
IP多媒體子系統(tǒng)(IP Multimedia Subsystem，簡(jiǎn)稱(chēng)為IMS)是第三代合作伙伴組 織(3rd Generation Partnership Project，簡(jiǎn)稱(chēng)為3GPP)定義的下一代網(wǎng)絡(luò)的標(biāo)準(zhǔn)，它的 顯著特點(diǎn)是采用了會(huì)話初始協(xié)議(Session Initiation Protocol，簡(jiǎn)稱(chēng)為SIP)體系。會(huì)話?；钍且环N用于檢測(cè)會(huì)話是否為活著的一種方式，RFC4028對(duì)SIP協(xié)議進(jìn)行 了擴(kuò)展來(lái)實(shí)現(xiàn)這種?；顧C(jī)制。RFC4(^8擴(kuò)展了兩個(gè)頭部Session-Expires、Min-SE，一個(gè)功 能選項(xiàng)定時(shí)器(timer)來(lái)實(shí)現(xiàn)會(huì)話保活檢查功能。依據(jù)RFC4028中的定義，會(huì)話保活的 ?；顚?duì)象雙方都必須支持RFC4028擴(kuò)展協(xié)議，并規(guī)定了如下3種實(shí)現(xiàn)形式，下面對(duì)此進(jìn)行說(shuō) 明形式一，主叫用戶(hù)(UAC)通過(guò)初始邀請(qǐng)(INVITE)請(qǐng)求攜帶用于?；畹男畔?(例如，Supported :timer, Session-Expires 90, Min-SE :90)，當(dāng)接收到請(qǐng)求的被叫用 戶(hù)(UAS)或者代理O^roxy)也支持RFC4028，并且也希望運(yùn)行會(huì)話?；罟δ軙r(shí)，則會(huì)在 2000K(INVITE)協(xié)商發(fā)起保活的時(shí)間間隔，最終通過(guò)協(xié)商的結(jié)果進(jìn)行定期發(fā)起的rehvite 或者更新(UPDATE)消息來(lái)進(jìn)行會(huì)話的?；顧z測(cè)。當(dāng)主動(dòng)發(fā)起?；钫?qǐng)求方在給定時(shí)間沒(méi)有 收到進(jìn)行協(xié)商的響應(yīng)消息，或者被動(dòng)接受?；钫?qǐng)求方在預(yù)定時(shí)間沒(méi)有收到保活請(qǐng)求時(shí)，則 判定會(huì)話終止，釋放會(huì)話，同時(shí)釋放該會(huì)話對(duì)應(yīng)的資源。形式二，在會(huì)話建立后，UAC或者UAS因?yàn)樾枨笤诤罄m(xù)的對(duì)話內(nèi)請(qǐng)求Update中發(fā) 起會(huì)話?；钫?qǐng)求(攜帶RFC4(^8規(guī)定的用于?；畹男畔?。形式三，核心網(wǎng)元也可以根據(jù)具體策略來(lái)主動(dòng)在消息轉(zhuǎn)發(fā)到下一跳時(shí)增加 Session Timers相關(guān)的信息，表明希望能和下一跳之間實(shí)現(xiàn)kssion Timers功能。RFC4028中的會(huì)話檢測(cè)是針對(duì)?；顚?duì)象的雙方都滿足該協(xié)議時(shí)定義的。在IMS 應(yīng)用中，當(dāng)所有SIP網(wǎng)元(包括終端)都必須支持RFC4028，并且在應(yīng)用中，各網(wǎng)元之 間都希望在會(huì)話期間使用kssion Timers功能時(shí)，流程大致相似，差異主要在于協(xié)商 后續(xù)執(zhí)Session Timers功能的請(qǐng)求發(fā)起者以及?；畹臅r(shí)間間隔(主要體現(xiàn)在頭部 Session-Expires)0圖1是根據(jù)相關(guān)技術(shù)的IMS網(wǎng)絡(luò)網(wǎng)元均支持且希望在會(huì)話中使用kssion Timer 的流程圖，該圖以會(huì)話的發(fā)起者主動(dòng)要求在會(huì)話期間執(zhí)行kssionTimers功能為例，對(duì)該 流程進(jìn)行說(shuō)明，該流程經(jīng)過(guò)代理呼叫會(huì)話控制功能實(shí)體(Proxy-Call Session Control Function,簡(jiǎn)稱(chēng)為P-CSCF)、服務(wù)呼叫會(huì)話控制功能實(shí)體Gerving-CSCF，簡(jiǎn)稱(chēng)為S-CSCF)以 及查詢(xún)呼叫會(huì)話控制功能實(shí)體anterrogating-CSCF，簡(jiǎn)稱(chēng)為I-CSCF)，如圖1所示，該流程 包括如下步驟步驟S101，主叫用戶(hù)(UAC)發(fā)起初始INVITE請(qǐng)求消息，該請(qǐng)求消息中攜帶了如 下信息=Session-Expires :90，Min-SE :90，Supported :timer。這些信息表明，終端支持Session Timers，且提供了自己的?；铋g隔。步驟S102，主叫側(cè)的P-CSCF網(wǎng)元轉(zhuǎn)發(fā)該消息，該P(yáng)-CSCF默認(rèn)支持^^8丨011 Timers 功能。步驟S103,核心網(wǎng)元I/S-CSCF網(wǎng)元轉(zhuǎn)發(fā)消息，該I/S-CSCF默認(rèn)支持Session Timers 功能。步驟S104，被叫側(cè)的P-CSCF網(wǎng)元轉(zhuǎn)發(fā)消息，該核心網(wǎng)元P-CSCF默認(rèn)支持kssion Timers 功能。步驟S105，被叫用戶(hù)(UAS)接收到該消息后，接受來(lái)自主叫的kssionTimer相關(guān) 約定，同意在會(huì)話中開(kāi)啟kssion Timer功能。被叫側(cè)在回復(fù)的2000K消息中增加如下信 息，以提供 Session Timer 的協(xié)商結(jié)果Session-Expires :90, refresher :uac,Min-SE :90, Require :timer。被叫回復(fù)了 2000K消息之后，啟動(dòng)kssion Timer定時(shí)器。步驟S106，被叫側(cè)P-CSCF接收到2000K(INVITE)消息后，與本地相關(guān)信息進(jìn)行匹 配，協(xié)商成功后向核心網(wǎng)側(cè)轉(zhuǎn)發(fā)該消息，并啟動(dòng)kssion Timer定時(shí)器。步驟S107，核心網(wǎng)元I/S-CSCF接收到2000K(INVITE)消息后，與本地相關(guān)信息進(jìn) 行匹配，協(xié)商成功后向核心網(wǎng)側(cè)轉(zhuǎn)發(fā)該消息，并啟動(dòng)kssion Timer定時(shí)器。步驟S108，主叫側(cè)P-CSCF，接收到2000K(INVITE)消息后，與本地相關(guān)信息進(jìn)行匹 配，協(xié)商成功后啟動(dòng)kssion Timer定時(shí)器。步驟S109、步驟S110、步驟Slll以及步驟S112，發(fā)送確認(rèn)(ACK)消息進(jìn)行轉(zhuǎn)發(fā)。步驟S113，主叫側(cè)kssion Timer定時(shí)器超時(shí)，主動(dòng)發(fā)起kssion Timer請(qǐng)求 UPDATE，該請(qǐng)求消息包含Session-Expires :90，Min-SE :90。步驟S114，主叫側(cè) P-CSCF 接收到 kssion Timer 請(qǐng)求 UPDATE，殺 kssion Timer 定時(shí)器，轉(zhuǎn)發(fā)UPDATE消息。步驟S 115，核心網(wǎng)元 I/S-CSCF 接收到 kssion Timer 請(qǐng)求 UPDATE，殺 Session Timer定時(shí)器，轉(zhuǎn)發(fā)UPDATE消息。步驟S116，被叫側(cè) P-CSCF 接收到 kssion Timer 請(qǐng)求 UPDATE，殺 kssion Timer 定時(shí)器，轉(zhuǎn)發(fā)UPDATE消息。步驟S117，被叫用戶(hù)(UAS)接收到 kssion Timer 的 UPDATE 請(qǐng)求，殺 kssion Timer 定時(shí)器，回復(fù) 2000K(UPDATE)。步驟S118、步驟S119以及步驟S120，轉(zhuǎn)發(fā)kssion Timer的UPDATE請(qǐng)求的響應(yīng) 消息2000K，各網(wǎng)元在收到2000K(UPDATE)后，均重新設(shè)置kssion Timer定時(shí)器。步驟S113-步驟S120之間的步驟將一直以kssion Timer定時(shí)器為周期執(zhí)行，直 到出現(xiàn)網(wǎng)絡(luò)異?；蛘邥?huì)話被終止。上述的步驟均是在會(huì)話?；铍p方均支持RFC4028時(shí)才能執(zhí)行，當(dāng)會(huì)話?；畹囊环?不支持RFC4(^8時(shí)，會(huì)話?；罹筒荒軋?zhí)行。在IMS體系中，多數(shù)核心網(wǎng)元(比如P/I/S-CSCF)已經(jīng)滿足了 RFC4028，能夠有效 實(shí)現(xiàn)會(huì)話保活功能。但SIP協(xié)議的應(yīng)用早在1999年前就開(kāi)始，而RFC4(^8則在2005年才 出現(xiàn)，在這個(gè)時(shí)間間隔內(nèi)市場(chǎng)、網(wǎng)絡(luò)上已經(jīng)出現(xiàn)了大量的SIP終端，這些終端應(yīng)該是不會(huì)支 持RFC4028的，同樣的2005年以后也會(huì)存在終端提供者沒(méi)有實(shí)現(xiàn)RFC4028的，一旦這些不 支持RFC4208的終端接入IMS網(wǎng)絡(luò)，將無(wú)法提供會(huì)話?；睿@將很容易造成P/I/S-CSCF等SIP網(wǎng)絡(luò)實(shí)體資源耗盡，導(dǎo)致P/I/S-CSCF等SIP網(wǎng)絡(luò)實(shí)體將無(wú)法為合法用戶(hù)提供正常服務(wù)。

發(fā)明內(nèi)容
本發(fā)明的主要目的在于提供會(huì)話?；罘椒把b置，以至少解決上述問(wèn)題。根據(jù)本發(fā)明的一個(gè)方面，提供了一種會(huì)話保活方法，包括網(wǎng)絡(luò)側(cè)的網(wǎng)元接收到消 息，并確定所述消息中未攜帶RFC4(^8規(guī)定的用于?；畹男畔ⅲ凰鼍W(wǎng)元設(shè)置會(huì)話定時(shí)器， 并在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送用于保活的?；钕ⅲ辉诎l(fā)送所述?；钕⒅蠡蛘?在接收到響應(yīng)于所述?；钕⒌谋；铐憫?yīng)消息之后，所述網(wǎng)元重啟所述會(huì)話定時(shí)器。優(yōu)選地，在所述網(wǎng)元確定所述消息中未攜帶所述用于?；畹男畔⒅?，所述方法 還包括所述網(wǎng)元發(fā)送用于查詢(xún)是否支持RFC4028的查詢(xún)消息；所述網(wǎng)元接收所述查詢(xún)消 息的響應(yīng)消息，根據(jù)所述查詢(xún)消息的響應(yīng)消息確定該響應(yīng)消息的發(fā)送方不支持RFC4028，并 在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述保活消息。優(yōu)選地，所述查詢(xún)消息為選項(xiàng)OPTION消息。優(yōu)選地，所述網(wǎng)元在接收到的所述消息中添加RFC4(^8規(guī)定的用于?；畹男畔ⅲ?并發(fā)送所述消息；所述網(wǎng)元接收到所述消息的響應(yīng)消息，并根據(jù)所述消息的響應(yīng)消息中是 否攜帶有RFC4(^8規(guī)定的用于保活的信息來(lái)判斷所述消息的響應(yīng)消息的發(fā)送方是否支持 RFC4028 ；所述網(wǎng)元在所述響應(yīng)消息的發(fā)送方不支持RFC4028的情況下，在所述會(huì)話定時(shí)器 到時(shí)之后，發(fā)送所述保活消息。優(yōu)選地，在所述網(wǎng)元確定該響應(yīng)消息的發(fā)送方支持RFC4028的情況下，所述方法 還包括；所述網(wǎng)元與所述響應(yīng)消息的發(fā)送方進(jìn)行RFC4(^8規(guī)定的會(huì)話保活的協(xié)商，并根據(jù) 協(xié)商的結(jié)果進(jìn)行會(huì)話?；?。優(yōu)選地，在所述響應(yīng)消息還攜帶有所述響應(yīng)消息的發(fā)送方所支持的所述?；钕?的類(lèi)型的情況下，所述網(wǎng)元在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送與所述類(lèi)型對(duì)應(yīng)的?；钕ⅰ?yōu)選地，所述?；钕⒌念?lèi)型包括邀請(qǐng)INVITE消息、更新UPDATE消息。根據(jù)本發(fā)明的另一方面，提供了一種會(huì)話?；钛b置，位于網(wǎng)絡(luò)側(cè)的網(wǎng)元中，該裝置 包括接收模塊，用于接收到消息，并確定所述消息中未攜帶RFC4(^8規(guī)定的用于?；畹男?息；會(huì)話定時(shí)器設(shè)置模塊，用于設(shè)置會(huì)話定時(shí)器；第一發(fā)送模塊，用于在所述會(huì)話定時(shí)器到 時(shí)之后，發(fā)送用于?；畹谋；钕?；所述會(huì)話定期器設(shè)置模塊，還用于在發(fā)送所述?；钕?之后或者在接收到響應(yīng)于所述保活消息的?；铐憫?yīng)消息之后，重啟所述會(huì)話定時(shí)器。優(yōu)選地，該裝置還包括第二發(fā)送模塊，用于在確定所述消息中未攜帶所述用于保 活的信息之后，發(fā)送用于查詢(xún)是否支持RFC4028的查詢(xún)消息；所述第一發(fā)送模塊還用于在 根據(jù)所述查詢(xún)消息的響應(yīng)消息確定該響應(yīng)消息的發(fā)送方不支持RFC4028的情況下，并在所 述會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述?；钕?。優(yōu)選地，該裝置還包括第三發(fā)送模塊，用于在接收到的所述消息中添加RFC4028 規(guī)定的用于?；畹男畔?，并發(fā)送所述消息；所述第一發(fā)送模塊，還用于在根據(jù)所述消息的響 應(yīng)消息中是否攜帶有RFC4(^8規(guī)定的用于?；畹男畔?lái)確定所述消息的響應(yīng)消息的發(fā)送 方不支持RFC4028的情況下；并在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述保活消息。通過(guò)本發(fā)明，解決了相關(guān)技術(shù)中不支持RFC4(^8則不能提供會(huì)話?；疃鴮?dǎo)致的問(wèn) 題，進(jìn)而提供了在不支持RFC4(^8時(shí)會(huì)話?；畹闹С?。


此處所說(shuō)明的附圖用來(lái)提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā) 明的示意性實(shí)施例及其說(shuō)明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中圖1是根據(jù)相關(guān)技術(shù)的IMS網(wǎng)絡(luò)網(wǎng)元均支持且希望在會(huì)話中使用kssion Timer 的流程圖；圖2是根據(jù)本發(fā)明實(shí)施例的會(huì)話保活方法的流程圖；圖3是根據(jù)本發(fā)明實(shí)施例的會(huì)話保活裝置的結(jié)構(gòu)框圖；圖4是根據(jù)本發(fā)明優(yōu)選實(shí)施例的會(huì)話?；钛b置的結(jié)構(gòu)框圖一；圖5是根據(jù)本發(fā)明優(yōu)選實(shí)施例的會(huì)話?；钛b置的結(jié)構(gòu)框圖二 ；圖6是根據(jù)本發(fā)明實(shí)施例的主叫側(cè)核心網(wǎng)網(wǎng)元主動(dòng)發(fā)起同主叫之間的會(huì)話檢測(cè) 的流程圖；圖7是根據(jù)本發(fā)明實(shí)施例的被叫側(cè)核心網(wǎng)網(wǎng)元主動(dòng)發(fā)起同被叫之間的會(huì)話檢測(cè) 的流程圖。
具體實(shí)施例方式下文中將參考附圖并結(jié)合實(shí)施例來(lái)詳細(xì)說(shuō)明本發(fā)明。需要說(shuō)明的是，在不沖突的 情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的特征可以相互組合。以下實(shí)施例可以應(yīng)用于支持SIP協(xié)議的網(wǎng)絡(luò)中，例如，IMS網(wǎng)絡(luò)(但是并不限于 此)，其他支持SIP協(xié)議網(wǎng)絡(luò)也可以應(yīng)用。在本實(shí)施例中，提供了會(huì)話?；罘椒?，圖2是根據(jù)本發(fā)明實(shí)施例的會(huì)話保活方法 的流程圖，如圖2所示，該流程包括以下步驟步驟S202，網(wǎng)絡(luò)側(cè)的網(wǎng)元接收到消息，并確定該消息中未攜帶RFC4(^8規(guī)定的用 于保活的信息；步驟S204，該網(wǎng)元設(shè)置會(huì)話定時(shí)器，并在上述會(huì)話定時(shí)器到時(shí)之后，發(fā)送用于保活 的?；钕?；步驟S206，在發(fā)送?；钕⒅蠡蛘咴诮邮盏巾憫?yīng)于?；钕⒌谋；铐憫?yīng)消息之 后，網(wǎng)元重啟會(huì)話定時(shí)器。通過(guò)上述步驟，網(wǎng)元在接收到消息時(shí)，即使該消息中未攜帶用于保活的信息，也可 以主動(dòng)設(shè)置會(huì)話定時(shí)器，從而實(shí)現(xiàn)?；?。例如，該網(wǎng)元可以向被叫用戶(hù)或者其他網(wǎng)元發(fā)送攜 帶有RFC4(^8規(guī)定的用于?；畹男畔?，在接收到響應(yīng)消息之后，由于被叫用戶(hù)或其他網(wǎng)元 支持RFC4028，因此響應(yīng)消息中不會(huì)攜帶用于?；畹男畔?，此時(shí)該網(wǎng)元可以主動(dòng)進(jìn)行?；顖?zhí) 行上述步驟S204和步驟S206。在實(shí)施時(shí)，接收到消息中未攜帶用于?；畹男畔⒁膊荒苷f(shuō)明該消息的發(fā)送方一 定不支持RFC4028，例如，該消息的發(fā)送方支持RFC4028，但是并沒(méi)有主動(dòng)發(fā)起保活，因此， 優(yōu)選地，還可以在網(wǎng)元確定消息中未攜帶用于保活的信息之后，發(fā)送用于查詢(xún)是否支持 RFC4028的查詢(xún)消息(例如，該查詢(xún)消息可以為選項(xiàng)OPTION消息)，該網(wǎng)元接收查詢(xún)消息的 響應(yīng)消息之后，根據(jù)該查詢(xún)消息的響應(yīng)消息確定該響應(yīng)消息的發(fā)送方不支持RFC4028，并在 所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述保活消息。或者，該網(wǎng)元可以在接收到的消息中添加RFC4028規(guī)定的用于?；畹男畔?，并發(fā)送該消息；在接收到該消息的響應(yīng)消息之后，根據(jù)該 消息的響應(yīng)消息中是否攜帶有RFC4028規(guī)定的用于?；畹男畔?lái)判斷該消息的響應(yīng)消息 的發(fā)送方是否支持RFC4028 ；該網(wǎng)元在該響應(yīng)消息的發(fā)送方不支持RFC4(^8的情況下，在會(huì) 話定時(shí)器到時(shí)之后，發(fā)送?；钕?。優(yōu)選地，如果上述網(wǎng)元確定該響應(yīng)消息的發(fā)送方支持RFC4028，則網(wǎng)元可以與響應(yīng) 消息的發(fā)送方進(jìn)行RFC4(^8規(guī)定的會(huì)話?；畹膮f(xié)商，并根據(jù)協(xié)商的結(jié)果進(jìn)行會(huì)話?；?即 進(jìn)行RFC4(^8規(guī)定的步驟)。當(dāng)然，也可以不進(jìn)行協(xié)商，而直接采用步驟S204和步驟S206。優(yōu)選地，在實(shí)施時(shí)，在上述響應(yīng)消息中還可以攜帶響應(yīng)消息的發(fā)送方所支持的保 活消息的類(lèi)型，在這種情況下，該網(wǎng)元在會(huì)話定時(shí)器到時(shí)之后，發(fā)送與類(lèi)型對(duì)應(yīng)的保活消息 (例如，邀請(qǐng)INVITE消息、更新UPDATE消息)。在本實(shí)施例中，還提供了一種會(huì)話?；钛b置，該裝置位于網(wǎng)絡(luò)側(cè)的網(wǎng)元中，該裝置 用于實(shí)現(xiàn)上述實(shí)施例及其優(yōu)選實(shí)施方式，已經(jīng)進(jìn)行過(guò)說(shuō)明的不再贅述，下面對(duì)該裝置中涉 及到的模塊進(jìn)行說(shuō)明。圖3是根據(jù)本發(fā)明實(shí)施例的會(huì)話?；钛b置的結(jié)構(gòu)框圖，如圖3所示， 該裝置包括接收模塊32，會(huì)話定時(shí)器設(shè)置模塊34，第一發(fā)送模塊36。下面對(duì)該結(jié)構(gòu)進(jìn)行 說(shuō)明。接收模塊32，用于接收到消息，并確定該消息中未攜帶RFC4(^8規(guī)定的用于?；?的信息；會(huì)話定時(shí)器設(shè)置模塊34連接至接收模塊32，該模塊用于設(shè)置會(huì)話定時(shí)器；第一發(fā) 送模塊36連接至?xí)挾〞r(shí)器設(shè)置模塊34，該模塊用于在會(huì)話定時(shí)器到時(shí)之后，發(fā)送用于保 活的保活消息；會(huì)話定時(shí)器設(shè)置模塊34還用于在發(fā)送該?；钕⒅蠡蛘咴诮邮盏巾憫?yīng) 于該保活消息的?；铐憫?yīng)消息之后，重啟會(huì)話定時(shí)器。圖4是根據(jù)本發(fā)明優(yōu)選實(shí)施例的會(huì)話?；钛b置的結(jié)構(gòu)框圖一，如圖4所示，該裝置 還包括第二發(fā)送模塊，該模塊用于在確定該消息中未攜帶用于?；畹男畔⒅?，發(fā)送用于 查詢(xún)是否支持RFC4028的查詢(xún)消息。第一發(fā)送模塊36用于在根據(jù)該查詢(xún)消息的響應(yīng)消息 確定該響應(yīng)消息的發(fā)送方不支持RFC4028的情況下，并在會(huì)話定時(shí)器到時(shí)之后，發(fā)送該保 活消息。圖5是根據(jù)本發(fā)明優(yōu)選實(shí)施例的會(huì)話保活裝置的結(jié)構(gòu)框圖二，如圖5所示，該裝 置還包括第三發(fā)送模塊52，該模塊用于在接收到的該消息中添加RFC4(^8規(guī)定的用于保 活的信息，并發(fā)送該消息。第一發(fā)送模塊36，用于在根據(jù)該消息的響應(yīng)消息中是否攜帶有 RFC4028規(guī)定的用于?；畹男畔?lái)確定該消息的響應(yīng)消息的發(fā)送方不支持RFC4028的情況 下；并在會(huì)話定時(shí)器到時(shí)之后，發(fā)送該保活消息。以下以IP多媒體子系統(tǒng)(IMS)為例結(jié)合優(yōu)選實(shí)施例進(jìn)行說(shuō)明。在本優(yōu)選實(shí)施例中，當(dāng)IMS接入側(cè)核心網(wǎng)元(以P-CSCF網(wǎng)元為例進(jìn)行說(shuō)明)是 在會(huì)話的主叫側(cè)時(shí)，需要在對(duì)話建立前從初始INVITE或者對(duì)話內(nèi)INVITE\UPDATE中提取 RFC4028中的相關(guān)信息來(lái)識(shí)別會(huì)話的發(fā)起者(UAC)是否支持該擴(kuò)展協(xié)議。當(dāng)會(huì)話發(fā)起者不 支持該擴(kuò)展協(xié)議時(shí)，在該會(huì)話的關(guān)聯(lián)信息中記錄，“終端不支持RFC4028”。當(dāng)會(huì)話建立成功 (接收到初始INVITE的成功握手ACK消息、或者接收到INVITE的2000K消息)后，設(shè)置一 個(gè)會(huì)話?；疃〞r(shí)器，refresh timer，可以遵循RFC4(^8協(xié)議，該定時(shí)器最小時(shí)長(zhǎng)為90秒。 然后，向會(huì)話的發(fā)起者發(fā)出Options請(qǐng)求查詢(xún)?cè)摻K端是否支持RFC4028。當(dāng)會(huì)話的發(fā)起者 支持RFC4028時(shí)，P-CSCF網(wǎng)元會(huì)在refresh timer超時(shí)后主動(dòng)向會(huì)話的發(fā)起者發(fā)起對(duì)話內(nèi)INVITE或者Update消息(當(dāng)能力查詢(xún)結(jié)果表明終端支持UPDATE方法時(shí))，與終端來(lái)協(xié)商 會(huì)話?；畹臅r(shí)間機(jī)制(包括時(shí)間、主動(dòng)發(fā)起者)，具體過(guò)程遵循RFC4028。當(dāng)通過(guò)能力查詢(xún) 獲取終端確實(shí)不支持RFC4028時(shí)，P-CSCF網(wǎng)元?jiǎng)t在refresh timer超時(shí)后主動(dòng)向終端發(fā)起 對(duì)話內(nèi)NVITE或者Update消息(當(dāng)能力查詢(xún)結(jié)果表明終端支持UPDATE方法時(shí))，同時(shí)再次 啟動(dòng)該 refresh timer。當(dāng)會(huì)話?；钫?qǐng)求超時(shí)未收到響應(yīng)消息則認(rèn)為網(wǎng)絡(luò)異?；蛘呓K端異常，P-CSCF網(wǎng)元 判斷終端異?；蛘弋?dāng)前會(huì)話異常，釋放相關(guān)資源，同時(shí)主動(dòng)向網(wǎng)絡(luò)測(cè)發(fā)起釋放消息BYE，以 使鄰接網(wǎng)元也能盡快釋放異常資源，有效為其他會(huì)話提供服務(wù)。當(dāng)會(huì)話?；钫?qǐng)求收到了響 應(yīng)消息后，則表明會(huì)話正常使用中，待refresh timer定時(shí)器超時(shí)后再次主動(dòng)發(fā)起請(qǐng)求，依 次循環(huán)直到會(huì)話釋放。圖6是根據(jù)本發(fā)明實(shí)施例的主叫側(cè)核心網(wǎng)網(wǎng)元主動(dòng)發(fā)起同主叫之間的會(huì)話檢測(cè) 的流程圖，如圖6所示，該流程包括以下步驟步驟S601，P-CSCF收到來(lái)自主叫側(cè)的SIPINVITE消息，該信息中無(wú)kssion Timer 相關(guān)信息。步驟S602，P-CSCF轉(zhuǎn)發(fā)消息。步驟S603，P-CSCF接收來(lái)自被叫側(cè)的2000K(INVITE) ；P-CSCF通過(guò)從INVITE以及 2000K (INVITE)中提取主叫側(cè)的kssion Timer相關(guān)信息，結(jié)果是“無(wú)kssion Timer相關(guān) fn息 ο步驟S604，P-CSCF向終端轉(zhuǎn)發(fā)2000K(INVITE) ；P-CSCF設(shè)置會(huì)話?；疃〞r(shí)器， refresh timer,時(shí)長(zhǎng)為 90s。步驟S605，P-CSCF發(fā)OPTIONS消息，查詢(xún)主叫的能力。步驟S606，P-CSCF接收來(lái)自的用戶(hù)的響應(yīng)2000K (OPTIONS) ；P-CSCF從2000K中提 取信息是否存在Supported timer, Allow :UPDATE。這兩個(gè)條件可以有四種組合第一種，兩者均存在，則表明主叫用戶(hù)已經(jīng)支持RFC4028。P-CSCF可以在S204設(shè) 置的定時(shí)器超時(shí)后，向主叫側(cè)發(fā)起UPDATE請(qǐng)求，進(jìn)行kssion Timer協(xié)商。第二種，只有Supported timer,則表明終端支持RFC4028，但不支持UPDATE方法 (RFC3311)，則P-CSCF可以在S204設(shè)置的定時(shí)器超時(shí)后，向主叫側(cè)發(fā)起對(duì)話內(nèi)的INVITE請(qǐng) 求，進(jìn)行Session Timer協(xié)商。第三種，只有Allow =UPDATE,那么表明終端不支持RFC4028，則P-CSCF可以在 S204設(shè)置的定時(shí)器超時(shí)后，向主叫側(cè)發(fā)起對(duì)話內(nèi)的UPDATE請(qǐng)求。第四種，兩者都不存在，則P-CSCF可以在S204設(shè)置的定時(shí)器超時(shí)后，向主叫側(cè)發(fā) 起對(duì)話內(nèi)的INVITE請(qǐng)求。該圖是針對(duì)第三種的。第一種、第二種的處理基本就是遵循RFC4028 了，第三種、 第四種情況其實(shí)是一樣的，只是會(huì)話?；畹恼?qǐng)求方法不同。UPDATE方法不存在握手所以流 程圖上就會(huì)簡(jiǎn)單些。步驟S607，步驟S604設(shè)置的refresh timer超時(shí)，P-CSCF向主叫側(cè)發(fā)起SIP UPDATE 消息。步驟S608，P-CSCF 接收到 2000K (UPDATE)；然后重新設(shè)置 refresh timer 定時(shí)器。步驟S609，步驟S607設(shè)置的refresh timer超時(shí)，P-CSCF向主叫側(cè)發(fā)起SIPUPDATE 消息。步驟S610,P-CSCF 接收到 2000K (UPDATE)；然后重新設(shè)置 refresh timer 定時(shí)器。步驟S607-S610將以refresh timer為間隔有規(guī)律的循環(huán)執(zhí)行，直到會(huì)話終止，或 者出現(xiàn)網(wǎng)絡(luò)等異常。步驟S611，P-CSCF 因 refresh timer 超時(shí)再次發(fā)起 UPDATE 請(qǐng)求。步驟S612，當(dāng)出現(xiàn)網(wǎng)絡(luò)異常，或者UPDATE請(qǐng)求超時(shí)無(wú)應(yīng)答時(shí)，P-CSCF網(wǎng)元判定終 端異常，會(huì)話終止，速向網(wǎng)絡(luò)側(cè)發(fā)送BYE消息，以通知其他會(huì)話中的網(wǎng)元即時(shí)釋放資源。步驟S613，P-CSCF接收2000K (BYE)，釋放會(huì)話相關(guān)資源。當(dāng)P-CSCF網(wǎng)元在會(huì)話的被叫側(cè)時(shí)，對(duì)被叫用戶(hù)而言，P-CSCF網(wǎng)元是初始消息的發(fā) 起者。P-CSCF網(wǎng)元接收到待轉(zhuǎn)發(fā)的初始INVITE請(qǐng)求時(shí)，P-CSCF網(wǎng)元需要檢查該請(qǐng)求消息 中是否存在RFC4028中的特征屬性。當(dāng)初始INVITE中不存在會(huì)話?；畹男畔r(shí)，則主動(dòng)在 消息中添加 Supported :timer, Session-Expires = 90,Min-SE = 90 等頭部。當(dāng)接收到初 始請(qǐng)求的最終成功響應(yīng)2000K時(shí)，需要檢查是否存在會(huì)話?；钕嚓P(guān)信息。當(dāng)確定不存在會(huì) 話?；钕嚓P(guān)信息時(shí)，基本表明被叫終端不支持RFC4028，則需要設(shè)置一個(gè)會(huì)話?；疃〞r(shí)器， refresh timer，可以遵循RFC4(^8協(xié)議，該定時(shí)器最小時(shí)長(zhǎng)為90秒。在會(huì)話結(jié)束前當(dāng)該定 時(shí)器超時(shí)，P-CSCF網(wǎng)元主動(dòng)向被叫發(fā)起對(duì)話內(nèi)請(qǐng)求INVITE或者UPDATE消息，同時(shí)再次啟 動(dòng)refreshtimer定時(shí)器。當(dāng)請(qǐng)求超時(shí)未接收到響應(yīng)則判定與此終端的會(huì)話出現(xiàn)異常，需要 立即釋放相關(guān)資源，并同時(shí)向網(wǎng)絡(luò)測(cè)主動(dòng)發(fā)起B(yǎng)YE消息，以通知其他網(wǎng)元釋放資源。會(huì)話保 活請(qǐng)求發(fā)出，且收到了響應(yīng)，則表明會(huì)話正常使用中，待refresh timer定時(shí)器超時(shí)后再次 主動(dòng)發(fā)起請(qǐng)求，依次循環(huán)直到會(huì)話釋放。圖7是根據(jù)本發(fā)明實(shí)施例的被叫側(cè)核心網(wǎng)網(wǎng)元主動(dòng)發(fā)起同被叫之間的會(huì)話檢測(cè) 流程圖，如圖7所示，該流程包括以下步驟步驟S701，被叫側(cè)的P-CSCF收到核心網(wǎng)的SIP INVITE消息。步驟S702, P-CSCF從SIP INVITE消息提取Session Timer相關(guān)信息，若沒(méi) 有提取到相關(guān)信息，P-CSCF網(wǎng)元主動(dòng)在消息轉(zhuǎn)發(fā)前添加kssion Timer相關(guān)信息 Session-Expires :90, Min-SE :90。步驟S703，P-CSCF接收來(lái)自被叫用戶(hù)(UAS)的響應(yīng)消息2000K (INVITE)，檢查碼 流中是否存在kssion Timer相關(guān)信息，且有Require :timer。上面的兩個(gè)條件有4種可 能第一種，當(dāng)兩者同時(shí)存在時(shí)，表明終端支持RFC4028，且希望在會(huì)話內(nèi)執(zhí)行該功能， P-CSCF可以啟動(dòng)會(huì)話?；疃〞r(shí)器refreSh timer，該時(shí)間也2000K中協(xié)商的時(shí)間為準(zhǔn)。第二種，只有Require timer,這種情況，也表明終端支持RFC4028，且愿意在會(huì)話 期間執(zhí)Sksssion Timer功能。P-CSCF可以啟動(dòng)會(huì)話?；疃〞r(shí)器refresh timer，該時(shí) 間以轉(zhuǎn)發(fā)請(qǐng)求時(shí)添加的時(shí)間為準(zhǔn)。第三種，當(dāng)只有kssion Timer相關(guān)信息，無(wú)Require :timer，則表明終端不支持 RFC4028，P-CSCF則可以啟動(dòng)會(huì)話?；疃〞r(shí)器，refresh timer，時(shí)長(zhǎng)遵循RFC4028，取值最小 為 90s。第四種，兩者均無(wú)，這種情況等同于第三種，即表明被叫不支持RFC4028，此時(shí)基本 上P-CSCF的處理與第三種類(lèi)似，該圖7是第三種情況的處理。第一種、第二種則表明終端支持RFC4028，后續(xù)的處理也遵循RFC4028。步驟S704，P-CSCF 轉(zhuǎn)發(fā) 2000K (INVITE)。步驟S705，步驟S703中的第3、4種情況下設(shè)置的kssion Timer定時(shí)器refresh timer超時(shí)，P-CSCF向終端發(fā)會(huì)話?；钫?qǐng)求SIP UPDATE消息。步驟S706，P-CSCF 接收 2000K (UPDATE)；設(shè)置 refresh timer 定時(shí)器。步驟S707，重復(fù)步驟S705，refreshtimer定時(shí)器超時(shí)，P-CSCF向終端發(fā)會(huì)話?；?請(qǐng)求SIPUPDATE消息；步驟S708，重復(fù)步驟 S706，P-CSCF 接收 2000K (UPDATE)；設(shè)置 refresh timer 定時(shí)
ο步驟S705-S708將以refreshtimer為間隔有規(guī)律的循環(huán)執(zhí)行，直到會(huì)話終止，或 者出現(xiàn)網(wǎng)絡(luò)等異常。步驟S709，當(dāng)refreshtimer定時(shí)器超時(shí)，P-CSCF向終端發(fā)會(huì)話?；钫?qǐng)求 SIPUPDATE消息，請(qǐng)求超時(shí)未收到響應(yīng)消息，則P-CSCF判斷網(wǎng)絡(luò)異?；蛘呓K端異常，決定終 止呼叫。步驟S710，P-CSCF向網(wǎng)絡(luò)側(cè)發(fā)送BYE消息，通知本會(huì)話中其他網(wǎng)元釋放會(huì)話相關(guān) 資源P-CSCF接收到2000K(BYE)，釋放本次會(huì)話相關(guān)資源，會(huì)話結(jié)束。優(yōu)選地，上述步驟中P-CSCF可以是任意支持RFC4(^8的網(wǎng)元，包括但不限于P/I/ S-CSCF, AGCF, SBC、Application-Service 等。當(dāng) SIP 網(wǎng)元雙方都不支持 RFC4(^8 時(shí)，核心 網(wǎng)絡(luò)上的網(wǎng)元也可以按照上述實(shí)施例及其優(yōu)選實(shí)施方式來(lái)實(shí)現(xiàn)會(huì)話保護(hù)機(jī)制。優(yōu)選地，上述步驟中的會(huì)話保活請(qǐng)求消息包括但不限于INVITE消息、UPDATE消 息、OPTIONS消息等。優(yōu)選地，上述步驟中被叫側(cè)的會(huì)話?；钸€可以采用同主叫側(cè)類(lèi)似的方法在接收 到成功響應(yīng)的握手消息ACK后，主動(dòng)向被叫終端發(fā)起能力查詢(xún)請(qǐng)求，以進(jìn)一步了解終端的 能力。綜上所述，通過(guò)上述實(shí)施例解決了相關(guān)技術(shù)中不支持RFC4(^8則不能提供會(huì)話保 活而導(dǎo)致的問(wèn)題，提供了在不支持RFC4028時(shí)對(duì)會(huì)話保活的支持。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用 的計(jì)算裝置來(lái)實(shí)現(xiàn)，它們可以集中在單個(gè)的計(jì)算裝置上，或者分布在多個(gè)計(jì)算裝置所組成 的網(wǎng)絡(luò)上，可選地，它們可以用計(jì)算裝置可執(zhí)行的程序代碼來(lái)實(shí)現(xiàn)，從而，可以將它們存儲(chǔ) 在存儲(chǔ)裝置中由計(jì)算裝置來(lái)執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示 出或描述的步驟，或者將它們分別制作成各個(gè)集成電路模塊，或者將它們中的多個(gè)模塊或 步驟制作成單個(gè)集成電路模塊來(lái)實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技 術(shù)人員來(lái)說(shuō)，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修 改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種會(huì)話保活方法，其特征在于包括網(wǎng)絡(luò)側(cè)的網(wǎng)元接收到消息，并確定所述消息中未攜帶RFC4(^8規(guī)定的用于保活的信息；所述網(wǎng)元設(shè)置會(huì)話定時(shí)器，并在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送用于保活的?；钕?；在發(fā)送所述?；钕⒅蠡蛘咴诮邮盏巾憫?yīng)于所述保活消息的?；铐憫?yīng)消息之后，所 述網(wǎng)元重啟所述會(huì)話定時(shí)器。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述網(wǎng)元確定所述消息中未攜帶所述用于?；畹男畔⒅螅龇椒ㄟ€包括所述 網(wǎng)元發(fā)送用于查詢(xún)是否支持RFC4028的查詢(xún)消息；所述網(wǎng)元接收所述查詢(xún)消息的響應(yīng)消息，根據(jù)所述查詢(xún)消息的響應(yīng)消息確定該響應(yīng)消 息的發(fā)送方不支持RFC4028，并在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述?；钕ⅰ?br> 3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述查詢(xún)消息為選項(xiàng)OPTION消息。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述網(wǎng)元在接收到的所述消息中添加RFC4(^8規(guī)定的用于保活的信息，并發(fā)送所述消息；所述網(wǎng)元接收到所述消息的響應(yīng)消息，并根據(jù)所述消息的響應(yīng)消息中是否攜帶有 RFC4028規(guī)定的用于?；畹男畔?lái)判斷所述消息的響應(yīng)消息的發(fā)送方是否支持RFC4028 ；所述網(wǎng)元在所述響應(yīng)消息的發(fā)送方不支持RFC4028的情況下，在所述會(huì)話定時(shí)器到時(shí) 之后，發(fā)送所述?；钕ⅰ?br> 5.根據(jù)權(quán)利要求2至4中任一項(xiàng)所述的方法，其特征在于，在所述網(wǎng)元確定該響應(yīng)消息 的發(fā)送方支持RFC4028的情況下，所述方法還包括；所述網(wǎng)元與所述響應(yīng)消息的發(fā)送方進(jìn)行RFC4(^8規(guī)定的會(huì)話保活的協(xié)商，并根據(jù)協(xié)商 的結(jié)果進(jìn)行會(huì)話?；?。
6.根據(jù)權(quán)利要求2至4中任一項(xiàng)所述的方法，其特征在于，在所述響應(yīng)消息還攜帶有所 述響應(yīng)消息的發(fā)送方所支持的所述?；钕⒌念?lèi)型的情況下，所述網(wǎng)元在所述會(huì)話定時(shí)器 到時(shí)之后，發(fā)送與所述類(lèi)型對(duì)應(yīng)的?；钕?。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述?；钕⒌念?lèi)型包括邀請(qǐng)INVITE 消息、更新UPDATE消息。
8.一種會(huì)話保活裝置，位于網(wǎng)絡(luò)側(cè)的網(wǎng)元中，其特征在于包括接收模塊，用于接收到消息，并確定所述消息中未攜帶RFC4(^8規(guī)定的用于?；畹男畔?；會(huì)話定時(shí)器設(shè)置模塊，用于設(shè)置會(huì)話定時(shí)器；第一發(fā)送模塊，用于在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送用于保活的?；钕?； 所述會(huì)話定期器設(shè)置模塊，還用于在發(fā)送所述?；钕⒅蠡蛘咴诮邮盏巾憫?yīng)于所述 ?；钕⒌谋；铐憫?yīng)消息之后，重啟所述會(huì)話定時(shí)器。
9.根據(jù)權(quán)利要求8所述的裝置，其特征在于，還包括第二發(fā)送模塊，用于在確定所述消息中未攜帶所述用于保活的信息之后，發(fā)送 用于查詢(xún)是否支持RFC4028的查詢(xún)消息；所述第一發(fā)送模塊還用于在根據(jù)所述查詢(xún)消息的響應(yīng)消息確定該響應(yīng)消息的發(fā)送方 不支持RFC4028的情況下，并在所述會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述?；钕?。
10.根據(jù)權(quán)利要求8所述的裝置，其特征在于，還包括第三發(fā)送模塊，用于在接收到的所述消息中添加RFC4(^8規(guī)定的用于保活的 信息，并發(fā)送所述消息；所述第一發(fā)送模塊，還用于在根據(jù)所述消息的響應(yīng)消息中是否攜帶有RFC4(^8規(guī)定的 用于?；畹男畔?lái)確定所述消息的響應(yīng)消息的發(fā)送方不支持RFC4028的情況下；并在所述 會(huì)話定時(shí)器到時(shí)之后，發(fā)送所述?；钕?。
全文摘要
本發(fā)明公開(kāi)了會(huì)話?；罘椒把b置，該方法包括網(wǎng)絡(luò)側(cè)的網(wǎng)元接收到消息，并確定消息中未攜帶RFC4028規(guī)定的用于?；畹男畔ⅲ痪W(wǎng)元設(shè)置會(huì)話定時(shí)器，并在會(huì)話定時(shí)器到時(shí)之后，發(fā)送用于?；畹谋；钕?；在發(fā)送?；钕⒅蠡蛘咴诮邮盏巾憫?yīng)于?；钕⒌谋；铐憫?yīng)消息之后，網(wǎng)元重啟會(huì)話定時(shí)器。通過(guò)本發(fā)明提供了在不支持RFC4028時(shí)會(huì)話保活的支持。
文檔編號(hào)H04L29/06GK102111899SQ20111005564
公開(kāi)日2011年6月29日 申請(qǐng)日期2011年3月8日 優(yōu)先權(quán)日2011年3月8日
發(fā)明者曾麗君, 田利榮, 艾紅芳 申請(qǐng)人:中興通訊股份有限公司