專利名稱：脫機(jī)即時消息的取回的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及基于SIP (會話發(fā)起協(xié)議)/SIMPLE (針對即時消息 傳送和呈現(xiàn)平衡擴(kuò)展的會話發(fā)起協(xié)議)技術(shù)的即時消息傳送。特別地， 本發(fā)明解決當(dāng)郵件服務(wù)器將即時消息存儲在網(wǎng)絡(luò)中以用于(大概在用 戶稍后連接到網(wǎng)絡(luò)時)進(jìn)一步遞送給最終用戶時出現(xiàn)的問題。
背景技術(shù)：
假設(shè)用戶A向用戶B發(fā)送一個或多個即時消息。用來遞送這些消 息的技術(shù)可以基于SIP MESSAGE方法或者消息會話中繼協(xié)議 (MSRP)。進(jìn)一步假設(shè)用戶B沒有向其SIP服務(wù)器注冊，并且郵件 應(yīng)用服務(wù)器正在存儲實際的即時消息，以用于稍后進(jìn)一步遞送給用戶 B。
當(dāng)用戶B向其SIP網(wǎng)絡(luò)注冊時，SIP用戶代理訂閱消息摘要和等 待指示符事件包，并得到有待于取回的消息的通知。假設(shè)郵件服務(wù)器 存儲了大量即時消息，因此用戶B得到包含那些已存儲即時消息的摘 要的通知。
本發(fā)明將支持一種改進(jìn)的脫機(jī)即時消息的取回。

發(fā)明內(nèi)容
圖1示出了說明根據(jù)本發(fā)明的終端設(shè)備和網(wǎng)絡(luò)設(shè)備的配置的示意 性框圖。
終端設(shè)備10包括接收塊11，選擇塊12，確定塊13和發(fā)送塊14。 接收塊11接收存儲在諸如網(wǎng)絡(luò)設(shè)備20之類的郵件服務(wù)器中并有待于 用戶取回的消息的摘要，其中每個消息與唯一的標(biāo)識符相關(guān)聯(lián)。選擇 塊12在消息的摘要的基礎(chǔ)上選擇將從郵件服務(wù)器中取回的至少一個消息。確定塊13基于與該至少一個消息相關(guān)聯(lián)的唯一標(biāo)識符來確定 對于該至少一個消息的取回有效的標(biāo)識符，由此獲得對于取回有效的 至少一個標(biāo)識符。并且發(fā)送塊14將具有對于取回有效的該至少一個 標(biāo)識符的取回請求發(fā)送至郵件服務(wù)器。唯一的標(biāo)識符可以是郵件服務(wù)器提供的消息標(biāo)識符或者是統(tǒng)一資源標(biāo)識符(URI)。諸如郵件服務(wù)器之類的網(wǎng)絡(luò)設(shè)備20存儲有待于用戶取回的消息， 并且包括接收塊21和發(fā)送塊22。接收塊21接收具有對于取回至少一 個已存儲消息有效的至少一個標(biāo)識符的取回請求，并且發(fā)送塊22向 發(fā)起該取回請求的用戶的終端設(shè)備(例如，終端設(shè)備10)發(fā)送該至少 一個消息。發(fā)送塊22可以在消息會話中繼協(xié)議(MSRP )的SEND消息中發(fā) 送該至少一個消息。根據(jù)'第一實施方式，網(wǎng)絡(luò)設(shè)備20還可以包括為每個已存儲消息 提供消息標(biāo)識符的提供塊23,其中，發(fā)送塊22將已存儲消息的摘要 發(fā)送給用戶，例如終端設(shè)備IO,其中每個消息與所確定的消息標(biāo)識符 相關(guān)聯(lián)。提供塊23可以將包括在每個已存儲消息的會話發(fā)起協(xié)議請求中 的Call-ID報頭字段用于消息標(biāo)識符，或者產(chǎn)生唯一的統(tǒng)一資源標(biāo)識 符(URI),其中URI可路由到網(wǎng)絡(luò)設(shè)備，其中消息標(biāo)識符是URI 的一部分。提供塊23可以將每個已存儲消息的消息會話中繼協(xié)議請求的 Message-ID報頭字段用于消息標(biāo)識符。根據(jù)第二實施方式，網(wǎng)絡(luò)設(shè)備20可以包括會議服務(wù)器以及諸如對應(yīng)于所存儲消息的虛擬SIP用戶代理之類的虛擬端點。會議服務(wù)器 可以接收來自用戶的、包括指向所選已存儲消息的標(biāo)識符的列表的取回請求(其中該取回請求建立第一會話以用于遞送所選消息)，為列 表中所標(biāo)識的每個所選消息建立與對應(yīng)于所選消息的虛擬端點的第 二會話，并且在所述第二會話中接收所選消息、并在所述第一會話中將所選消息轉(zhuǎn)發(fā)給用戶。應(yīng)當(dāng)理解，圖1中所示的配置是為了說明本發(fā)明，終端設(shè)備和網(wǎng)絡(luò)設(shè)備可以包括實現(xiàn)其他功能的其他塊(例如，網(wǎng)絡(luò)設(shè)備20中用于 存儲消息的存儲塊)，它們與理解本發(fā)明無關(guān)，在此省略其描述。圖2示出了在終端設(shè)備10 —端說明從郵件服務(wù)器中取回消息的 方法的流程圖。在步驟S31中，在終端設(shè)備上接收存儲在郵件服務(wù)器 中并有待于用戶取回的消息的摘要，其中每個消息與唯一的標(biāo)識符相 關(guān)聯(lián)。在步驟S32中，基于步驟S31中接收的消息的摘要來選擇將從 郵件服務(wù)器中取回的至少一個消息。在步驟S33中，基于與該至少一 個消息相關(guān)聯(lián)的唯一標(biāo)識符，確定對于該至少 一個消息的取回有效的 標(biāo)識符，從而獲得對于取回有效的至少一個標(biāo)識符，并在步驟S34中 將具有對于取回有效的標(biāo)識符的取回請求發(fā)送給郵件服務(wù)器。圖3示出了在網(wǎng)絡(luò)設(shè)備20 —端說明從郵件服務(wù)器中取回消息的 方法的流程圖。在步驟S41中，接收具有對取回至少一個已存儲消息 有效的至少一個標(biāo)識符的取回請求，并且在步驟S42中，向發(fā)起該取 回請求的用戶的終端設(shè)備發(fā)送該至少 一個消息。根據(jù)第二實施方式，在網(wǎng)絡(luò)設(shè)備20處接收來自用戶的、包括指 向所選已存儲消息的標(biāo)識符的列表的取回請求，其中該取回請求建立 第 一會話以用于遞送所選消息。為列表中標(biāo)識的每個所選消息建立第 二會話，并且在所述第二會話中接收所選消息，并在所述第一會話中 將所選消息轉(zhuǎn)發(fā)給用戶。本發(fā)明還可以實現(xiàn)為計算機(jī)程序產(chǎn)品。郵件服務(wù)器可以實現(xiàn)為郵件存儲應(yīng)用服務(wù)器或者即時消息郵件 服務(wù)器。根據(jù)本發(fā)明的第一實施方式，用戶接收消息摘要通知，其包括分 配給每個已存儲消息的唯一消息身份。對于用戶想要取回的每個消 息，SIP用戶代理創(chuàng)建以該消息的身份為地址的消息SIP會話，這例 如是在進(jìn)行一些變換之后。服務(wù)器在接收到INVITE請求時能夠唯一 地確定用戶想要取回的實際消息。這種解決方案允許用戶選擇那些將要取回的已存儲即時消息。在 帶寬有限的移動情境中、特別是在已存儲即時消息的數(shù)目和大小至關(guān) 重要的情況下，該優(yōu)點是巨大的。因此用戶可以選擇取回那些標(biāo)定為 緊急的消息，或是那些已經(jīng)從特定用戶處接收到的消息，并在稍后閱 讀剩余的消息。
根據(jù)本發(fā)明的第二實施方式，提供了一種機(jī)制，由此，只要它選 擇了用戶想要從郵件服務(wù)器中取回的即時消息，用戶就可以通過使用
URI列表的概念來創(chuàng)建以所選消息為地址的單個會話(SIP INVITE)。 這種實施方式將郵件服務(wù)器建模為包括會議服務(wù)器和多個虛擬SIP用 戶代理，每個用戶代理都代表一個已存儲即時消息。
根據(jù)這種實施方式，提供了一種機(jī)制，用以通過一種能夠在移動 環(huán)境中使用的最優(yōu)方式來選擇和取回已經(jīng)存儲在郵件服務(wù)器中的所 選消息。根據(jù)這種解決方案，用戶可以在單個協(xié)議操作中取回所選數(shù) 目不限的已存儲消息。
這種解決方案允許用戶通過使用朝向郵件服務(wù)器的單個會話而 將取回所選消息的信令和往返行程最小化。在此引入Garcia等人在 2005年9月30日提交給美國專利商標(biāo)局的臨時專利申請"Methodand apparatus for instant messaging"的內(nèi)容作為參考，該申i青和第一實施 方式允許取回全部已存儲的即時消息，或是逐個取回所選消息(這意 味著，每個消息都需要單獨的SIP會話)。
因此本發(fā)明的第二實施方式由于在建立會話時延遲較低而提高 了用戶的體驗，并且優(yōu)化了諸如空中接口之類的低帶寬信道上的資源 處理。


圖1示出了說明根據(jù)本發(fā)明的終端設(shè)備和網(wǎng)絡(luò)設(shè)備的配置的示意 性框圖。
圖2示出了說明根據(jù)本發(fā)明的取回方法的流程圖。 圖3示出了說明根據(jù)本發(fā)明的取回方法的流程圖。圖4示出了根據(jù)本發(fā)明第一實施方式的信令圖。 圖5示出了說明根據(jù)本發(fā)明第二實施方式的郵件服務(wù)器主機(jī)的示 意性框圖。
圖6示出了根據(jù)本發(fā)明第二實施方式的信令圖。
具體實施例方式
假設(shè)已經(jīng)將即時消息存放在了用戶的郵箱中，當(dāng)用戶的電話開機(jī) 時，才艮才居RFC 3842 "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", 電 話發(fā)送對消息摘要事件包的訂閱，并且接收具有待處理消息的通知。 由此引入RFC 3842的內(nèi)容作為參考。該機(jī)制還適用于語音郵件、傳 真等等。通知器(代表用戶的消息傳送系統(tǒng)進(jìn)行動作的SIP用戶代理) 在NOTIFY的主體中發(fā)送已存儲消息的消息摘要，例如"您有4條舊 消息和3條新消息"。
可選地，在摘要計數(shù)之后，可以對每個消息附加消息報頭，諸如 To (發(fā)往)、From (來自)、Date (日期)、Subject (主題)以及 Message-ID之類的。
一旦用戶/UE (用戶設(shè)備)被通知，其就可以向服務(wù)器發(fā)送包括 用于取回操作的期望媒體類型在內(nèi)的INVITE (為了 OMA (開放移動 聯(lián)盟)中的消息傳送群組，該INVITE必須包括MSRP的SDP (會話 描述協(xié)議)描述，但是也可以包括其他媒體類型)。
此夕卜，用戶可以應(yīng)用臨時專利申請"Method and Apparatus for Instant Messaging"中描述的機(jī)制，以便從郵件服務(wù)器中取回全部已 存儲的即時消息，其中所述即時消息包括元數(shù)據(jù)信息(例如，發(fā)送者， 遞送時間等等)。為此目的，提供SIP機(jī)制來取回先前存放在充當(dāng)消 息存儲應(yīng)用服務(wù)器的應(yīng)用服務(wù)器中的即時消息。這可以通過將SIP消 息封裝為例如RFC 3261第27.5節(jié)中定義的massage/sip或RFC 3420 中定義的message/sipfrag并繼而將其作為MSRP SEND請求的有效載 荷發(fā)送從而保持SIP消息的相關(guān)報頭來實現(xiàn)。由此引入RFC 3261和3420的內(nèi)容作為參考。此外，存儲應(yīng)用服務(wù)器可以向MSRP SEND消 息和經(jīng)過封裝的SIP消息添加包含接收到消息時的時間和日期的報 頭。更特別地，在每個已存儲的SIP和MSRP消息中插入日期/時間 報頭。針對已存儲即時消息的封裝可以使用新穎的語義，并且在MSRP 的原始上下文之夕卜，在MSRP中使用message/sip和message/sipfrag。 由此，提供了一種將包括報頭信息的已封裝SIP消息作為MSRP消息 的有效載荷進(jìn)行遞送的方法。通過以上機(jī)制，提供了一種方法和裝置，用戶借此可以聯(lián)系其郵 件服務(wù)器并取回已經(jīng)存放在存儲消息應(yīng)用服務(wù)器中的已有即時消息。 可以使用作為SIP會話一部分的SIP MESSAGE請求(按照IETF RFC 3428 )或者M(jìn)SRP消息(例如，MSRP SEND請求)來將即時消息存 放在存儲消息應(yīng)用服務(wù)器中。由此引入RFC 3428的內(nèi)容作為參考。 元數(shù)據(jù)和/或報頭信息可以使用戶能夠確定消息的來源、留下消息的時 間等等。一旦與MSRP媒體建立了 SIP會話，所有已存儲的消息將從服務(wù) 器被傳送給用戶/UE。每個已存儲的消息將在獨立的MSRP SEND請 求中發(fā)送(在MSRP SEND請求的組塊化(chunking)發(fā)生之前)， 并且每個消息將由它自己的原始Message-ID來標(biāo)識。以這種方式， 用戶 一次性(in one shot)取回了所有消息，但是通過Message-ID仍 然能夠?qū)λ邢⑦M(jìn)行分類。一些解決方案的缺點之一在于必須丟掉原始發(fā)送者標(biāo)識(用戶 信息)，因為MSRP報頭不包含與存放消息的SIP URI的任何關(guān)系。 因此，發(fā)送者與他們在消息傳送應(yīng)用收件箱中已經(jīng)可用的特定消息 (例如電子郵件、即時消息、MMS等)的關(guān)聯(lián)將丟失。這也適用于 SIP MESSAGE請求，因為該請求可以被發(fā)送，但是接受者將無法識 別發(fā)送者，因為發(fā)送者被設(shè)置成了存儲消息應(yīng)用服務(wù)器。由此，提出了一種機(jī)制，當(dāng)用戶想要取回他的已存儲即時消息時， 他或她與其存儲消息應(yīng)用服務(wù)器建立MSRP會話。存儲消息應(yīng)用服務(wù) 器將每個接收到的會話或單獨的MESSAGE (消息)封裝到MSRPSEND請求中。因此，每個MSRP SEND請求代表包含有效載荷的SIP 會話或者M(jìn)ESSAGE (消息)( 一個或多個MSRP SEND請求，或者 在消息的情況下是一些其他類型)。
然而，通過以上機(jī)制，不允許用戶B取回所選的消息(例如，由 給定用戶發(fā)送的、在特定時間范圍期間的、主題是特定的、或者具有 給定優(yōu)先級的)。特別地，沒有這樣的機(jī)制在其中用戶B可以向郵 件服務(wù)器指明用戶對接收哪個消息感興趣。
第一實施方式
圖4示出了根據(jù)本發(fā)明第一實施方式說明在用戶和存儲消息應(yīng)用 服務(wù)器(AS)之間所交換的消息的信令圖。如圖4所示，Alice使用 SIP MESSAGE請求向Charlie發(fā)送即時消息(流1 )。該MESSAGE 請求包括一些文本，在此命名為文本#1。假設(shè)Charlie為脫機(jī)，該消 息被接收并存儲在存儲消息應(yīng)用服務(wù)器(AS)處。
另 一個用戶Bob通過向Charlie發(fā)送INVITE請求來創(chuàng)建SIP會 話(流3) 。 INVITE請求包含會話描述，其中會話描述包括以發(fā)送 基于會話的即時消息為目的的MSRP描述符。由于Charlie脫機(jī)，存 儲消息應(yīng)用服務(wù)器截取INVITE請求并建立會話。然后，Charlie使用 MSRP SEND請求將兩個消息存放在Charlie的消息傳送賬號中(流5 和流7,分別包括文本#2和文本#3 )。也即，利用MSRP SEND請求 發(fā)送實際的消息。消息#9是終止即時消息會話的SIPBYE請求。
稍后，Charlie連接到網(wǎng)絡(luò)，并通過向他的郵件服務(wù)器(也即，存 儲消息應(yīng)用服務(wù)器)發(fā)送SIP SUBSCRIBE請求(消息#11)來訂閱消 息摘要通知。
通知被包括在NOTIFY請求(消息#13 )中。用戶根據(jù)對消息摘 要和消息等待指示符事件包的訂閱而接收到的通知包含每個消息的 唯一標(biāo)識符，以及其他單元，其中該唯一標(biāo)識符才各式為Message-ID 報頭。郵件服務(wù)器為每個消息選擇Message-ID。在通常的映射中，通 知中的Message-ID可以包含與SIP MESSAGE或者(發(fā)起MSRP會話的)SIP INVITE請求中的Call-ID報頭字段相同的值，或者，通知 中的Message-ID可以包含與MSRP SEND請求中的Message-ID報頭 字段相同的值。 一旦Charlie選擇了要取回的消息，他便創(chuàng)建以待取 回的特定消息為地址的INVITE請求(消息#15)。 第一實施方式有兩種可選的并且類似的實現(xiàn)示例。
實現(xiàn)示例A
郵件服務(wù)器將SIP中包括的Call-ID報頭字段復(fù)制到消息摘要的 Message-ID報頭，或者，郵件服務(wù)器將MSRP SEND請求的Message-ID 報頭復(fù)制到消息摘要的Message-ID報頭。因此，由Message-ID唯一 地標(biāo)識每個已存儲的SIP MESSAGE,完成的MSRP會話(其已經(jīng)由 SIP INVITE發(fā)起)、或者單獨的MSRP SEND請求?，F(xiàn)在，當(dāng)用戶根 據(jù)消息摘要選擇待取回的特定消息時，為每個已存儲的消息分配建立 于消息摘要中Message-ID報頭中的唯一 SIP URL
這允許在利用SIP MESSAGE請求存放消息的情況下逐個取回消 息。如果消息是利用(INVITE-BYE會話中的)MSRP SEND請求的 集合存放的，則該解決方案允許取回作為SIP INVITE的Call-ID所標(biāo) 識的會話的一部分的所有MSRP消息，或者取回每個單個的已存儲 MSRP SEND請求。
下面是用戶B接收到的消息摘要通知的示例。該通知指出兩個 新的文本消息正在等待被取回。
NOTIFY sip:charlie@pc.example.com SIP/2.0 To: <sip: charlie example. com>, tag=78923 From: <sip:mailserver.example.com>;tag=4442 Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: <sip:mailserver.example.com> Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Event: message-summary Subscription-State: active
Content-Type: application/simple-message-summary Content-Length: 503
Messages-Waiting: yes
Mess age-Account: sip: charlie咖ailserver. example. comText-Mes sage: 2/0 (1/0)
To<cha;rlie exaniple. com>
From: <alice@example.org>
Subj ect: caxpool tomorrow
Date: Sun, 09 Jul 2Q00 21:23:01 -0700
Priority: normal
Message-ID: 32098d@alicepc，example，org
To: <cha:rlie@example. com> From: <bob example.com>
Subject: HELP! at home ill, present for me please Date: Sun, 09 Jul 2000 21:25:12 -0700 Priority: urgent
Message-ID: d0982dkjs敏obmobile example com
假設(shè)Charlie只想取回第二個消息，其中該消息已由 bob@example.com發(fā)送,并且由4直是d0982dkjs@bobmobile.example.com 的Message-ID標(biāo)識。Charlie繼而創(chuàng)建以SIP URI為;也址的SIP INVITE 請求(其一般才各式為"sip:username@hostname，，)， 包括以下內(nèi)容
-所選Message-ID的轉(zhuǎn)義值(escaped value),如URI中的
-郵件服務(wù)器的/wW"flwe (這通常在SIP用戶代理中預(yù)先配置) 換言之，用戶(也即，Charlie)將已存儲即時消息的唯一標(biāo)識符 映射成為對取回有效的標(biāo)識符。
繼續(xù)我們的示例，Charlie創(chuàng)建SIP INVITE請求(例如，圖4中 的消息#15)，其R叫uest-URI是
sip:d0982dkjs%40bobmobile.example.com@mailserver.example.com "%40"是對應(yīng)于"@"符號的轉(zhuǎn)義字符(這是SIP中的標(biāo)準(zhǔn)實踐)。
例如，用戶(也即，Charlie)將在消息# 15中向語音郵件服務(wù)器 (存儲消息應(yīng)用服務(wù)器)發(fā)送以下INVITE (僅打印了有關(guān)的報頭)。
INVITE
sip: d0982dkj s奮40bobmobile. exaitple com@mailserver. exairple, com SIP/2.0
From: <sip:charlie@example.com> To:
<sip:d0982dkj s%40bobmobile.example com@mailserver.example.com>根據(jù)常規(guī)SIP過程將該INVITE請求路由到郵件服務(wù)器(存儲消 息應(yīng)用服務(wù)器)。郵件服務(wù)器提取"username",對其進(jìn)行解轉(zhuǎn)義 (unescape)以得到原始的消息ID,取回該消息，并將其發(fā)送給Charlie。 為jt匕，可以應(yīng)用臨時專利申i青"Method and Apparatus for Instant Messaging"中描述的機(jī)制。
例如，存儲消息應(yīng)用服務(wù)器得到圖4中的已存儲SIP INVITE消 息#3、已存儲MSRP SEND請求#5和#7、以及已存儲SIP BYE消息 #9,并將它們封裝到MSRP SEND請求中(未示出)，其中同樣將消 息類型設(shè)置為message/sip (RFC 3261第27.5節(jié))或message/sigfrag (RFC 3420)。
實現(xiàn)示例B
該實現(xiàn)與A基本相同。僅有的區(qū)別是郵件服務(wù)器不是用存放即 時消息的SIP MESSAGE或INVITE的Call-ID才艮頭值填充Message-ID 報頭，而是用指向郵件服務(wù)器并標(biāo)識消息的唯一 URI填充Message-ID報頭。
例如，下面是與用實現(xiàn)示例A所指示的相同的NOTIFY請求，但 是修改為實現(xiàn)示例B:
NOTIFY sip:charlie@pc.example,com SIP/2,0 T。 <sip:charlie example. com> tag=78923 From: <sip:mailserver.example ， com>;tag=4442 Date: Mori, 10 Jul 2000 04:28:53 GMT Contact: <sip:mailserver.example.com> Call-工D: adsf0923jscijw CSeq: 31 NOTIFY Event: message-summary Subscription-State: active
Content-Type: application/simple-message-summary Content - Length: 503
Messages-Waiting: yes
Message-Account: sip: charlie咖ailserver. example. com Text-Message: 2/0 (1/0)
To: <charlie example,com> From: <alice example.org>Subject: carpool tomorrow
Date: Sun, 09 Jul 2000 21:23:01 -0700
Priority: normal
Message-ID: 120932咖ailserver. example .com
To: <charlie example.com> From: <bob example.com>
Subject: HELP! at home ill, present for me please Date: Sun, 09 Jul 2000 21:25:12 -0700 Priority: urgent
Message-ID: 120933咖ailserver. example, com
因此，如果Charlie想要取回由Bob遞送的相同的第二個消息， 他將創(chuàng)建以郵件服務(wù)器分配給該消息的Message-ID值為地址的 INVITE請求，其中該Message-ID在服務(wù)器中唯一地標(biāo)識該消息。在 這種可選方案中，在創(chuàng)建SIP消息的Request-URI之前無需將所接收 的Message-ID轉(zhuǎn)換成別的東西，也即，將待取回消息的Message-ID 的值復(fù)制到SIP請求的Request-URI。
INVITE sip: 120933咖ailserver.example.com SIP/2.0 From: <sip: cha:rlie@example. com> To: <sip: 120933咖ailserver. example. com>
第二實施方式
與上面類似，假設(shè)用戶已經(jīng)脫機(jī)一段時間，并且一些其他用戶已 經(jīng)在存儲消息應(yīng)用服務(wù)器中存放了 一個或多個即時消息，該操作通常
使用SIP (會話發(fā)起協(xié)議，RFC 3261 )和MSRP (消息會話中繼協(xié)議， Internet-Draft draft-ietf-simple-message-sessions-12.txt)的結(jié)合作為協(xié) 議。當(dāng)用戶變?yōu)槁?lián)機(jī)時(連接到網(wǎng)絡(luò))，例如通過應(yīng)用臨時專利申 請"Method and Apparatus for Instant Messaging"中描述的機(jī)制，用戶 能取回全部的已存儲即時消息。然而，該機(jī)制是對于全部的已存儲即 時消息進(jìn)行操作。
上述第一實施方式允許用戶選擇一 個且剛好一 個即時消息以取 回(如果消息是通過SIP MESSAGE請求遞送的) 一個且剛好一個即 時消息會話(如果它們是通過使用SIP INVITE和多個MSRP SEND 請求來存;^文的)、或者一個且剛好一個MSRP SEND消息。如果用戶想要取回多于一個的即時消息、或者多于一個的即時消息會話、或者
屬于同一會話的多于一個(但不是全部)的MSRPSEND消息，則該
機(jī)制將產(chǎn)生問題，因為對于每個取回動作，用戶都必須與郵件服務(wù)器
建立獨立的SIP會話(也即，用戶必須發(fā)送獨立的SIP INVITE請求)。
這顯然帶來了問題，特別是在移動環(huán)境中。 一方面，這造成了連
續(xù)取回的消息之間的延遲，這是由于對信令流的1.5個附加往返行程
(INVITE-200-ACK )。而且，這些INVITE請求中的每一個都可能
包含大量的報頭，因此在用戶代理和郵件服務(wù)器之間傳送的字節(jié)數(shù)不
可忽略。
根據(jù)第二實施方式，假設(shè)
-已經(jīng)將以特定用戶為地址的即時消息存放在了郵件服務(wù)器中。 -存在一種適當(dāng)?shù)臋C(jī)制，通過該機(jī)制將有待于取回的即時消息的摘要 通知給用戶。該機(jī)制在郵件服務(wù)器中包括每個消息的唯一標(biāo)識符。這 種機(jī)制的示例在RFC 3842 "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)" 中描 述。
-存在一種機(jī)制，其允許用戶將已存儲即時消息的唯一標(biāo)識符映射為 對取回有效的標(biāo)識符。這種機(jī)制的示例在第一實施方式中描述。
-存在一種機(jī)制，用戶可以借此建立會話以取回一個或多個已存儲的 即時消息。這種機(jī)制的示例在臨時專利申請"Method and Apparatus for Instant Messaging" 中描述。
根據(jù)第二實施方式，將存儲消息應(yīng)用服務(wù)器或者郵件服務(wù)器主機(jī) 建模為虛擬實體，其包括
-用于SIP INVITE事務(wù)的URI列表服務(wù)器分發(fā)器(exploder)，其按 照 "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)" , draft畫ietf畫sipping-uri畫list陽conferencing -03.txt (在此引入其內(nèi)容作為參考)也被稱為會議服務(wù)器。 -也包含在相同的郵件服務(wù)器主機(jī)中的一個或多個虛擬SIP用戶代 理。這些虛擬SIP用戶代理中的每一個都代表資源，在本發(fā)明的情況下，該資源實際上是已存儲的即時消息或者即時消息的會話。特征是 每個即時消息或者即時消息的會話由唯 一 的統(tǒng) 一 資源標(biāo)識符(URI)標(biāo)識。
圖5示意性地示出了郵件服務(wù)器主機(jī)(即時消息郵件服務(wù)器)的 模型，其集成了會議服務(wù)器和多個虛擬SIP用戶代理，每個虛擬SIP 用戶代理都代表一個已存儲即時消息。
圖6示出了根據(jù)第二實施方式說明用戶和即時消息郵件服務(wù)器之 間交換的消息的信令圖。
如所指出的那樣已經(jīng)將郵件服務(wù)器建模，則當(dāng)用戶想要通過建立 單個SIP會話來取回所選擇的已存儲即時消息時，用戶代理發(fā)送單個 SIP INVITE請求(消息#1 ),其中該請求包含兩個消息主體建立即 時消息會話的會話描述協(xié)議(RFC 2327 )和URI列表(如 draft-ietf-sipping-uri-list-conferencing-03.txt中指出的)。SDP指明至 少建立基于MSRP的消息々某體流(dmft-ietf-simple-message畫sessions-12.txt)的意愿。URI列表包含一個或多個URI，每個URI唯一地標(biāo) 識在服務(wù)器中的用戶想要取回的已存儲即時消息。郵件服務(wù)器用200 OK響應(yīng)(消息#2 )進(jìn)行應(yīng)答，其中200 OK響應(yīng)包含指明了基于MSRP 的消息媒體流的SDP。
在接收到這樣的INVITE請求后，郵件服務(wù)器的會議服務(wù)器部分 將INVITE請求分發(fā)(explode )給標(biāo)識已存儲消息的每個虛擬SIP用 戶代理。會議服務(wù)器將包括SDP的INVITE請求發(fā)送給傳入INVITE 的URI列表中指明的每個URI。換言之，郵件服務(wù)器的會議服務(wù)器向 包含在INVITE ( #1 )的URI列表中的每個URI發(fā)送INVITE請求。 在圖6中，它們是INVITE請求#4、 #5和#6。每個INVITE請求都包 括SDP主體，其指明了至少建立基于MSRP的消息媒體流的意愿。
這在最終用戶和標(biāo)識給定消息的每個虛擬SIP用戶代理之間創(chuàng)建 了虛擬集中化會議。接著，這些虛擬SIP用戶代理中的每一個向會議 服務(wù)器發(fā)送已存儲的即時消息，會議服務(wù)器繼而將消息中繼給最終用 戶。換言之，虛擬SIP用戶代理用包含其自己的SDP的200 OK消息(圖6中的消息弁7、弁8和弁9)進(jìn)行應(yīng)答，然后，它們例如通過應(yīng)用臨 時專利申i會"Method and Apparatus for Instant Messaging"中指明的過 程(這對應(yīng)于圖6中的其余消息#13到#24)來發(fā)送已存儲的消息(或 者即時消息的會話)。
特別地，每個虛擬SIP用戶代理可以得到已存儲的消息、保持SIP MESSAGE請求的有關(guān)報頭(例如From ， To , Call-ID , P畫Asserted-Identity等)、將其封裝為message/sip ( RFC 3261第27.5 節(jié))或者message/sipfrag (RFC 3420)、并且將其作為MSRP SEND 請求(圖6中的消息#13、 #17、 #21 )的有效載荷發(fā)送。
類似地，每個虛擬SIP用戶代理可以得到已存儲SIP INVITE消 息、相應(yīng)的已存儲MSRP SEND請求、以及相應(yīng)的已存儲SIP BYE消 息，并將它們封裝在另一 MSRP SEND請求(消息#13、 #17、 #21) 中，其中同樣將消息類型設(shè)置為message/sip或者message/sipfrag。類 似地，每個虛擬SIP用戶代理可以得到已存儲的MSRP SEND請求， 將其封裝為message/msrp,并將其作為MSRP SEND請求(#13、 #17、 #21 )的有效載荷發(fā)送。
本發(fā)明涵蓋所有可能的組合和改變。例如，MSRP SEND請求#13 可以封裝已存儲的MSRP SEND請求，而MSRP SEND請求#15可以 封裝SIP MESSAGE請求，或者，MSRP SEND請求#17可以封裝SIP INVITE請求以及SIP BYE請求，其中SIP INVITE請求包括作為該會 話的一部分而發(fā)送的所有MSRP SEND請求。
一旦虛擬SIP UA將它的已存儲即時消息遞送給了服務(wù)器，它就 向會議服務(wù)器發(fā)送BYE請求(圖6中的消息#25、 #27和#29)以結(jié)束 會話。 一旦最后的虛擬SIP UA已經(jīng)斷開，會話服務(wù)器就向用戶發(fā)送 BYE請求(消息#31)以結(jié)束會話。
最后，最終用戶在僅僅一個信令會話中獲得了已存儲即時消息的 選擇。
應(yīng)當(dāng)注意，郵件服務(wù)器被認(rèn)為包括會議服務(wù)器和多個虛擬SIP用 戶代理，其中每個虛擬SIP用戶代理都代表已存儲即時消息?？紤]郵件服務(wù)器的單片電路實現(xiàn)，對其進(jìn)一步分解以便更好地理解。然而， 這并不強加對實現(xiàn)的限制，實現(xiàn)可以決定將郵件服務(wù)器的每個組件分 離在不同的主機(jī)中。在這種情況下，術(shù)語"郵件服務(wù)器"用來指那些 主才幾的集合。
還應(yīng)當(dāng)注意，在郵件服務(wù)器的單片電路實現(xiàn)的情況下，在會議服
務(wù)器和每個SIP虛擬用戶代理之間所定義的接口變成內(nèi)部調(diào)用或者已 定義的API,但是無需用SIP來實現(xiàn)。
重要的是應(yīng)當(dāng)注意，本發(fā)明的實施方式還適用于脫機(jī)消息"推送" 遞送機(jī)制。在推送遞送系統(tǒng)中，存儲消息傳送應(yīng)用服務(wù)器知道脫機(jī)用 戶何時返回上線，也即，通過SIP SUBSCRIBE/NOTIFY和/或任何其 他機(jī)制。
應(yīng)當(dāng)理解，上述描述是本發(fā)明的例證，并且其不構(gòu)成對本發(fā)明的 限制。對于本領(lǐng)域的技術(shù)人員來說，在不脫離所附權(quán)利要求限定的本 發(fā)明的真正精神和范圍的情況下，可以進(jìn)行各種修改和應(yīng)用。
權(quán)利要求
1.一種終端設(shè)備，包括用于接收存儲在郵件服務(wù)器中并有待于用戶取回的消息的摘要的裝置，其中每個消息與唯一標(biāo)識符相關(guān)聯(lián)；用于根據(jù)所述消息的摘要來選擇將從所述郵件服務(wù)器中取回的至少一個消息的裝置；用于根據(jù)與所述至少一個消息相關(guān)聯(lián)的所述唯一標(biāo)識符來確定對取回所述至少一個消息有效的標(biāo)識符，由此得到對于取回有效的至少一個標(biāo)識符的裝置；以及用于向所述郵件服務(wù)器發(fā)送具有所述對于取回有效的至少一個標(biāo)識符的取回請求的裝置。
2. 根據(jù)權(quán)利要求1所述的終端設(shè)備，其中，所述唯一標(biāo)識符是由 所述郵件服務(wù)器提供的消息標(biāo)識符。
3. 根據(jù)權(quán)利要求1所述的終端設(shè)備，其中，所述唯一標(biāo)識符是統(tǒng) 一資源標(biāo)識符(URI)。
4. 一種用于存儲有待于用戶取回的消息的網(wǎng)絡(luò)設(shè)備，所述網(wǎng)絡(luò)設(shè) 備包括接收裝置，用于接收取回請求，其中所述取回請求具有對取回已 存儲消息中的至少 一 個消息有效的至少 一 個標(biāo)識符；以及發(fā)送裝置，用于向發(fā)起所述取回請求的用戶的終端設(shè)備發(fā)送所述 至少一個消息。
5. 根據(jù)權(quán)利要求4所述的網(wǎng)絡(luò)設(shè)備，其中，將所述發(fā)送裝置配置 為在消息會話中繼協(xié)議(MSRP) SEND消息中發(fā)送所述至少一個消自.
6.根據(jù)權(quán)利要求4所述的網(wǎng)絡(luò)設(shè)備，還包括 提供裝置，用于為每個所述已存儲的消息提供消息標(biāo)識符，其中 將所述發(fā)送裝置配置為向用戶發(fā)送所述已存儲消息的摘要，每個 消息與所述提供的消息標(biāo)識符相關(guān)聯(lián)。
7. 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)設(shè)備，其中，將所述提供裝置配置 為將包括在每個所述已存儲消息的會話發(fā)起協(xié)議請求中的Call-ID報 頭字段用于所述提供的消息標(biāo)識符。
8. 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)設(shè)備，其中，將所述提供裝置配置 為將每個所述已存儲消息的消息會話中繼協(xié)議請求的Message-ID報 頭字段用于所述提供的消息標(biāo)識符。
9. 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)設(shè)備，其中，將所述提供裝置配置 為生成唯一的統(tǒng)一資源標(biāo)識符(URI),所述URI可^各由至所述網(wǎng)絡(luò) 設(shè)備，并且其中，所述提供的消息標(biāo)識符是所述URI的一部分。
10. —種取回存儲在郵件服務(wù)器中并有待于用戶取回的消息的方 法，所述方法包4舌接收存儲在郵件服務(wù)器中并有待于用戶取回的所述消息的摘要， 每個消息與唯 一 標(biāo)識符相關(guān)聯(lián)；根據(jù)所述消息的摘要來選擇將從所述郵件服務(wù)器中取回的所述消息中的至少一個消息；根據(jù)與所述至少一個消息相關(guān)聯(lián)的所述唯一標(biāo)識符來確定對取回所述至少一個消息有效的標(biāo)識符，由此得到對于取回有效的至少一 個標(biāo)識符；以及向所述郵件服務(wù)器發(fā)送具有所述對于取回有效的至少一個標(biāo)識 符的取回請求。
11. 一種取回有待于用戶取回的已存儲消息的方法，所述方法包括接收取回請求，其中所述取回請求具有對取回所述已存儲消息中 的至少一個消息有效的至少一個標(biāo)識符；以及向發(fā)起所述取回請求的用戶的終端設(shè)備發(fā)送所述至少 一 個消息。
12. 根據(jù)權(quán)利要求11所述的方法，還包括 為每個所述已存儲消息提供消息標(biāo)識符；以及向用戶發(fā)送所述已存儲消息的摘要，其中每個消息與所述提供的 消息標(biāo)識符相關(guān)聯(lián)。
13. —種用于存儲有待于用戶取回的消息的網(wǎng)絡(luò)設(shè)備，所述網(wǎng)絡(luò) 設(shè)備包括會議服務(wù)器；以及 對應(yīng)于已存儲消息的虛擬端點，其中將所述會議服務(wù)器配置為接收來自于用戶的包括標(biāo)識符列表的 取回請求，其中每個所述標(biāo)識符指向所述已存儲消息中的所選消息， 所述取回請求建立第一會話以用于遞送所述所選消息；為所述列表中 標(biāo)識的每個所述所選消息建立與對應(yīng)于所述所選消息的所迷虛擬端 點的第二會話；以及在所述第二會話中接收所述所選消息，并在所述 第一會話中將所述所選消息轉(zhuǎn)發(fā)給所述用戶。
14. 根據(jù)權(quán)利要求13所述的網(wǎng)絡(luò)設(shè)備，其中，所述虛擬端點是虛 擬會話發(fā)起協(xié)議(SIP)用戶代理。
15. —種取回存儲在郵件服務(wù)器中并有待于用戶取回的消息的方 法，所述方法包括接收來自用戶的包括標(biāo)識符列表的取回請求，其中每個所述標(biāo)識 符指向已存儲消息中的所選消息，所述取回請求建立第 一會話以用于 遞送所述所選消息；為所述列表中標(biāo)識的每個所述所選消息建立第二會話；以及 在所述第二會話中接收所述所選消息，并在所述第一會話中將所 述所選消息轉(zhuǎn)發(fā)給所述用戶。
16. —種計算機(jī)程序產(chǎn)品，包括用于處理設(shè)備的程序，所述程序 包括軟件代碼部分，當(dāng)所述程序在所述處理設(shè)備上運行時，所述軟件 代碼部分用于執(zhí)行權(quán)利要求10到12或15任一項所述的步驟。
17. 根據(jù)權(quán)利要求16所述的計算機(jī)程序產(chǎn)品，其中，所迷計算機(jī) 程序產(chǎn)品包括計算機(jī)可讀介質(zhì)，其上存儲有所述軟件代碼部分。
18. 根據(jù)權(quán)利要求16所述的計算機(jī)程序產(chǎn)品，其中，所迷程序可 直接載入到所述處理設(shè)備的內(nèi)部存儲器中。
全文摘要
公開了取回存儲在郵件服務(wù)器上并有待于用戶取回的消息。在用戶的終端設(shè)備處接收存儲在郵件服務(wù)器上并有待于用戶取回的消息的摘要(S31)，其中每個消息與唯一標(biāo)識符相關(guān)聯(lián)?；谠撓⒌恼x擇將從郵件服務(wù)器中取回的至少一個消息(S32)。根據(jù)與該至少一個消息相關(guān)聯(lián)的唯一標(biāo)識符，確定對于該至少一個消息的取回有效的標(biāo)識符(S33)，并且將具有對于取回有效的標(biāo)識符的取回請求發(fā)送給郵件服務(wù)器(S34)。在接收到具有對取回至少一個已存儲消息有效的至少一個標(biāo)識符的取回請求之后(S41)，郵件服務(wù)器向終端設(shè)備發(fā)送該至少一個消息(S42)。
文檔編號H04L12/58GK101292480SQ200680039030
公開日2008年10月22日 申請日期2006年10月13日 優(yōu)先權(quán)日2005年10月19日
發(fā)明者A·哈魯納, M·A·加西亞-馬丁 申請人:諾基亞公司