專利名稱：基于sip的媒體服務(wù)中的會(huì)話控制的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及基于SIP的媒體服務(wù)中的，并且特別(但不一定)是 一鍵通(Push-to-Talk)服務(wù)中的會(huì)話控制。更具體地說，本發(fā)明涉及 為此類服務(wù)提供?；?keep-alive)機(jī)制。
背景技術(shù)：
步話機(jī)類型服務(wù)早就證明了其在要在相互之間快速傳遞簡短消息 的用戶之間受歡迎。步話機(jī)類型服務(wù)有時(shí)稱為一鍵通(PTT)服務(wù)。 此類PTT服務(wù)通常一直由雙向便攜式對(duì)講機(jī)才是供，這些對(duì)講機(jī)利用無 線電頻譜的專用部分，但只允許用戶與利用類似終端且在對(duì)講機(jī)的較 短操作范圍的范圍內(nèi)的一小群預(yù)選擇用戶通信。近來，服務(wù)已被引入 美國，其搭載在現(xiàn)有蜂窩電話基礎(chǔ)設(shè)施上。然而，這些服務(wù)在性質(zhì)上 是私有的，不允許用戶在不同的運(yùn)營商網(wǎng)絡(luò)之間通信。
在拓寬PTT服務(wù)的使用的嘗試中，已建立了稱為開放移動(dòng)聯(lián)盟 (www.openmobilealliance.org)的行業(yè)集合，目的是將允許通過蜂窩 網(wǎng)絡(luò)提供的步話機(jī)服務(wù)的網(wǎng)絡(luò)間可操作性的適合協(xié)議標(biāo)準(zhǔn)化。多種標(biāo) 準(zhǔn)建立的服務(wù)稱為蜂窩一鍵通(Push-to-talk Over cellular) (PoC)。 PoC利用IP多力某體子系統(tǒng)(IMS)處理經(jīng)PoC應(yīng)用服務(wù)器(充當(dāng)SIP AS)的PoC會(huì)話的建立和控制。PoC提議相關(guān)聯(lián)語音數(shù)據(jù)將通過分 組交換接入技術(shù)傳輸。在使用GSM和UMTS的情況下，這將是通用 分組無線電服務(wù)(GPRS)接入技術(shù)。在其它網(wǎng)絡(luò)架構(gòu)中，將利用類 似的分組交換接入技術(shù)傳輸談話數(shù)據(jù)。 一鍵通服務(wù)也可通過電路交換 接入網(wǎng)絡(luò)提供，但這不是優(yōu)選。版本1.0中陳述了 PoC的當(dāng)前狀況。 PoC第2版的要求現(xiàn)在正在設(shè)計(jì)。PoC第2版將擴(kuò)展PoC以包括多媒
5體而不只是語音。
PoC AS在信令平面和媒體平面內(nèi)均存在。它實(shí)現(xiàn)4某體資源功能 (MRF),包括a)在實(shí)現(xiàn)所有媒體有關(guān)功能的媒體平面節(jié)點(diǎn)中的媒 體資源功能處理器(MRPP )和b )在充當(dāng)?shù)絊-CSCF的SIP用戶代理 的信令平面節(jié)點(diǎn)中的媒體資源功能控制器(MRFC)。雖然在MRFC 與MRFP之間的接口尚未標(biāo)準(zhǔn)化，但在標(biāo)準(zhǔn)化時(shí)，它可能是基于 H.248。也可能是在PoC的情況下，通過MRFP的實(shí)際(音頻)媒體 將使用實(shí)時(shí)傳輸協(xié)議(RTP)將數(shù)據(jù)打包，或者使用消息會(huì)話中繼協(xié) i義(MSRP)傳送文件。
PoC使用"發(fā)言權(quán)控制"的概念指示在任何給定時(shí)間涉及PoC會(huì)話 的哪個(gè)PoC客戶端可發(fā)送媒體。MRFC充當(dāng)用于PoC ^S舌的媒體發(fā) 言權(quán)控制實(shí)體。如無許可，PoC客戶端不發(fā)送任何類型的媒體，甚至 不發(fā)送指示靜止的+某體分組。發(fā)言權(quán)控制由分配的PoC應(yīng)用服務(wù)器使 用媒體突發(fā)控制協(xié)議(Media Burst Control Protocol) (MBCP)處理。 MBCP消息跨媒體層傳輸。 一旦PoC會(huì)話已建立，PoC客戶端便通過 發(fā)送MBCP媒體突發(fā)請(qǐng)求消息到PoC AS,請(qǐng)求"發(fā)言權(quán)"。假設(shè)其它 PoC客戶端當(dāng)前沒有發(fā)送媒體的許可，則PoC AS接受請(qǐng)求，并將 MBCP媒體突發(fā)授予消息返回到PoC客戶端。
MBCP定義在當(dāng)前無PoC客戶端具有發(fā)送媒體的許可時(shí)發(fā)出到 PoC會(huì)話中所有參與者的"媒體突發(fā)閑置"消息。接收此消息的PoC客 戶端了解到它能在需要時(shí)請(qǐng)求發(fā)送媒體的許可。PoC AS授予PoC客 戶端在某個(gè)預(yù)定義期間的發(fā)言權(quán)，例如，IO秒鐘。在那之后，PoC AS 調(diào)用發(fā)送媒體的許可，并將MBCP媒體突發(fā)閑置消息發(fā)出到參與者。 如果無參與者請(qǐng)求發(fā)送4某體的許可，則PoC AS將在增大的時(shí)間間隔 發(fā)出其它媒體突發(fā)閑置消息，最長為某 一 固定最大間隔。
PoC會(huì)話能由于多個(gè)原因而"桂起"。這可能是例如因?yàn)镻oC客戶 端失去無線電覆蓋。在此類情況下，網(wǎng)絡(luò)實(shí)體，并且具體而言IMS內(nèi) 的SIP代理可能在狀態(tài)信息不再是必需時(shí)保留狀態(tài)信息?？赡芨匾氖?，用戶在其丟失到服務(wù)的接入的時(shí)間點(diǎn)之后可能^皮計(jì)費(fèi)。因此， 最好是提供某種?；顧C(jī)制，允許網(wǎng)絡(luò)實(shí)體了解會(huì)話何時(shí)已掛起。
上述問題不限于PoC，而是也可能適用于其它IMS啟用的服務(wù)， 并且實(shí)際上適用于依賴SIP在端點(diǎn)之間建立和控制會(huì)話的非IMS服 務(wù)。
名稱為"Session Timers in the Session Initiation Protocol (SIP)，，的 IETF RFC 4028提供了 一個(gè)能適用于PoC會(huì)話的此類機(jī)制。該機(jī)制要 求參與SIP客戶端以定期間隔跨SIP信令路徑發(fā)送SIP邀請(qǐng)或更新消 息。為避免信令網(wǎng)絡(luò)過載，建議發(fā)送?；钕⒌拈g隔為大約30分鐘。 然而，由于通常的IMS會(huì)話并且尤其是PoC會(huì)話預(yù)期存活較短，因 此，此機(jī)制應(yīng)用到IMS將使得在不需要狀態(tài)信息后很長時(shí)間在網(wǎng)絡(luò)內(nèi) 保留狀態(tài)信息，并且將對(duì)解決過度計(jì)費(fèi)問題幫助不大。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的第一方面，提供了 一種保持向SIP應(yīng)用服務(wù)器通知 SIP客戶端的狀態(tài)的方法，其中，SIP應(yīng)用服務(wù)器位于用于SIP客戶端 的媒體平面和信令平面內(nèi)，并且負(fù)責(zé)接受SIP客戶端到SIP會(huì)話中和 從SIP會(huì)話刪除它們。方法包括5^某體平面將?；钕腟IP客戶端 發(fā)送到SIP應(yīng)用服務(wù)器。
由于i某體平面消息能比等效的信令平面(即SIP)消息更短，并
且經(jīng)過相對(duì)少的節(jié)點(diǎn)，因此，能發(fā)送?；钕⒌臅r(shí)間間隔更短，而不 會(huì)過度地加負(fù)載于信令網(wǎng)絡(luò)。
將理解，本發(fā)明尤其適用于半雙工會(huì)話。在此類會(huì)話中，SIP客
發(fā)送?；钕ⅰ．?dāng)SIP客戶端正在發(fā)送媒體時(shí)，這表示隱式?；顧C(jī)制。 可能必需在SIP客戶端與SIP應(yīng)用服務(wù)器之間協(xié)商?；钣?jì)時(shí)器值， 所述計(jì)時(shí)器值定義從SIP客戶端發(fā)送保活消息的間隔。SIP應(yīng)用服務(wù) 器運(yùn)行設(shè)置成在所述計(jì)時(shí)器值期滿的計(jì)時(shí)器，其中，如果SIP應(yīng)用服
7務(wù)器在計(jì)時(shí)器的期滿前尚未收到?；钕ⅲ瑒t從SIP客戶端參與的SIP
會(huì)話將其刪除。
在本發(fā)明的典型應(yīng)用中，SIP應(yīng)用服務(wù)器位于IP多々某體子系統(tǒng)網(wǎng) 絡(luò)內(nèi)，并且所述?；钕⑹敲襟w突發(fā)控制協(xié)議消息。更優(yōu)選的是SIP
應(yīng)用服務(wù)器是負(fù)責(zé)發(fā)言權(quán)控制的蜂窩一鍵通應(yīng)用服務(wù)器，并且所述
SIP客戶端是在蜂窩一鍵通會(huì)話中涉及的蜂窩一鍵通客戶端。
優(yōu)選的是在SIP客戶端沒有發(fā)送媒體的許可時(shí)發(fā)送?；钕ⅰIP
客戶端確實(shí)有發(fā)送媒體的許可時(shí)，不發(fā)送?；钕ⅰ?br> 優(yōu)選的是沒有蜂窩一鍵通會(huì)話中涉及的SIP客戶端有發(fā)送媒體的 許可，并且SIP應(yīng)用服務(wù)器接收保活消息時(shí)，應(yīng)用服務(wù)器將確認(rèn)發(fā)送 到SIP客戶端，否則不發(fā)送確認(rèn)。
優(yōu)選的是不同于發(fā)送?；钕⒌目蛻舳说腟IP客戶端具有發(fā)送士某 體的許可時(shí)，SIP應(yīng)用服務(wù)器不明確確認(rèn)消息的接收，并且發(fā)送?；?消息的SIP客戶端將媒體的接收視為隱式確認(rèn)。SIP客戶端具有發(fā)送
4某體的許可時(shí)，不發(fā)送保活消息和顯式確認(rèn)。
在本發(fā)明的實(shí)施例中，所述?；钕⑹莻蜶TP媒體分組。 根據(jù)本發(fā)明的第二方面，提供了一種SIP客戶端，客戶端設(shè)置用
于將?；钕l(fā)送到負(fù)責(zé)接受SIP客戶端到SIP會(huì)話中和從SIP會(huì)話
刪除它們的SIP應(yīng)用服務(wù)器，?；钕⒖?某體平面發(fā)送。
根據(jù)本發(fā)明的第三方面，提供了一種SIP應(yīng)用服務(wù)器，服務(wù)器負(fù)
責(zé)接受SIP客戶端到SIP會(huì)話中和從SIP會(huì)話刪除它們，服務(wù)器設(shè)置
用于通過媒體平面從SIP客戶端接收?；钕?。


圖1以示意圖方式示出包括PoC應(yīng)用服務(wù)器的IMS網(wǎng)絡(luò)；
圖2示出與用于PoC會(huì)話的?；钣?jì)時(shí)器值協(xié)商相關(guān)聯(lián)的信令；以
及
圖3示出與用于三種不同^^舌情況的PoC的?；顧C(jī)制相關(guān)聯(lián)的信令。
具體實(shí)施例方式
圖1以示意圖方式示出包括各種網(wǎng)絡(luò)節(jié)點(diǎn)的IMS網(wǎng)絡(luò)，包括應(yīng)用 服務(wù)器和SIP代理。此架構(gòu)將為本領(lǐng)域的技術(shù)人員所熟知。為論述的 目的足以引起注意的是IMS客戶端1,即用戶終端，連接到可能是諸 如GSM或3G網(wǎng)絡(luò)等蜂窩電話網(wǎng)絡(luò)的接入網(wǎng)絡(luò)2。 IMS客戶端經(jīng)接入 網(wǎng)絡(luò)與IMS核心網(wǎng)絡(luò)3和傳輸網(wǎng)絡(luò)4通信。通過IMS客戶端與IMS 核心網(wǎng)絡(luò)內(nèi)的實(shí)體和對(duì)等IMS客戶端交換SIP信令，建立了 IMS服 務(wù)會(huì)話。IMS核心網(wǎng)絡(luò)鏈接到傳輸網(wǎng)絡(luò)，前者根據(jù)需要使傳輸網(wǎng)絡(luò)內(nèi) 的可用資源供IMS客戶端使用。
再考慮IMS核心網(wǎng)絡(luò)，IMS客戶端分配有服務(wù)呼叫會(huì)話控制功能 (S-CSCF )5。 S-CSCF位于使用IMS客戶端的訂戶的歸屬IMS域內(nèi)， 而不考慮客戶端是從歸屬域內(nèi)還是經(jīng)"受訪"域接入IMS。 CSCF(包括 S-CSCF)處理有關(guān)訂戶的可達(dá)性、認(rèn)證和授權(quán)。服務(wù)的供應(yīng)由SIP應(yīng) 用服務(wù)器(AS)處理。圖1示出為PoC服務(wù)提供服務(wù)邏輯的PoC AS 6。如上所述，PoC AS實(shí)現(xiàn)包括MRFC和MRFP的MRF。用戶媒體 流過MRFP。
在訂戶要與對(duì)等用戶建立PoC會(huì)話時(shí)，訂戶的IMS客戶端經(jīng)代表 訂戶附連到IMS的點(diǎn)的P-CSCF,將SIP邀請(qǐng)發(fā)送到S-CSCF。在檢測 到邀請(qǐng)與PoC會(huì)話有關(guān)時(shí)，S-CSCF為訂戶安裝的初始過濾規(guī)則使邀 請(qǐng)被路由到PoC服務(wù)器。PoC服務(wù)器執(zhí)行所需的動(dòng)作，包括初始化計(jì) 費(fèi)和分配資源，將自己添加到SIP路徑中，并且將邀請(qǐng)返回到S-CSCF。 S-CSCF將邀請(qǐng)向前向?qū)Φ扔脩艮D(zhuǎn)發(fā)。
此處提議？ 1入?；顧C(jī)制，該機(jī)制涉及跨PoC客戶端與PoC AS之 間的媒體平面發(fā)送?；钕?。各種機(jī)制/協(xié)議能用于輸送此類消息。例 如，指定新MBCP消息可能是適當(dāng)?shù)?。備選地，在傳輸協(xié)議是RTP 的情況下，能使用偽RTP媒體分組。偽RTP分組實(shí)質(zhì)上只是無有效負(fù)載的RTP分組。此實(shí)現(xiàn)將要求修改PoC客戶端以便即使它沒有顯 式許可也允許發(fā)送媒體。
此機(jī)制的前提條件是在PoC客戶端與PoC AS之間的?；钕㈤g 隔的協(xié)商(參見圖2)。因此，在PoC客戶端啟動(dòng)、加入或重新加入 PoC會(huì)活時(shí)，PoC客戶端使用fintp參數(shù)包括建議的時(shí)間間隔("fmtp" 是應(yīng)用能用于在SIP邀請(qǐng)或重新邀請(qǐng)的會(huì)話描述協(xié)議(SDP)中添加 參數(shù)的標(biāo)準(zhǔn)化參數(shù))。時(shí)間間隔按每個(gè)^某體發(fā)言權(quán)控制實(shí)體協(xié)商(在 多媒體情況下可存在多個(gè)此類實(shí)體，每個(gè)媒體類型一個(gè)實(shí)體，但一個(gè) 實(shí)體能處理多個(gè)流)。
圖2示出使用SIP在信令平面中的協(xié)商過程(術(shù)語"CSCF，在適當(dāng) 時(shí)表示P-CSCF、 I-CSCF和S-CSCF復(fù)合體)，其中流程的步驟如下 所述
1. PoC客戶端將SIP邀請(qǐng)請(qǐng)求發(fā)送到CSCF。 SIP邀請(qǐng)請(qǐng)求包含 [OMA-PoC-CP]指定的信息和帶有建議的?；钕㈤g隔的附 力口的fmtp。在示例中，此值設(shè)為20秒。
2. CSCF使用在[TS24.229]中指定的機(jī)制將SIP邀請(qǐng)請(qǐng)求轉(zhuǎn)發(fā)到 PoC AS。
3. PoC AS評(píng)估收到的建議的保活消息間隔，并在SIP 200 OK 響應(yīng)中將值返回到S-CSCF。 PoC AS啟動(dòng)計(jì)時(shí)器，監(jiān)^ 見來自 PoC客戶端的?；钕⒌慕邮?。
4. CSCF向PoC客戶端轉(zhuǎn)發(fā)200 OK。 PoC客戶端基于從PoC服 務(wù)器收到的值啟動(dòng)計(jì)時(shí)器。在計(jì)時(shí)器期滿時(shí)，PoC客戶端發(fā) 送?；钕?。時(shí)間間隔可在PoC會(huì)話期間重新協(xié)商，并且對(duì) 于每個(gè)士某體發(fā)言權(quán)控制實(shí)體可以不同。
應(yīng)認(rèn)識(shí)到，PoC客戶端不必為所有會(huì)話情況將保活消息發(fā)送到 PoC AS。通過使用作為?；钕⒒虮；铐憫?yīng)的媒體，能降低信令負(fù)載， 其中，Jf某體在PoC客戶端與PoC AS之間發(fā)送。參照?qǐng)D3，它示出了 三種會(huì)話情況。
10情況1):沒有連接到媒體發(fā)言權(quán)控制實(shí)體的PoC客戶端當(dāng)前具 有發(fā)送媒體的許可。
根據(jù)現(xiàn)有技術(shù)解決方案，在此情況下，PoCAS將以增大的間隔發(fā) 出MBCP^某體突發(fā)閑置消息。與此相反，此處提議僅響應(yīng)于每個(gè)收到 的保活消息而發(fā)送媒體突發(fā)閑置消息。PoC客戶端將媒體突發(fā)閑置消 息作為其?；钕⒌拇_認(rèn)處理，并且將其計(jì)時(shí)器重置為零。如果在收 到?；钕⑶埃琍oC AS中的計(jì)時(shí)器期滿，則PoC AS從PoC會(huì)話中 刪除PoC客戶端。
情況2):連接到媒體發(fā)言權(quán)控制實(shí)體的另一PoC客戶端當(dāng)前具 有發(fā)送媒體的許可。
PoC客戶端根據(jù)同意的時(shí)間間隔發(fā)送保活消息。PoC AS因此注意 到PoC客戶端保持"已連接"，并且將繼續(xù)向它發(fā)送媒體。PoC客戶端 接收々某體，并因此注意到PoC AS已收到其最后的保活消息。il^示 ?；钕⒌碾[式確認(rèn)，并且PoC客戶端將其計(jì)時(shí)器重置為零。同樣地， 如果PoC服務(wù)器中的計(jì)時(shí)器期滿而未收到保活消息，則PoC AS從PoC 會(huì)話中刪除PoC客戶端。
情況3) : PoC客戶端當(dāng)前具有發(fā)送媒體的許可。
這種情況下，PoC客戶端無需發(fā)送?；钕ⅰＫl(fā)送媒體，并且 PoC服務(wù)器將媒體視為隱式?；钕ⅰo需在PoC AS維護(hù)新計(jì)時(shí)器。 如上所述，才艮據(jù)PoC的當(dāng)前狀態(tài)，PoC AS將維護(hù)具有預(yù)定義時(shí)間期 間的計(jì)時(shí)器，在該期間期滿時(shí)，從PoC客戶端刪除發(fā)言權(quán)。除此計(jì)時(shí) 器外，根據(jù)技術(shù)現(xiàn)狀的PoC提議，PoC AS維護(hù)又一計(jì)時(shí)器以檢測在 PoC客戶端部分上的連接丟失。此機(jī)制在每次從具有發(fā)送媒體許可的 PoC客戶端收到媒體時(shí)啟動(dòng)計(jì)時(shí)器(PoC客戶端在具有發(fā)言權(quán)時(shí)將始 終發(fā)送媒體-在用戶不發(fā)言的情況下，發(fā)送靜止RTP分組)。如果 在收到媒體前，計(jì)時(shí)器期滿，則從會(huì)話中刪除PoC客戶端。
本領(lǐng)域的技術(shù)人員將理解，在不脫離本發(fā)明范圍的情況下，可對(duì) 上述實(shí)施例進(jìn)行各種修改。例如，雖然上述示例涉及PoC服務(wù)，但本發(fā)明可應(yīng)用到其它IMS服務(wù)，包括話音和視頻電話。實(shí)際上，本發(fā)明 可適用于非IMS,但仍基于SIP的服務(wù)。特別是，本發(fā)明適用于半雙 工服務(wù)。
權(quán)利要求
1.一種保持向SIP應(yīng)用服務(wù)器通知SIP客戶端的狀態(tài)的方法，其中，所述SIP應(yīng)用服務(wù)器位于用于SIP客戶端的媒體平面和信令平面內(nèi)，并且負(fù)責(zé)接受SIP客戶端到SIP會(huì)話中和從SIP會(huì)話刪除它們，所述方法包括跨所述媒體平面將保活消息從所述SIP客戶端發(fā)送到所述SIP應(yīng)用服務(wù)器。
2. 如權(quán)利要求l所述的方法，其中所述SIP會(huì)話是半雙工會(huì)話。
3. 如權(quán)利要求2所述的方法，其中所述SIP客戶端僅在沒有正在息:'、,、、。、、、、'、、、、、、''
4. 如前面權(quán)利要求任一項(xiàng)所述的方法，并且包括在所述SIP客戶 端與所述SIP應(yīng)用服務(wù)器之間協(xié)商計(jì)時(shí)器值，所述計(jì)時(shí)器值定義從所 述SIP客戶端發(fā)送?；钕⒌拈g隔，并且所述SIP應(yīng)用服務(wù)器運(yùn)行設(shè) 置成在所述計(jì)時(shí)器值期滿的計(jì)時(shí)器，其中，如果所述SIP應(yīng)用服務(wù)器 在所述計(jì)時(shí)器的期滿之前尚未收到?；钕ⅲ瑒t從所述SIP客戶端參 與的SIP會(huì)話將其刪除。
5. 如權(quán)利要求4所述的方法并包括跨所述信令平面使用SIP信令 進(jìn)行所述協(xié)商。
6. 如前面權(quán)利要求任一項(xiàng)所述的方法，其中所述SIP應(yīng)用服務(wù)器 在已接收到?；钕r(shí)，通過所述媒體平面將確認(rèn)發(fā)送到所述SIP客 戶端。
7. 如權(quán)利要求1到5的任一項(xiàng)所述的方法，其中所述SIP應(yīng)用服 務(wù)器在已接收到?；钕⒉⑶覜]有要發(fā)送到所述SIP客戶端的媒體時(shí) 將確認(rèn)發(fā)送到所述SIP客戶端。
8. 如前面權(quán)利要求任一項(xiàng)所述的方法，其中所述SIP應(yīng)用服務(wù)器 位于IP多媒體子系統(tǒng)網(wǎng)絡(luò)內(nèi)。
9. 如權(quán)利要求8所述的方法，其中所述?；钕⑹敲襟w突發(fā)控制協(xié)議消息。
10. 當(dāng)附于權(quán)利要求2時(shí)如權(quán)利要求8或9所述的方法，其中所 述SIP應(yīng)用服務(wù)器是負(fù)責(zé)發(fā)言權(quán)控制的蜂窩一鍵通應(yīng)用服務(wù)器，并且 所述SIP客戶端是在蜂窩一鍵通會(huì)話中涉及的蜂窩一鍵通客戶端。
11. 如權(quán)利要求IO所述的方法，并包括當(dāng)所述SIP客戶端沒有發(fā) 送媒體的許可時(shí)發(fā)送?；钕ⅲ约爱?dāng)所述SIP客戶端確實(shí)有發(fā)送媒 體的許可時(shí)，不發(fā)送所述保活消息。
12. 如權(quán)利要求11所述的方法，并且包括當(dāng)沒有所述蜂窩一鍵通 會(huì)話中涉及的SIP客戶端有發(fā)送々某體的許可，并且所述SIP應(yīng)用服務(wù) 器接收?；钕r(shí)，將確認(rèn)發(fā)送到所述SIP客戶端，否則不發(fā)送確認(rèn)。
13. 如權(quán)利要求12所述的方法，并且包括當(dāng)不同于發(fā)送所述?；?消息的客戶端的SIP客戶端具有發(fā)送媒體的許可時(shí)，所述SIP應(yīng)用服 務(wù)器不明確確認(rèn)所述消息的接收，并且發(fā)送所述保活消息的SIP客戶 端將媒體的接收認(rèn)為是隱式確認(rèn)。
14. 如權(quán)利要求11到13的任一項(xiàng)所述的方法，并且包括當(dāng)所述 SIP客戶端具有發(fā)送媒體的許可時(shí)，不發(fā)送?；钕⒑惋@式確認(rèn)。
15. 如權(quán)利要求1所述的方法，其中所述?；钕⑹莻蜶TP媒體 分組。
16. —種SIP客戶端，設(shè)置用于將保活消息發(fā)送到SIP應(yīng)用服務(wù) 器，所述SIP應(yīng)用服務(wù)器負(fù)責(zé)接受SIP客戶端到SIP會(huì)話中和從SIP 會(huì)話刪除它們，所述?；钕⒖缑襟w平面發(fā)送。
17. 如權(quán)利要求16所述的SIP客戶端并且包括，用于與SIP應(yīng)用 服務(wù)器協(xié)商計(jì)時(shí)器值和用于在所述計(jì)時(shí)器值指示的間隔發(fā)送?；钕?息的部件。
18. 如權(quán)利要求16或17所述的SIP客戶端，并設(shè)置用于僅在所 述客戶端沒有發(fā)送媒體的許可時(shí)發(fā)送?；钕?。
19. 如權(quán)利要求16到18的任一項(xiàng)所述的SIP客戶端，所述SIP 客戶端是蜂窩 一鍵通客戶端。
20. —種SIP應(yīng)用服務(wù)器，負(fù)責(zé)接受SIP客戶端到SIP會(huì)話中和 從SIP會(huì)話刪除它們，所述服務(wù)器設(shè)置用于通過媒體平面從SIP客戶 端接收?；钕?。
21. 如權(quán)利要求20所述的SIP應(yīng)用服務(wù)器，所述服務(wù)器是蜂窩一 4定通應(yīng)用服務(wù)器。
22. 如權(quán)利要求16到19的任一項(xiàng)所述的SIP客戶端，或如權(quán)利 要求20或21所述的SIP應(yīng)用服務(wù)器，所述客戶端/服務(wù)器設(shè)置成使用 々某體突發(fā)控制協(xié)議來發(fā)送/接收?；钕ⅰ?br> 全文摘要
一種保持向SIP應(yīng)用服務(wù)器通知SIP客戶端的狀態(tài)的方法，其中，SIP應(yīng)用服務(wù)器位于用于SIP客戶端的媒體平面和信令平面內(nèi)，并且負(fù)責(zé)接受SIP客戶端到SIP會(huì)話中和從SIP會(huì)話刪除它們，方法包括跨媒體平面將保活消息從SIP客戶端發(fā)送到SIP應(yīng)用服務(wù)器。
文檔編號(hào)H04L29/06GK101652973SQ200780052259
公開日2010年2月17日 申請(qǐng)日期2007年3月21日 優(yōu)先權(quán)日2007年3月21日
發(fā)明者J·斯維德伯格, J·霍爾姆 申請(qǐng)人:艾利森電話股份有限公司