專利名稱：按照會(huì)話啟動(dòng)協(xié)議發(fā)送系統(tǒng)消息的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明通常涉及會(huì)話啟動(dòng)協(xié)議(SIP)技術(shù)，更具體地，涉及用于向例如即時(shí)消息(IM)、無線一鍵通(PoC)、多媒體消息服務(wù)(MMS)的各種基于SIP的服務(wù)訂戶和由服務(wù)供應(yīng)商提供的其它任何基于SIP的服務(wù)發(fā)送系統(tǒng)消息的方法。
系統(tǒng)消息是系統(tǒng)為了不同目的而發(fā)送的特殊類型的消息(例如，付款通知書、服務(wù)通知、警報(bào)、指令等)。系統(tǒng)消息可以包括可能的選項(xiàng)的列表，并要求來自用戶的響應(yīng)。
SIP是用于控制通過網(wǎng)絡(luò)的多媒體會(huì)話的會(huì)話啟動(dòng)協(xié)議，其包括但并不限于MESSAGE方法、消息會(huì)話中繼協(xié)議(MSRP)方法和SIP INFO方法。
背景技術(shù)：
下面將描述MESSAGE方法、MSRP方法和SIP INFO方法MESSAGE方法-SIP擴(kuò)展RFC 3428MESSAGE方法(參見請(qǐng)求注釋(RFC)3428，“Session InitiationProtocol(SIP)Extension for Instant Messaging(用于即時(shí)消息的會(huì)話啟動(dòng)協(xié)議(SIP)擴(kuò)展)”，B.Campbell，Ed.，et.al.，RFC 3428，2002年12月)提出了MESSAGE方法，其為SIP的擴(kuò)展(參見RFC 3261，“SIPSession InitiationProtocol(SIP會(huì)話啟動(dòng)協(xié)議)”，J.Rosenberg，et.al.，RFC 3261，2002年6月)，其允許發(fā)送即時(shí)消息。MESSAGE請(qǐng)求是SIP的擴(kuò)展，因而其繼承了SIP協(xié)議的所有請(qǐng)求路由和安全特征。MESSAGE請(qǐng)求在其中攜帶多用途網(wǎng)際郵件擴(kuò)充協(xié)議(MIME)主體部分的形式的內(nèi)容。MESSAGE請(qǐng)求本身不生成SIP對(duì)話。通常，每個(gè)即時(shí)消息各自獨(dú)立，很像尋呼消息。可以在另一個(gè)SIP請(qǐng)求生成的對(duì)話內(nèi)容中發(fā)送MESSAGE請(qǐng)求。
MSRp方法消息會(huì)話中繼協(xié)議(MSRP)(參見“The Message Session Relay Protocol(消息會(huì)話中繼協(xié)議)”，B.Campbell，Ed.，et，al.，draft-ietf-simple-message-sessions)是用于在會(huì)話中發(fā)送一系列相關(guān)即時(shí)消息的協(xié)議。MSRP是基于文本定向連接的協(xié)議，用于交換任意的或二進(jìn)制MIME內(nèi)容，特別是即時(shí)消息。
SIPINFO方法-RFC 2976SIP INFO方法(參見RFC 2976，“The SIP INFO Method(SIP INFO方法)”，S.Donovan，RFC 2976，2000年10月)允許攜帶在會(huì)話期間生成的會(huì)話相關(guān)控制信息。
然而，使用上述傳統(tǒng)方法的系統(tǒng)消息傳送會(huì)引起一些意外的關(guān)鍵問題，其中基本不能辨別系統(tǒng)消息和正常消息，并且也不能正確識(shí)別從客戶端接收的關(guān)于系統(tǒng)消息的響應(yīng)。此外，上述傳統(tǒng)方法還有其他缺點(diǎn)，當(dāng)服務(wù)器期待來自客戶端的響應(yīng)時(shí)，它們排除了特定的持續(xù)時(shí)間，而且對(duì)于服務(wù)器來說要提供友好的用戶服務(wù)級(jí)別訪問控制是非常困難的。

發(fā)明內(nèi)容
因此，本發(fā)明旨在解決在傳統(tǒng)技術(shù)中發(fā)生的上述難題，本發(fā)明的一個(gè)方面是提供一種傳送系統(tǒng)消息的方法，用于區(qū)分系統(tǒng)消息和正常消息。
根據(jù)本發(fā)明的另一個(gè)方面，提供了一種傳送系統(tǒng)消息的方法，用于識(shí)別客戶端將從服務(wù)器接收的響應(yīng)的類型。
根據(jù)本發(fā)明的另一個(gè)方面，提供了一種傳送系統(tǒng)消息的方法，用于當(dāng)服務(wù)器期待來自客戶端的響應(yīng)時(shí)，等待特定的持續(xù)時(shí)間。
在本發(fā)明的另一個(gè)方面中，提供了一種傳送系統(tǒng)消息的方法，用于提供來自服務(wù)器的友好的用戶服務(wù)級(jí)別訪問控制。
在本發(fā)明的另一個(gè)方面中，提供了一種傳送系統(tǒng)消息的方法，其中服務(wù)器將系統(tǒng)消息發(fā)送到客戶端，服務(wù)器從客戶端接收其響應(yīng)而且基于服務(wù)供應(yīng)商的策略確定任何隨后的動(dòng)作。
仍在本發(fā)明的另一個(gè)方面中，提供了一種可應(yīng)用于MESSAGE方法、MSRP SEND方法和SIP INFO方法的系統(tǒng)消息傳送方法。
為了實(shí)現(xiàn)本發(fā)明上述和其他方面，根據(jù)本發(fā)明的一個(gè)方面，提供了一種按照SIP傳送系統(tǒng)消息的方法，包括通過服務(wù)器，將表示系統(tǒng)消息的特征標(biāo)記引入SIP消息的消息首標(biāo)，并且將表示包含與系統(tǒng)消息相關(guān)的內(nèi)容的多用途網(wǎng)際郵件擴(kuò)充協(xié)議(MIME)內(nèi)容類型引入消息主體，并在消息主體中攜帶包括與系統(tǒng)消息相關(guān)的內(nèi)容的系統(tǒng)消息請(qǐng)求可擴(kuò)展標(biāo)記語言(XML)文檔，從而創(chuàng)建用于發(fā)送到客戶端的對(duì)應(yīng)于當(dāng)前狀況的系統(tǒng)消息請(qǐng)求；并且，通過客戶端，接收系統(tǒng)消息請(qǐng)求，根據(jù)接收的系統(tǒng)消息請(qǐng)求將特征標(biāo)記和MIME內(nèi)容類型添加到SIP消息的消息首標(biāo)，從而創(chuàng)建用于發(fā)送到服務(wù)器的系統(tǒng)消息請(qǐng)求，該系統(tǒng)消息請(qǐng)求在消息主體中攜帶包括與系統(tǒng)消息請(qǐng)求響應(yīng)相關(guān)的內(nèi)容的系統(tǒng)消息響應(yīng)XML文檔。
并且，通過MESSAGE、MSRP SEND、INFO或其他恰當(dāng)?shù)腟IP方法發(fā)送系統(tǒng)消息請(qǐng)求和系統(tǒng)消息響應(yīng)。
優(yōu)選地，在SIP消息首標(biāo)的Accept-Contact(接受-聯(lián)系)字段中攜帶特征標(biāo)記，并且在Content-Type(內(nèi)容-類型)字段中攜帶MIME內(nèi)容類型。
優(yōu)選地，特征標(biāo)記可以是“+g.application.smsg”標(biāo)記，而MIME內(nèi)容類型可以是“vnd.example.system-message+xml”。
有利地，系統(tǒng)消息請(qǐng)求XML文檔可以從<system-message>根元素開始，系統(tǒng)請(qǐng)求消息XTML文檔包括<smsg-type>元素，該元素指示該系統(tǒng)消息是系統(tǒng)消息請(qǐng)求或系統(tǒng)消息響應(yīng)；<smsg>元素，該元素包括唯一標(biāo)識(shí)編號(hào)以關(guān)聯(lián)系統(tǒng)消息響應(yīng)和系統(tǒng)消息請(qǐng)求；<smsg-text>元素，該元素包括要被發(fā)送到客戶端的信息；<smsg-response-type>元素，該元素向用戶指示依照系統(tǒng)消息請(qǐng)求而被客戶端請(qǐng)求的用戶的響應(yīng)類型；<answer-options>元素，通過包含在<smsg-response-type>中的響應(yīng)類型確定該元素內(nèi)容，該元素包括響應(yīng)的具體內(nèi)容和標(biāo)識(shí)符；<verification>元素，該元素包括用于確認(rèn)用戶已閱讀系統(tǒng)消息請(qǐng)求的代碼；<time-out>元素，該元素指示等待時(shí)間的持續(xù)時(shí)間，在該等待時(shí)間內(nèi)，期待用戶對(duì)于系統(tǒng)消息請(qǐng)求的響應(yīng)；以及<restrict-access>元素，該元素允許服務(wù)器協(xié)助客戶端阻止對(duì)相應(yīng)服務(wù)的進(jìn)一步訪問，直到用戶相對(duì)于系統(tǒng)消息請(qǐng)求進(jìn)行響應(yīng)。
優(yōu)選地，<smsg-response-type>元素可以包括no-answer(無應(yīng)答)、only-one-answer(僅有一個(gè)應(yīng)答)和multiple-answer(多個(gè)應(yīng)答)中的至少一個(gè)，如果不期待來自用戶的響應(yīng)，則使用“no-answer”，如果要選擇兩個(gè)不同應(yīng)答(接受或拒絕)中的一個(gè)，則使用“only-one-answer”，如果系統(tǒng)消息需要帶有多個(gè)應(yīng)答的用戶響應(yīng)，則使用“multiple-answer”。
優(yōu)選地，如果<smsg-response-type>元素值是“no-answer”，則<answer-options>元素可以不包括在系統(tǒng)消息請(qǐng)求文檔中，并且如果是只有一個(gè)應(yīng)答或有多個(gè)應(yīng)答，則每個(gè)<answer-options>元素包括<answer-option-id>子元素，該子元素包括對(duì)應(yīng)于用于標(biāo)識(shí)應(yīng)答選項(xiàng)的唯一編號(hào)的標(biāo)識(shí)符；以及<answer-option-text>子元素，該子元素包括表示每個(gè)應(yīng)答選項(xiàng)的具體含義的文本。
優(yōu)選地，<verification>元素可以包括兩個(gè)子元素<verification-text>元素和<verification-uri>元素，<verification-text>元素包括用戶必須在系統(tǒng)消息響應(yīng)中輸入的字母數(shù)字代碼，而<verification-uri>元素包括字母數(shù)據(jù)代碼位置的統(tǒng)一資源標(biāo)識(shí)符(URI)。
優(yōu)選地，在系統(tǒng)消息請(qǐng)求XML文檔中可以選擇性地包括<time-out>元素、<restrict-access>元素和<verification>元素。
此外，系統(tǒng)消息響應(yīng)XML文檔可以包括<smsg-type>元素、<smsg>元素、具有用戶對(duì)系統(tǒng)消息請(qǐng)求的應(yīng)答的<answer>元素以及包括用戶根據(jù)系統(tǒng)消息請(qǐng)求的<verification>元素中包括的字母數(shù)字行而輸入的字母數(shù)字行的<verification>元素。


從下面結(jié)合附圖的本發(fā)明的詳細(xì)描述中，本發(fā)明的上述和其它目標(biāo)、特征和優(yōu)點(diǎn)將會(huì)變得更加明顯，其中圖1是示出了通過客戶端接收來自服務(wù)器的接收系統(tǒng)消息請(qǐng)求的控制過程的流程圖；圖2是示出了客戶端向服務(wù)器發(fā)送系統(tǒng)消息響應(yīng)的控制過程的流程圖；圖3是示出了根據(jù)通用SIP MESSAGE方法發(fā)送系統(tǒng)消息的過程的流程圖；圖4是示出了根據(jù)MSRP SEND方法發(fā)送系統(tǒng)消息的過程的流程圖；并且圖5是示出了根據(jù)SIP INFO方法發(fā)送系統(tǒng)消息的過程的流程圖。
具體實(shí)施例方式
以下將參照附圖描述本發(fā)明的優(yōu)選實(shí)施例。在下面本發(fā)明的描述中，當(dāng)此中包括的已知功能和配置會(huì)混淆本發(fā)明的主題時(shí)，將會(huì)把其省略。
系統(tǒng)消息是系統(tǒng)為不同目的發(fā)送的特定類型的消息(例如，付費(fèi)通知、服務(wù)提醒、警告、指令等)。這些系統(tǒng)消息可以包括可能的選項(xiàng)的列表，而且要求來自用戶的響應(yīng)。發(fā)送這樣的消息的周期取決于服務(wù)供應(yīng)商的策略。終端用戶的響應(yīng)可以用來改變服務(wù)流通。
本發(fā)明提供一種方法，通過將新內(nèi)容引入MIME形式的SIP消息主體、將新特征標(biāo)記引入已有的SIP消息首標(biāo)，而將系統(tǒng)消息進(jìn)行傳送，以領(lǐng)會(huì)各種系統(tǒng)消息需求；然后將其作為系統(tǒng)消息來發(fā)送，用于發(fā)送信息并且接收用戶響應(yīng)。在MIME類型的SIP消息主體中攜帶新內(nèi)容的所述方法可以應(yīng)用于例如MESSAGE方法、MSRP SEND方法、SIP INFO方法等。
客戶端和服務(wù)器必須支持系統(tǒng)消息特征。此外，客戶端和服務(wù)器必須特定地標(biāo)識(shí)系統(tǒng)消息，區(qū)分系統(tǒng)消息和其他正常消息。因此，根據(jù)本發(fā)明，將新特征標(biāo)記引入SIP消息的消息首標(biāo)中有助于服務(wù)器確定客戶端是否支持系統(tǒng)消息，還有助于發(fā)送和接收系統(tǒng)唯一地標(biāo)識(shí)系統(tǒng)消息。該新特征標(biāo)記可以被稱為“+g.applications.smsg”，而且該新特征標(biāo)記可以應(yīng)用于任何服務(wù)，例如IM服務(wù)、PoC服務(wù)、MMS服務(wù)。特征標(biāo)記“+g.applications.smsg”的ASN.1標(biāo)識(shí)符是IANA的新分配，而且該特征標(biāo)記表示客戶端支持系統(tǒng)消息。適用于該特征標(biāo)記的值是布爾值。特征標(biāo)記起初意欲用于今后的應(yīng)用、協(xié)議、服務(wù)或流通機(jī)制中，并且在通信應(yīng)用中最為有用，用于描述例如電話或PDA等設(shè)備的性能。
上述典型用途的一個(gè)例子是將系統(tǒng)消息路由到能夠支持系統(tǒng)消息的移動(dòng)電話。新特征標(biāo)記在SIP REGISTER步驟過程中必須被客戶端注冊(cè)。SIP首標(biāo)字段用于指示對(duì)系統(tǒng)消息的支持，例如，以便能夠使用接受-聯(lián)系首標(biāo)來根據(jù)RFC 3841“Caller Preferences for the Session Initiation Protocol(用于會(huì)話啟動(dòng)協(xié)議的呼叫參考)”的規(guī)則和程序連同“require(需求)”和“explicit(顯式)”參數(shù)一起攜帶新特征標(biāo)記。新特征標(biāo)記可以被使用在用于系統(tǒng)消息的各種SIP方法中。與是否在一個(gè)會(huì)話中發(fā)送系統(tǒng)消息無關(guān)，在本發(fā)明中可以使用SIPMESSAGE方法來發(fā)送和接收系統(tǒng)消息。同樣，可以將SIP IFO方法和MSRPSEND方法應(yīng)用于本發(fā)明，用于會(huì)話期間中發(fā)送系統(tǒng)消息。
根據(jù)本發(fā)明，必須為系統(tǒng)消息定義新的MIME類型。例如，利用“vnd.example.system-message+xml”MIME內(nèi)容類型唯一地標(biāo)識(shí)新的MIME類型。該MIME內(nèi)容類型用于標(biāo)識(shí)該SIP MESSAGE主體包括符合特定方案(XML方案)的系統(tǒng)消息。新的MIME內(nèi)容類型被應(yīng)用于例如IM服務(wù)、PoC服務(wù)、MMS服務(wù)的任何服務(wù)。此外，在用于系統(tǒng)消息的各種SIP方法中，必須指示新的MIME內(nèi)容類型。與是否在會(huì)話中發(fā)送系統(tǒng)消息無關(guān)，SIPMESSAGE方法可以被用于發(fā)送和接收系統(tǒng)消息，并且，SIP INFO和MSRPSEND方法也可以用于在會(huì)話期間發(fā)送系統(tǒng)消息。在SIP MESSAGE的首標(biāo)字段中(例如在內(nèi)容類型首標(biāo)中)可以攜帶新的MIME類型。
同時(shí)，在發(fā)送和接收系統(tǒng)消息期間，在各種SIP方法的消息主體中攜帶根據(jù)新的MIME內(nèi)容類型的系統(tǒng)消息。因此，必須基于由新的MIME內(nèi)容類型定義的新的方案來描述消息主體。只有在必要時(shí)(例如首次使用等)，才將系統(tǒng)消息發(fā)送到客戶端。所以，服務(wù)器保持這樣一種狀態(tài)，即從中服務(wù)供應(yīng)商可以知道已經(jīng)向誰發(fā)送了系統(tǒng)消息并且仍然要向誰發(fā)送系統(tǒng)消息。因此，可以用如下方式來限定由新的MIME內(nèi)容類型定義的消息主體能夠被服務(wù)器用來發(fā)送的系統(tǒng)消息應(yīng)當(dāng)具有與客戶端用于響應(yīng)回服務(wù)器的消息相同的方案。例如，可以具有能夠?qū)崿F(xiàn)系統(tǒng)消息請(qǐng)求和系統(tǒng)消息響應(yīng)的單個(gè)方案。
以下將描述系統(tǒng)消息請(qǐng)求文檔的結(jié)構(gòu)。系統(tǒng)消息請(qǐng)求是結(jié)構(gòu)良好的而且必須有效的XML文檔。該系統(tǒng)請(qǐng)求消息文檔基于XML 1.0，并且使用聯(lián)碼轉(zhuǎn)換格式8(UTF-8)編碼。本發(fā)明利用XML命名空間來唯一地標(biāo)識(shí)系統(tǒng)消息請(qǐng)求文檔或該文檔的片段。由本發(fā)明的詳細(xì)描述所定義的用于元素的命名空間統(tǒng)一資源標(biāo)識(shí)符(URI)是使用命名空間標(biāo)識(shí)符“example”統(tǒng)一資源名(URN)，。下面闡明該URN“urn:example:params:xml:ns:application:system-message”上述系統(tǒng)消息請(qǐng)求文檔可以從<system-message>根元素開始，它還可以包括<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<answer-option-id>元素、<answer-option-text>元素、<verification>元素、<verification-text>元素、<verification-uri>元素、<time-out>元素和<restrict-access>元素。在下面的表格1中提供了每個(gè)元素的定義。
表格1


參照上面的表格1，將詳細(xì)描述關(guān)于上述的各個(gè)元素。
<smsg-type>元素表示系統(tǒng)消息是“request”類型，其意味著它是從服務(wù)器到客戶端。<smsg>元素是包括用來將將響應(yīng)和系統(tǒng)消息請(qǐng)求進(jìn)行關(guān)聯(lián)的唯一標(biāo)識(shí)編號(hào)的元素。該元素使系統(tǒng)同時(shí)發(fā)送多于一個(gè)的系統(tǒng)消息，從而減少消息傳送和信令的開銷。同樣，它有助于在服務(wù)器端將稍后可以從客戶端接收的響應(yīng)和系統(tǒng)消息進(jìn)行關(guān)聯(lián)。
<smsg-text>是提供要呈現(xiàn)給用戶的某些消息的元素。<smsg-response-type>元素是向用戶通知來自應(yīng)答該系統(tǒng)消息請(qǐng)求的用戶所期望的響應(yīng)類型的指示符，該響應(yīng)包括“no-answer”、“only-one-answer”或“multiple-answer”，其中，在服務(wù)器發(fā)送的系統(tǒng)消息僅僅與用戶信息有關(guān)、而且不期待來自用戶的響應(yīng)的情況下，使用“no-answer”，在服務(wù)器發(fā)送的系統(tǒng)消息需要知道僅僅帶有接受/拒絕或者是/否類型的響應(yīng)的用戶的響應(yīng)的情況下，使用“only-one-answer”，在服務(wù)器發(fā)送的系統(tǒng)消息需要知道帶有多個(gè)應(yīng)答的用戶的響應(yīng)時(shí)，使用“multiple-answer”。服務(wù)器基于用戶所需的響應(yīng)類型而確定<smsg-response-type>元素中的值。客戶端必須依照服務(wù)器請(qǐng)求的響應(yīng)類型進(jìn)行回應(yīng)。
<answer-options>元素是描述可由用戶選擇且可組成多個(gè)元素的可能的應(yīng)答選項(xiàng)的元素。當(dāng)存在該元素時(shí)，意味著服務(wù)器期待來自用戶的響應(yīng)。因此，在<smsg-response-type>元素值是“no-answer”的情況下，不存在<answer-options>元素。<answer-options>將允許客戶端顯示用戶可以從中選擇的應(yīng)答選項(xiàng)。在僅有一個(gè)應(yīng)答或多個(gè)應(yīng)答的情況下，每個(gè)應(yīng)答選項(xiàng)對(duì)包括唯一的ID和表示該選項(xiàng)含義的文本消息。該唯一的ID有助于服務(wù)器標(biāo)識(shí)用戶響應(yīng)于系統(tǒng)消息所作出的選擇。每個(gè)<answer-options>元素包括對(duì)應(yīng)于標(biāo)識(shí)應(yīng)答選項(xiàng)的唯一編號(hào)的<answer-option-id>元素，以及提供解釋相應(yīng)應(yīng)答選項(xiàng)的空白文本的<answer-option-text>元素。如果不存在子元素，那么這意味著客戶端將向用戶提供用于填寫該應(yīng)答的選項(xiàng)。
<verification>元素是確認(rèn)用戶已閱讀系統(tǒng)消息的元素。如果存在該字段，那么這表示服務(wù)器需要用于聲明用戶已閱讀過該消息的回執(zhí)(acknowledgement)。是否包括該<verification>元素是可選的，并由服務(wù)器來決定。<verification>元素包括以下兩個(gè)子元素中的一個(gè)子元素，即<verification-text>和<verification-uri>元素，其中<verification-text>元素描述用戶必須在系統(tǒng)消息響應(yīng)中重新輸入的字母數(shù)字代碼，，而<verification-uri>元素描述表示用戶必須在系統(tǒng)消息響應(yīng)中插入該代碼的代碼位置的URI值。
<time-out>元素是通知用戶持續(xù)時(shí)間的元素，在該持續(xù)時(shí)間內(nèi)期望用戶的響應(yīng)。該元素包括服務(wù)器期望用戶在某一時(shí)間/持續(xù)時(shí)間內(nèi)響應(yīng)系統(tǒng)消息的情況。如果用戶沒有在預(yù)定的時(shí)間/周期內(nèi)作出響應(yīng)，則服務(wù)器可以基于本地策略確定動(dòng)作的未來方向。是否包括該<time-out>元素是可選的，這由服務(wù)器來決定。
<restrict-access>元素是允許服務(wù)器協(xié)助客戶端阻止對(duì)服務(wù)的進(jìn)一步訪問直到用戶響應(yīng)系統(tǒng)消息的元素。是否包括該元素也是可選的，并且由服務(wù)器決定。如果服務(wù)器通過<restrict-access>元素請(qǐng)求阻止對(duì)該服務(wù)的訪問，則客戶端不應(yīng)該允許用戶進(jìn)一步訪問該服務(wù)。從而，在服務(wù)器希望限制該服務(wù)訪問直到客戶端進(jìn)行響應(yīng)的情況下，服務(wù)器保持訪問狀態(tài)并且等待響應(yīng)，直到時(shí)間用盡為止，在時(shí)間用盡的情況下，該服務(wù)器基于服務(wù)供應(yīng)商策略而決定下一步的動(dòng)作。在時(shí)間用盡的狀態(tài)下服務(wù)器可以重發(fā)系統(tǒng)消息，但是根據(jù)服務(wù)供應(yīng)商的策略而決定系統(tǒng)消息的重發(fā)。應(yīng)當(dāng)用MIME內(nèi)容類型“vnd.example.system-message+xml”來標(biāo)識(shí)系統(tǒng)消息請(qǐng)求文檔。
下面將在表格2中描述表格2中所示系統(tǒng)消息的請(qǐng)求文檔的XML方案。
表格2



根據(jù)本發(fā)明的包括上述元素的系統(tǒng)消息請(qǐng)求文檔的例子如下面的表格3所示。
表格3



接下來，將描述系統(tǒng)消息響應(yīng)文檔的結(jié)構(gòu)。系統(tǒng)消息響應(yīng)文檔必須是結(jié)構(gòu)良好并且有效的XML文檔。系統(tǒng)消息響應(yīng)文檔基于XML1.0并使用UTF-8編碼。本發(fā)明利用XML命名空間唯一地標(biāo)識(shí)系統(tǒng)消息響應(yīng)文檔或文檔的片段。本發(fā)明定義的元素的命名空間URI是URN，其使用命名空間標(biāo)識(shí)符“example”。該URN的描述如下urn:example:params:xml:ns:application:system-message系統(tǒng)消息響應(yīng)文檔以<system-message>根元素開始，它還包括<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素。各個(gè)元素的定義如下面的表格4所示。
表格4

參考上面的表格，進(jìn)一步詳細(xì)描述其中各個(gè)元素。
<smsg-type>元素表示系統(tǒng)消息是“response(響應(yīng))”類型，這意味著它是從客戶端到服務(wù)器的。<smsg>元素是具有包括在系統(tǒng)消息請(qǐng)求的<smsg>元素的“id”屬性中的值的元素。該元素有助于尋找在服務(wù)器的請(qǐng)求和響應(yīng)之間的匹配。在單個(gè)消息中發(fā)送多于一個(gè)的系統(tǒng)消息的情況下，該<smsg>元素還有助于使所述響應(yīng)相關(guān)聯(lián)，以減少消息傳送和信令的開銷。
<answer>元素是表示根據(jù)應(yīng)答選項(xiàng)列表的用戶選擇的元素，并且可以包括許多元素。該元素是在系統(tǒng)消息請(qǐng)求中定義的一組應(yīng)答選項(xiàng)中的選擇。每個(gè)<answer>元素包括子元素<answer-id>。如果在系統(tǒng)消息請(qǐng)求中的<smsg-response-type>元素中的值是“multiple-answer”，則還可以有多個(gè)<answer-id>元素。這允許用戶使用相同的消息對(duì)一個(gè)請(qǐng)求發(fā)送多個(gè)應(yīng)答。僅使用ID服務(wù)器以減少該消息的尺寸。同樣，每個(gè)<answer>元素可以包括子元素<answer-text>和<answer-id>，其中存在用戶輸入的空白文本應(yīng)答。應(yīng)答響應(yīng)有利于服務(wù)供應(yīng)商決定同意給予用戶的服務(wù)級(jí)別，以及諸如密碼復(fù)位、新的登記、收費(fèi)、特征等的各種要素。
<verification>元素是確認(rèn)用戶已閱讀系統(tǒng)消息的元素。例如，用戶輸入在系統(tǒng)消息請(qǐng)求中出現(xiàn)的代碼，從而允許服務(wù)器確認(rèn)用戶已經(jīng)閱讀過該系統(tǒng)消息。否則，該元素可以是在如特定URI(如系統(tǒng)消息請(qǐng)求中提到的)所描述的位置出現(xiàn)的代碼。如果用戶提供的響應(yīng)的驗(yàn)證失敗，則服務(wù)器策略將決定下一步的動(dòng)作。例如，可能是服務(wù)器不允許對(duì)服務(wù)的進(jìn)一步訪問，且服務(wù)器可以重發(fā)該系統(tǒng)消息。應(yīng)當(dāng)由MIME內(nèi)容類型“vnd.example.system-message+xml”標(biāo)識(shí)系統(tǒng)消息響應(yīng)文檔。
系統(tǒng)消息響應(yīng)文檔的XML方案如下面的表格5所述。
表格5



根據(jù)本發(fā)明的系統(tǒng)消息響應(yīng)文檔的例子如下面的表格6所示。
表格6


現(xiàn)在參照?qǐng)D1和圖2描述系統(tǒng)消息的傳送和接收過程，其中，圖1示出了由客戶端接收來自服務(wù)器的系統(tǒng)消息請(qǐng)求的控制過程，圖2示出了客戶端向服務(wù)器發(fā)送系統(tǒng)消息響應(yīng)的控制過程。
首先參照?qǐng)D1描述系統(tǒng)消息請(qǐng)求的傳送過程。如果服務(wù)器X(130)根據(jù)現(xiàn)有的通信環(huán)境確定需要發(fā)送系統(tǒng)消息到客戶端X，那么它向SIP/IP核心(120)發(fā)送SIP請(qǐng)求消息，即系統(tǒng)消息請(qǐng)求。這里，SIP請(qǐng)求消息的Request-URI包括客戶端X(110)的地址，且SIP消息首標(biāo)的Accept-Contact標(biāo)題包括特征標(biāo)記“+g.application.smsg”。此外，消息首標(biāo)的Content-Type字段包括MIME內(nèi)容類型的“application/vnd.example.system-message+xml”，用于表示消息主體具有與系統(tǒng)消息相關(guān)的內(nèi)容，并且將SIP消息的消息主體配置成具有與系統(tǒng)消息請(qǐng)求相關(guān)的內(nèi)容的XML文檔。
所述SIP請(qǐng)求消息的例子如下面的表格7所示。
表格7


在步驟203中，SIPIP/Core X(120)基于存儲(chǔ)在登記步驟中的信息，將從服務(wù)器(130)接收的SIP請(qǐng)求消息發(fā)送到客戶端X(110)。在步驟205中，客戶端X(110)允許將接收的SIP請(qǐng)求消息(即系統(tǒng)消息請(qǐng)求)向用戶X顯示。然后，在步驟207中，客戶端X(110)將SIP 200“OK”響應(yīng)發(fā)送到SIP/IP核心X(120)，以便確認(rèn)已經(jīng)接收了系統(tǒng)消息請(qǐng)求。將SIP 200“OK”響應(yīng)沿著信令路徑發(fā)送到服務(wù)器X，其配置如下面的表格8所示。
表格8

在步驟209中，接收SIP 200“OK”響應(yīng)的SIP/IP核心X(120)將響應(yīng)發(fā)送到服務(wù)器X。服務(wù)器X(130)接收SIP 200“OK”響應(yīng)，從而確認(rèn)客戶端X(110)已接收系統(tǒng)消息請(qǐng)求。參照?qǐng)D2，其描述了根據(jù)本發(fā)明，在客戶端X(110)接收SIP請(qǐng)求消息(即系統(tǒng)消息請(qǐng)求)之后，使用SIP響應(yīng)消息的新信息傳送系統(tǒng)消息響應(yīng)的過程，。如圖2所示，客戶端X(110)向SIP/IP核心X(120)發(fā)送SIP響應(yīng)消息，以對(duì)在圖1的步驟中接收的SIP請(qǐng)求消息進(jìn)行應(yīng)答。這里，SIP響應(yīng)消息的Request-URI可以包括服務(wù)器X(130)的地址，SIP消息首標(biāo)的Accept-Contact首標(biāo)可以包括特征標(biāo)記“+g.application.smsg”。此外，消息首標(biāo)的Content-type字段可以包括MIME內(nèi)容類型的“application/vnd.example.system-message+xml”，用于表示所述消息主體具有與系統(tǒng)消息相關(guān)的內(nèi)容，而且SIP消息的消息主體可以被配置成具有與系統(tǒng)消息響應(yīng)相關(guān)的內(nèi)容的XML文檔。該SIP響應(yīng)消息的例子如下面表格9所示。
表格9

在步驟303中，SIP/IP核心X(120)根據(jù)Accept-Contact首標(biāo)中的特征標(biāo)記“+g.application.smsg”將所接收的SIP響應(yīng)消息發(fā)送到服務(wù)器X(130)。在步驟305中，服務(wù)器X(130)接收SIP響應(yīng)消息，從而接收客戶端X(110)對(duì)系統(tǒng)消息請(qǐng)求的響應(yīng)。然后，在步驟307中，服務(wù)器X(130)將如下面表格10中所示的SIP 200“OK”響應(yīng)發(fā)送到SIP/IP核心X(120)。
表格10

接下來，在步驟308中，SIP/IP核心X(120)將SIP 200“OK”響應(yīng)傳送到客戶端X(110)。
本發(fā)明提供了一種用于傳送系統(tǒng)消息以領(lǐng)會(huì)(comprehend)各種系統(tǒng)消息需求的方法，該方法將MIME內(nèi)容類型和表示上述系統(tǒng)消息的新特征標(biāo)記引入SIP消息的消息首標(biāo)中，并且還在SIP消息的MIME類型主體中攜帶具有與系統(tǒng)消息相關(guān)的內(nèi)容的XML文檔。這里，可以通過MESSAGE方法、MSRP SEND方法、SIP INFO方法等實(shí)現(xiàn)SIP消息。
參照?qǐng)D3到圖5，描述了根據(jù)上述各個(gè)方法的系統(tǒng)消息傳送方法。在所述附圖中，圖3示出了根據(jù)通常的SIP MESSAGE方法發(fā)送系統(tǒng)消息的過程，圖4示出了根據(jù)MSRP SEND方法發(fā)送系統(tǒng)消息的過程，圖5示出了根據(jù)SIPINFO方法發(fā)送系統(tǒng)消息的過程。
如圖3所示，在SIP MESSAGE方法中，服務(wù)器20在步驟11中根據(jù)表格2的XML方案構(gòu)成用于提供信息或警告的系統(tǒng)消息請(qǐng)求，從而請(qǐng)求接受/拒絕和多個(gè)應(yīng)答。換句話說，服務(wù)器20使用<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<verification>元素、<verification-text>元素和<restrict-access>元素構(gòu)成包含在系統(tǒng)消息請(qǐng)求中的內(nèi)容，然后在步驟13中使用MESSAGE方法將相同的內(nèi)容發(fā)送到客戶端10。在步驟15中，客戶端10使接收的系統(tǒng)消息請(qǐng)求與正常消息區(qū)分顯示，而且如果被系統(tǒng)消息請(qǐng)求所請(qǐng)求，則它就控制用戶對(duì)特定服務(wù)的訪問，然后在步驟17中將SIP 200“OK”響應(yīng)發(fā)送到服務(wù)器20。其后，在步驟19中，如果有必要的話，客戶端10就在系統(tǒng)消息請(qǐng)求預(yù)定的時(shí)間內(nèi)根據(jù)表格5的XML方案構(gòu)成對(duì)系統(tǒng)消息請(qǐng)求的響應(yīng)消息。例如，客戶端10使用<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素構(gòu)成包含在系統(tǒng)消息響應(yīng)中的內(nèi)容，然后在步驟21中使用SIP MESSAGE方法將相同內(nèi)容發(fā)送到服務(wù)器20。一旦服務(wù)器20識(shí)別出所發(fā)送的響應(yīng)消息，其就確認(rèn)用戶已閱讀了該消息，并且向客戶端10發(fā)送200“OK”響應(yīng)。
如圖4所示，在MSRP SEND方法中，服務(wù)器20在步驟31中根據(jù)表格2的XML方案構(gòu)成用于提供信息或警告的系統(tǒng)消息請(qǐng)求，從而請(qǐng)求接受/拒絕和多個(gè)應(yīng)答。例如，服務(wù)器20使用<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<vertification>元素、<time-out>元素和<restrict-access>元素構(gòu)成包含在系統(tǒng)消息請(qǐng)求中的內(nèi)容，然后在步驟33中通過使用MSRP SEND方法將相同內(nèi)容發(fā)送到客戶端10。在步驟35中，客戶端10使所接收的系統(tǒng)消息請(qǐng)求與正常消息區(qū)分顯示，而且如果被系統(tǒng)消息請(qǐng)求所請(qǐng)求，則它就控制用戶對(duì)特定服務(wù)的訪問，隨后在步驟37中將SIP 200“OK”響應(yīng)發(fā)送到服務(wù)器20。其后，在步驟39中，客戶端10在系統(tǒng)消息請(qǐng)求中預(yù)定的時(shí)間內(nèi)根據(jù)表格5的XML方案構(gòu)成對(duì)系統(tǒng)消息請(qǐng)求的響應(yīng)消息。例如，客戶端10使用<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素構(gòu)成包含在系統(tǒng)消息響應(yīng)中的內(nèi)容，然后在步驟41中使用MSRP SEND方法將相同內(nèi)容發(fā)送到服務(wù)器20。一旦服務(wù)器20識(shí)別出所發(fā)送的響應(yīng)消息，則其確認(rèn)用戶已經(jīng)閱讀過該消息，并且向客戶端10發(fā)送200“OK”響應(yīng)。
如圖5所示，在SIP INFO方法中，服務(wù)器20在步驟51中根據(jù)表格2的XML方案構(gòu)成用于提供信息或警告的系統(tǒng)消息請(qǐng)求，從而請(qǐng)求的接受/拒絕和多個(gè)應(yīng)答。換句話說，服務(wù)器20使用<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<verification>元素、<time-out>元素和<restrict-access>元素構(gòu)成包含在系統(tǒng)消息請(qǐng)求中的內(nèi)容，然后在步驟53中使用SIP INFO方法將相同內(nèi)容發(fā)送到客戶端10。在步驟55中，客戶端10顯示所接收的系統(tǒng)消息請(qǐng)求，而且如果被系統(tǒng)消息請(qǐng)求所請(qǐng)求，它就控制用戶對(duì)特定服務(wù)的訪問，然后客戶端10在步驟57中將200“OK”響應(yīng)發(fā)送到服務(wù)器20。其后，在步驟59中，客戶端10在系統(tǒng)消息請(qǐng)求中所預(yù)定的時(shí)間內(nèi)根據(jù)表格5的XML方案構(gòu)成對(duì)系統(tǒng)消息請(qǐng)求的響應(yīng)消息。例如，客戶端10使用<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素構(gòu)成包含在系統(tǒng)消息響應(yīng)中的各種內(nèi)容，然后在步驟61中通過使用SIP INFO方法將相同內(nèi)容發(fā)送到服務(wù)器20。服務(wù)器20檢測所發(fā)送的響應(yīng)消息，確認(rèn)用戶已閱讀了該系統(tǒng)消息，隨后向客戶端10發(fā)送200“OK”響應(yīng)。
從上面的描述可以看到的，本發(fā)明提供了一種使用SIP消息傳送系統(tǒng)消息的方法，其將系統(tǒng)消息類型的MIME內(nèi)容和表示該系統(tǒng)消息的特征標(biāo)記引入SIP消息的消息首標(biāo)，從而在SIP消息的消息主體中攜帶描述與系統(tǒng)消息相關(guān)的內(nèi)容的XTML文檔。因此，根據(jù)本發(fā)明的使用SIP來傳送系統(tǒng)消息的方法可以區(qū)分系統(tǒng)消息和正常消息，而且可以使服務(wù)器標(biāo)識(shí)對(duì)于從客戶端接收的系統(tǒng)消息的響應(yīng)。此外，該方法允許當(dāng)服務(wù)器等待來自客戶端的響應(yīng)時(shí)，等待特定的持續(xù)時(shí)間，并且本本方法提供了來自服務(wù)器的友好的用戶服務(wù)級(jí)別訪問控制。而且，服務(wù)器可以向客戶端發(fā)送系統(tǒng)消息，且服務(wù)器可以從客戶端接收對(duì)其的響應(yīng)。服務(wù)器可以基于服務(wù)供應(yīng)商的策略來確定任何接下來的動(dòng)作。此外，傳送系統(tǒng)消息的該方法可適用于SIP MESSAGE方法、MSRPSEND方法和SIP INFO方法。
對(duì)于本領(lǐng)域技術(shù)人員來說顯而易見的是，通過描述和附圖的教導(dǎo)，可以從本發(fā)明的各種方法和裝置的組合中得到其他控制方法和裝置，并且這些也被認(rèn)為在本發(fā)明的范圍之內(nèi)。而且，因此在前面省略了對(duì)上述組合和變化的描述。還應(yīng)該注意的是，用于存儲(chǔ)上述應(yīng)用的主機(jī)包括但不限于計(jì)算機(jī)、移動(dòng)通信設(shè)備、移動(dòng)服務(wù)器或多功能設(shè)備。雖然已結(jié)合其優(yōu)選實(shí)施例并參照附圖全面描述了本發(fā)明，但要注意的是，可以做出各種變化和修改，而且這種變化和修改對(duì)于本領(lǐng)域的技術(shù)人員來說是顯而易見的。除非上述變化和修改背離了本發(fā)明的范圍，否則上述變化和修改可以被理解為包括在由所附的權(quán)利要求書所定義的本發(fā)明的范圍之內(nèi)。
[RFC2976]“The SIP INFO Method”，S.Donovan，RFC 2976，October 2000，URI:http://www.ietf.org/rfc/rfc2976.txt[RFC3261]“SIPSession Initiation Protocol”，J.Rosenberg，et.al.，RFC3261，June 2002，URL:http://www.ietf.org/rfc/rfc3261.txt[RFC3428]“Session Initiation Protocol(SIP) Extension for InstantMessaging”，B.Campbell，Ed.，et .al.，RFC 3428，December 2002，URL:http://www.ietf.org/rfc/rfc3428.txt[MSRP]“The Message Session Relay Protocol”，B.Campbell，Ed.，et.al.，draft-ietf-simple-message-sessions，URL:http://www.ietf.org/intemet-drafts/draft-ietf-simple-message-sessions-15.txt
權(quán)利要求
1.一種使用會(huì)話啟動(dòng)協(xié)議SIP傳送系統(tǒng)消息的方法，包括以下步驟通過服務(wù)器，將表示系統(tǒng)消息的特征標(biāo)記引入SIP消息的消息首標(biāo)，而且將表示包含與系統(tǒng)消息相關(guān)的內(nèi)容的多用途網(wǎng)際郵件擴(kuò)充協(xié)議MIME內(nèi)容類型引入消息主體，并攜帶描述消息主體中與系統(tǒng)消息相關(guān)的內(nèi)容的系統(tǒng)消息請(qǐng)求XML文檔，從而構(gòu)成用于發(fā)送到客戶端的與當(dāng)前狀況對(duì)應(yīng)的系統(tǒng)消息請(qǐng)求；而且通過客戶端，接收系統(tǒng)消息請(qǐng)求，根據(jù)所接收的系統(tǒng)消息請(qǐng)求將所述特征標(biāo)記和所述MIME內(nèi)容類型引入到SIP消息的消息首標(biāo)中，從而構(gòu)成用于發(fā)送給服務(wù)器的攜帶系統(tǒng)消息響應(yīng)XML文檔的系統(tǒng)消息響應(yīng)，該系統(tǒng)消息響應(yīng)XML文檔描述了對(duì)消息主體中的系統(tǒng)消息請(qǐng)求進(jìn)行響應(yīng)的相關(guān)內(nèi)容。
2.如權(quán)利要求1所述的方法，在所述構(gòu)成并發(fā)送系統(tǒng)消息請(qǐng)求的步驟中，客戶端構(gòu)成與提供信息、提供警告、請(qǐng)求對(duì)任意服務(wù)的接受/拒絕或請(qǐng)求多個(gè)應(yīng)答中的至少一個(gè)對(duì)應(yīng)的系統(tǒng)消息請(qǐng)求。
3.如權(quán)利要求2所述的方法，所述構(gòu)成并發(fā)送系統(tǒng)消息響應(yīng)還包括步驟如果接收的系統(tǒng)消息請(qǐng)求包括特征標(biāo)記，則將所述系統(tǒng)消息與一般的SIP消息區(qū)別顯示。
4.如權(quán)利要求3所述的方法，在所述構(gòu)成并發(fā)送系統(tǒng)消息響應(yīng)的步驟中，如果所接收的系統(tǒng)消息請(qǐng)求包括用于請(qǐng)求響應(yīng)的內(nèi)容，則客戶端構(gòu)成系統(tǒng)消息響應(yīng)。
5.如權(quán)利要求4所述的方法，根據(jù)SIP MESSAGE方法、MSRP SEND方法或SIP INFO方法中的一個(gè)來發(fā)送系統(tǒng)消息響應(yīng)。
6.如權(quán)利要求5所述的方法，其中，在所述消息首標(biāo)的Accept-Contact字段中攜帶所述特征標(biāo)記，在Content-type字段中攜帶MIME內(nèi)容類型。
7.如權(quán)利要求6所述的方法，其中，所述特征標(biāo)記是“+g.application.smsg”標(biāo)記，而且所述MIME內(nèi)容類型是“vnd.example.system-message+xml”。
8.如權(quán)利要求6所述的方法，其中，所述系統(tǒng)消息請(qǐng)求XML文檔以<system-message>根元素開始。
9.如權(quán)利要求8所述的方法，其中，所述系統(tǒng)消息請(qǐng)求XML文檔包括<smsg-type>元素，該元素表示該系統(tǒng)消息是系統(tǒng)消息請(qǐng)求；<smsg>元素，該元素包括用于關(guān)聯(lián)對(duì)系統(tǒng)消息請(qǐng)求的響應(yīng)的唯一編號(hào)；<smsg-text>元素，該元素包括要發(fā)送到客戶端的信息；<smsg-response-type>元素，該元素表示依照系統(tǒng)消息請(qǐng)求向客戶端請(qǐng)求的用戶的響應(yīng)類型；<answer-options>元素，通過包含在<smsg-response-type>中的響應(yīng)類型確定該元素內(nèi)容，該元素包括響應(yīng)的具體內(nèi)容和標(biāo)識(shí)符；<verification>元素，該元素包括用于確認(rèn)用戶已閱讀所述系統(tǒng)消息請(qǐng)求的代碼；<time-out>元素，該元素表示其間期望對(duì)所述系統(tǒng)消息請(qǐng)求的用戶響應(yīng)的等待時(shí)間的持續(xù)時(shí)間；以及<restrict-access>元素，該元素允許服務(wù)器協(xié)助客戶端阻止對(duì)相應(yīng)服務(wù)的進(jìn)一步訪問，直到用戶關(guān)于該系統(tǒng)消息請(qǐng)求進(jìn)行響應(yīng)。
10.如權(quán)利要求9所述的方法，其中，所述<smsg-response-type>元素包括no-answer、only-one-answer和multiple-answer中的至少一個(gè)，其中，在不期待來自用戶的響應(yīng)的情況下，使用“no-answer”，在要選擇兩個(gè)不同的應(yīng)答中的一個(gè)的情況下，使用“only-one-answer”，在系統(tǒng)消息需要帶有多個(gè)應(yīng)答的用戶響應(yīng)的情況下，使用“multiple-answer”；其中，在<smsg-response-type>元素值是“no-answer”的情況下，系統(tǒng)消息請(qǐng)求文檔不包括<answer-options>元素，在只有一個(gè)或多個(gè)應(yīng)答的情況下，每個(gè)<answer-options>元素包括<answer-option-id>子元素和<answer-option-text>子元素，該<answer-option-id>子元素具有與用于標(biāo)識(shí)應(yīng)答選項(xiàng)的唯一編號(hào)對(duì)應(yīng)的標(biāo)識(shí)符，該<answer-option-text>子元素具有表示每個(gè)應(yīng)答選項(xiàng)的具體含義的文本；而且其中，所述<verification>元素包括兩個(gè)子元素<verification-text>元素和<verification-uri>元素，所述<verification-text>元素包括用戶必須在系統(tǒng)消息響應(yīng)中輸入的字母數(shù)字代碼，而所述<verification-uri>元素包括該字母數(shù)據(jù)代碼的位置的統(tǒng)一資源標(biāo)識(shí)符URI。
11.如權(quán)利要求10所述的方法，其中，在所述系統(tǒng)消息請(qǐng)求XML文檔中可選地包括<time-out>元素、<restrict-access>元素和<verification>元素。
12.如權(quán)利要求11所述的方法，其中，所述系統(tǒng)消息請(qǐng)求XML文檔包括<smsg-type>元素、<smsg>元素、具有用戶對(duì)系統(tǒng)消息請(qǐng)求的應(yīng)答的<answer>元素以及具有字母數(shù)字行的<verification>元素，該<verification>元素是用戶根據(jù)<verification>元素中包括的字母數(shù)字行而輸入的。
全文摘要
本發(fā)明提供了一種系統(tǒng)和方法，通過將MIME主體形式的新內(nèi)容和新特征標(biāo)記引入現(xiàn)有SIP框架來實(shí)現(xiàn)SIP中的系統(tǒng)消息通信，用于發(fā)送服務(wù)特定信息并接收用戶響應(yīng)。該系統(tǒng)消息可以包括可能選項(xiàng)的列表并要求來自用戶的響應(yīng)。
文檔編號(hào)H04L29/06GK1972302SQ20061014928
公開日2007年5月30日 申請(qǐng)日期2006年8月14日 優(yōu)先權(quán)日2005年8月12日
發(fā)明者帕滕·J·巴薩瓦拉, 雷德?？āだ准游牡绿m 申請(qǐng)人:三星電子株式會(huì)社