專利名稱：基于會話的通信的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信系統(tǒng)中的基于會話的通信，并且特別涉及其中多個媒 體類型可以被提供的通信。
背景技術(shù)：
以下對背景技術(shù)的描述可能包括在本發(fā)明之前對相關(guān)技術(shù)來說未知但 由本發(fā)明提供的洞察、發(fā)現(xiàn)、理解或公開或者公開的關(guān)聯(lián)內(nèi)容。本發(fā)明的 一些此類貢獻(xiàn)可在下文中被特別指出，而本發(fā)明的其它此類貢獻(xiàn)從其上下 文中將是顯而易見的。
通信技術(shù)特別是基于IP的通信技術(shù)和末端用戶終端的發(fā)展已經(jīng)使得
實現(xiàn)了多功能通信可能性和不同服務(wù)的引入。服務(wù)^L^來越頻繁地使用由 SIP (會話發(fā)起協(xié)議)提供的原語來實現(xiàn)，其中，所述原語不是被垂直整 合到通信系統(tǒng)中，而是用來構(gòu)建多媒體架構(gòu)的工具。更準(zhǔn)確地說，SIP是 IETF定義的應(yīng)用層控制(信令)協(xié)議，用于創(chuàng)建、修改和終止具有一個 或更多參與者的會話。
可以利用SIP會話的一個特定的特征是群組通信。這里所使用的術(shù)語 "群組"(group)指有意參與同一群組通信的兩個或更多用戶(即群組 成員)的任意邏輯群組，并且群組通信覆蓋兩個或更多參與者之間的會話。 群組通信的示例包括會議、互聯(lián)網(wǎng)電話呼叫、多々某體分發(fā)、多媒體會議、 即時消息通信和聊天。
由于所述多功能通信可能性，在群組中不同媒體類型可以是可用的， 例如語音、即時消息、視頻、游戲服務(wù)、音樂、文件傳輸?shù)?。典型地僅僅 以上4某體類型中的一些4吏用在會話中。想要與其它群組成員建立會話的用戶可以發(fā)送具有SDP (會話描述協(xié)議)提供的SIP請求，其中，所述SDP 提供定義所述用戶想要為所述會話提供的媒體類型。然而，可能已經(jīng)定義 了策略或規(guī)則，其可導(dǎo)致所提供的媒體類型中的一個或更多將被控制M 建立或群組成員的服務(wù)器拒絕，例如由于該會話已經(jīng)存在。與以上安排關(guān) 聯(lián)的問題中的一個是，用戶將不會收到任何關(guān)于為何所述會話建立請求僅 被部分地接受(即不是作為整體被接受)的信息，所述原因例如是會話已 經(jīng)存在。

發(fā)明內(nèi)容
從而本發(fā)明的目的是提供一種方法和用于實現(xiàn)該方法的設(shè)備以便克服 以上問題。所述目的通過一種方法、設(shè)備、模塊、信令消息、系統(tǒng)和程序 產(chǎn)品來達(dá)到，其由獨立權(quán)利要求中所限定的內(nèi)容來表征。優(yōu)選實施例被/> 開在從屬權(quán)利要求中。


下文中，將參考附圖更加詳細(xì)地描述實施例，其中
圖1示例性示出了提供群組通信服務(wù)的通信系統(tǒng)的一般體系結(jié)構(gòu)的示
例；
圖2和3是設(shè)備的簡化框圖4、 5和6是每個都示例性示出了設(shè)備的功能的流程圖；以及 圖7示例性示出才艮據(jù)實施例的信令。
具體實施例方式
下文中的實施例是示例性的。盡管本說明書在一些位置可能提到"一"、 "一個"或"一些"實施例，但這并非必然地意味著每個此種提及都針對 同一個(些)實施例，或所述特征僅應(yīng)用于單一實施例。不同實施例的單 一特征還可以被合并以提供其它實施例。
本發(fā)明可適用于支持基于SIP的會話并且提供向會話提供多個媒體類型的可能性的任何用戶終端、服務(wù)器、對應(yīng)的部件和/或任何通信系統(tǒng)或不 同通信系統(tǒng)的任意組合。對于會話類型或媒體類型或所述提供機制不存在 任何限制。所述通信系統(tǒng)可以是固定的通信系統(tǒng)或無線通信系統(tǒng)或者利用 固定網(wǎng)絡(luò)和無線網(wǎng)絡(luò)兩者的通信系統(tǒng)。所使用的協(xié)議，通信系統(tǒng)、服務(wù)器 和用戶終端、或?qū)?yīng)的部件的規(guī)范發(fā)展迅速，這尤其是在無線通信中。這 樣的發(fā)展可能需要對實施例的額外改變。因此，所有術(shù)語和表述都應(yīng)當(dāng)被 寬泛地解釋，并且其意在示例性示出而非限制所述實施例。
下文中，將使用實施例可應(yīng)用到的系統(tǒng)架構(gòu)作為示例來描述不同的實
施例，該架構(gòu)基于用于信令和會話建立的SIP以及用于傳送關(guān)于所提供的 媒體類型的信息的SDP，然而，這并非將實施例限制于此類架構(gòu)。SIP和 SDP由互聯(lián)網(wǎng)工程任務(wù)組(IETF)定義。SIP是用于創(chuàng)建、修改和終止具 有一個或更多參與者的會話的控制(信令)協(xié)議。SDP是用于傳送々某體細(xì)
用層協(xié)議，其不考慮所述信息如何被傳送。換句話說，SIP和SDP不是被 垂直地整合到通信系統(tǒng)中。IETF規(guī)范和互聯(lián)網(wǎng)草案可以在 http:〃www.ietf.org找到。
這里々某體類型覆蓋了在例如用戶終端之類的端點之間可協(xié)商的通用類 型的數(shù)據(jù)和/或通信裝置。媒體類型的示例包括但不限于文本(文本信息)、 圖像(圖像數(shù)據(jù))、音頻(音頻數(shù)據(jù))、視頻(視頻數(shù)據(jù))、應(yīng)用(某其 它種類的數(shù)據(jù)，典型是未被解釋的二進(jìn)制數(shù)據(jù)或?qū)⑼ㄟ^應(yīng)用進(jìn)行處理的信 息)、多部分(由多個獨立數(shù)據(jù)類型的實體組成的數(shù)據(jù))和消息(已封裝 的消息)。另外，媒體類型包含提供群組通信服務(wù)的不同子類型和/或連接 類型(包括不同的覆蓋服務(wù))。從而，媒體類型可以被選自例如這樣的組， 該組包括'poc，、 'im，、'音頻，、'一見頻，、'會漢，、'應(yīng)用，、 '所有，、'其它，。
提供基于SIP的^^舌的通信系統(tǒng)的一般架構(gòu)在圖1中示出。圖1是簡 化了的系統(tǒng)架構(gòu)，其僅示出了一些單元和功能實體，其全部都是其實現(xiàn)可 以與所示出的不同的邏輯單元。圖1中所示的連接是邏輯連接；實際的物理連接可以是不同的。對于本領(lǐng)域技術(shù)人員來i兌顯然該系統(tǒng)還包括其它功 能和結(jié)構(gòu)。應(yīng)當(dāng)認(rèn)識到使用在群組通信中或用于群組通信的功能、結(jié)構(gòu)、 單元和協(xié)議與實際的發(fā)明無關(guān)。因此，這里不需要更詳細(xì)地討論它們。
圖1中所示的通信系統(tǒng)100包括用戶終端(UT) 200，每當(dāng)需要時其 可經(jīng)由包括接入和核心網(wǎng)的一個或更多網(wǎng)絡(luò)400連接到服務(wù)器300。
用戶終端200是這樣的一件裝備或設(shè)備，其將該用戶終端及其用戶與 訂閱關(guān)聯(lián)，或被安排為將該用戶終端及其用戶與訂閱關(guān)聯(lián)，并且允許用戶 與通信系統(tǒng)交互。用戶終端向用戶呈現(xiàn)信息，并且允許用戶輸入信息。換 句話說，用戶終端可以是能夠從網(wǎng),收信息和/或向網(wǎng)絡(luò)發(fā)送信息的、可 無線地或經(jīng)由固定連接來連接到網(wǎng)絡(luò)的任何終端。用戶終端的示例包括個 人計算機、游戲控制臺、膝上電腦(筆記本)、個人數(shù)字助理、移動臺(移 動電話)或線路電話。
服務(wù)器300是主持會話的一件裝備或設(shè)備。主持會話的服務(wù)器管理會 話，即控制會話，或充當(dāng)對于會話的焦點或控制功能。換句話說，所有與 會話相關(guān)的控制業(yè)務(wù)都將經(jīng)過該服務(wù)器，并且服務(wù)器可以使用不同的策略， 例如特定與服務(wù)器的策略或特定于群組或特定于用戶的策略，用于控制會 話及會話建立。
實施例可以被應(yīng)用到的一個實現(xiàn)環(huán)境是利用XDM (XML文檔管理) 的群組通信架構(gòu)。開放移動聯(lián)盟(OMA)已將XDM定義為基于XCAP 協(xié)議(XML配置訪問協(xié)議)的用于群組和列表管理的一般框架。OMA規(guī) 范可以在http:ASvww.openmobilealliance.org沖戈到。XDM定義這才羊一種公 共機制，該機制使得特定于用戶的服務(wù)相關(guān)信息，諸如群組定義，對于駐 留在用戶裝備中的不同應(yīng)用(服務(wù)啟動者)和客戶端是可訪問的，并且啟 動此類信息的創(chuàng)建、修改、取回(retrieval)和刪除。提供群組通信服務(wù) 的應(yīng)用可以例如是PoC (無線一鍵通，push to talk over cellular)、消息 傳送或會漢。PoC規(guī)范當(dāng)前正由OMA下的PoC工作組開發(fā)。關(guān)于PoC 的更詳細(xì)信息可經(jīng)由上面提到的OMA的互聯(lián)網(wǎng)頁面找到。從而，服務(wù)器 300可以是PoC服務(wù)器、即時消息傳送服務(wù)器或支持例如音頻、視頻和消息傳送之類的不同媒體類型的會議服務(wù)器。然而，服務(wù)器300可以是包括 所需功能并^皮配置為充當(dāng)才艮據(jù)實施例的服務(wù)器的用戶終端。
圖2示出了被配置為根據(jù)實施例的用戶終端的設(shè)備200的簡化框圖， 該設(shè)備以下被稱為用戶終端。用戶終端200包括 一個或更多應(yīng)用客戶端 單元(客戶端)21，應(yīng)用客戶端單元中的至少一個被配置為根據(jù)實施例的 應(yīng)用客戶端單元，下文中將其稱為客戶端；數(shù)據(jù)存儲裝置，例如存儲器 (mem)22;用于接收和用于發(fā)送通信(消息、信息、信令、不同輸出或 輸入)的接收器(Rx) 23和發(fā)送器(Tx) 24;用于接收用戶指令和向用 戶提供信息的用戶接口 (UI)26;以及一個或更多操作處理器(operation processor) 25，用于處理一個或更多客戶端，用于對接收A^送包括會話 建立的通信進(jìn)行處理和控制，用于對經(jīng)由用戶接口 26接收用戶指令和向用 戶提供信息進(jìn)行處理和控制，以及用于控制存儲器的使用。對本領(lǐng)域技術(shù) 人員來說顯然用戶終端可以包括不需要在這里被詳細(xì)描述的其它部件、實 體、功能和結(jié)構(gòu)，或者僅包括上述部件中的一些。還可能的是參與會話的 用戶終端不包括根據(jù)實施例的任何客戶端，即用戶終端沒有凈皮配置為通過 根據(jù)實施例的用戶終端來執(zhí)行下文描述的所有功能，可以僅實現(xiàn)所述功能 中的一些。
根據(jù)實施例，客戶端或者客戶端駐留于其中的用戶終端可被配置為提 供客戶端功能，用于確定媒體類型拒絕的原因。客戶端或客戶端駐留于其 中的用戶終端可以進(jìn)一步被配置為，當(dāng)決定稍后是否可能使得4某體類型被 接受時使用所述原因。為此，客戶端或客戶端駐留于其中的用戶終端可被 配置為至少臨時地將原因或其指示存儲到數(shù)據(jù)存儲裝置22。 客戶端21的功能以下通過圖4和7來更詳細(xì)地描述。 圖3示出了被配置為根據(jù)實施例的服務(wù)器部件的設(shè)備300的簡化框圖， 該設(shè)備以下被稱為服務(wù)器。服務(wù)器300包括 一個或更多用于主持會話的 應(yīng)用主機單元(主機)31，應(yīng)用主機單元中的至少一個被配置為根據(jù)實施 例的應(yīng)用主機單元，下面將其稱為主機；數(shù)據(jù)存儲裝置，例如存儲器(mem ) 32;用于接收和發(fā)送通信(消息、信息、信令、不同輸出或輸入)的接收器(Rx) 33和發(fā)送器(Tx) 34;以及一個或更多操作處理器35,用于處 理一個或更多主機，用于對接收和發(fā)送與會話相關(guān)、包括會話建立的通信 進(jìn)行處理和控制，用于處理和控制會話，以及用于控制存儲器的使用。對 于本領(lǐng)域技術(shù)人員來說顯然服務(wù)器可以包括不需要在這里詳細(xì)描述的其它 部件、實體、功能和結(jié)構(gòu)，或者僅包括上面描述的部件中的一些。還有可 能的是主持會話的服務(wù)器不包括根據(jù)實施例的任何主機，即服務(wù)器沒有被 配置為通過根據(jù)實施例的服務(wù)器來執(zhí)行下文描述的所有功能，可以僅僅實 現(xiàn)所述功能中的一些。
主機可以被配置為提供根據(jù)實施例的主機功能，用于為提供媒體類型 的用戶終端提供媒體類型拒絕的原因。主機可以被進(jìn)一步配置為決定是否 拒絕所提供的媒體類型。為此，主機可以被配置為至少臨時地將原因或其 指示存儲到數(shù)據(jù)存儲裝置32。
下面通過圖5、 6和7來更詳細(xì)地描述主機31的功能。 實現(xiàn)通過實施例描述的相應(yīng)設(shè)備的功能的設(shè)備，例如服務(wù)器或相應(yīng)的 服務(wù)器部件、用戶終端和/或其它相應(yīng)的裝備或設(shè)備，不僅包括現(xiàn)有裝置， 而是還有用于實現(xiàn)通過實施例描述的相應(yīng)設(shè)備的功能的裝置，并且其可以 包括用于每個單獨功能的單獨裝置，或者裝置可被配置為執(zhí)行兩個或更多 功能。目前的設(shè)備包括可以在實施例中使用的處理器和存儲器。例如，應(yīng) 用客戶端單元21或主機單元31可以是被配置為通過操作處理器來執(zhí)行的 算術(shù)操作或程序的軟件應(yīng)用或才莫塊或單元。實現(xiàn)實施例的功能所需的所有 修改和配置可以被實施為例程，其中，所述例程可以被實現(xiàn)為被添加的或 更新的軟件例程、應(yīng)用電路(ASIC)和/或可編程電路。包括小應(yīng)用程序 和宏的也被稱為程序產(chǎn)品的軟件例程可以被存儲在任何設(shè)備可讀的數(shù)據(jù)存 儲媒體中，并且其包括用于實施特定任務(wù)的程序指令。軟件例程可以被下 載到設(shè)備中。例如服務(wù)器，或?qū)?yīng)的服務(wù)器部件，或用戶終端，或?qū)?yīng)的 用戶終端之類的設(shè)備，可以被配置為計算機或例如單片機單元的微處理器， 其至少包括用于提供用于算術(shù)操作的存儲區(qū)域的存儲器和用于執(zhí)行所述算 術(shù)操作的操作處理器。操作處理器的示例包括中央處理單元。所述存儲器可以是可拆卸地連接到所述設(shè)備的可移除存儲器。
下文中，為清楚起見在作出如下假設(shè)的情況下描述不同實施例盡管 一個或更多^(某體類型可以被拒絕，但建立會話的請求沒有被整體地拒絕， 并且如果媒體類型被拒絕，則原因被指示，并且存在兩種拒絕的原因基 于策略的或會話已存在。進(jìn)一步地，所述會話可以用于一對一通信，群組 內(nèi)的一對一通信，或一對多通信，或多對多通信，或多對一通信。在本上 下文中，已加入務(wù)活的用戶或更準(zhǔn)確地說的用戶終端被稱為參與者。換句 話說，當(dāng)請求被發(fā)送時參與者的數(shù)量可以是零個、 一個、兩個、三個等。
圖4示出了用戶終端中的客戶端的實施例。然而，為清楚起見，在下 文中使用術(shù)語"用戶終端"。
當(dāng)用戶終端在步驟401中發(fā)送帶有一個或更多媒體類型提供的會話建 立請求時圖4開始。所述請求可以是帶有提供所述媒體類型的SDP的SIP INVITE,并且所述請求可以被發(fā)送到服務(wù)器的URI或管理會話建立的服 務(wù)器中的對應(yīng)服務(wù)。URI是用于標(biāo)識概要(abstract)或物理資源的統(tǒng)一 資源標(biāo)識符。
當(dāng)所述用戶終端接收到指示接受所述請求的至少一部分的響應(yīng)時(步 驟402)，所述用戶終端在步驟403中檢查所提供的媒體類型是否被拒絕。 如果所提供的媒體類型已被拒絕，則用戶終端在步驟404中檢查所述原因 的指示是否指示了現(xiàn)存會話。如果其指示，則用戶終端在步驟405中推斷 該用戶終端正在加入現(xiàn)存會話，而不是建立會話，并且在步驟406中通知 用戶該會話已存在以及被拒絕的媒體類型。除此之外，用戶終端在步驟407 中推斷，被拒絕的々某體類型不是被協(xié)商的々某體類型中的一個，并且可以稍 后在所述會話期間被提供，隨后在步驟408中開始通信。
如果所述原因沒有指示現(xiàn)存會話(步驟404)，則拒絕的原因是基于 策略的(步驟409)。換句話說，所述原因可能取決于例如主機策略、用 戶的訂閱者信息或群組定義。因此，用戶終端在步驟410中推斷所述々某體 類型稍后不會被提供，因為所述策略保持不變。隨后用戶終端在步驟408 中開始通信。所接收的響應(yīng)可以是SIP 200 OK，其帶有指示被接受和被拒絕的媒體 類型的SDP主體，并且?guī)в邪ㄈ晃谋敬a和解釋文本的告警報頭，例 如按照格式〈xxx、 + <解釋文本>，該格式至少在OMA PoC規(guī)范中被定義。 用于指示會話已存在的解釋文本可以是"會話存在"或"加入會話"或"被 參與者拒絕"。然而，應(yīng)當(dāng)認(rèn)識到，任何其它合適的報頭、字段或位都可 以被用于指示拒絕原因，或用于指示發(fā)生并提供信息的事件，其中潛在拒 絕原因可能基于所述信息而被推斷，并且對于所述解釋文本的內(nèi)容沒有任 何限制。
在另一實施例中，所述用戶終端可以被配置為，不管告警報頭的內(nèi)容 而將帶有告警報頭或?qū)?yīng)指示的被拒絕的々某體類型解釋為意味著會話已存 在。換句話說，該實施例的用戶終端被配置為僅識別一個原因，該原因是 現(xiàn)存會話。
在另一實施例中，所述用戶終端可以被配置為，不管告警報頭的內(nèi)容 而將帶有告警報頭或?qū)?yīng)指示的被拒絕的媒體類型解釋為意味著拒絕該媒 體類型的原因是會話已存在，以及將不帶有告警報頭或?qū)?yīng)指示的被拒絕 的媒體類型解釋為意味著該媒體類型由于策略而被拒絕。
如果多于一個的媒體類型因為會話已存在而被拒絕，則所述用戶終端 可以被配置為， 一次而非逐個地將所有被拒絕的媒體類型通知給用戶。
在實施例中，如果所述響應(yīng)包含多于一個被拒絕的媒體類型但僅一個 拒絕原因的指示，則所述用戶終端被配置為解釋成對于所有被拒絕的媒體 類型原因是相同的。
在實施例中，如果所述響應(yīng)包含多于一個被拒絕的媒體類型但僅一個 拒絕原因的指示，則所述用戶終端被配置為解釋成該原因是針對該指示所 伴隨的媒體類型，其它媒體類型由于其它原因而被拒絕。
在實施例中，所述用戶終端#:配置為，將指示會話建立請求的接受并 且包含至少一個被接受的媒體類型和至少一個被拒絕的媒體類型的響應(yīng)解 釋為指示該會話已存在，以及取代建立會話，該用戶終端正在加入已建立 的會話，其中，所述至少一個被拒絕的媒體類型帶有例如告警報頭的對拒絕原因的指示。
在實施例中，所述用戶終端可以被配置為，除了向用戶指示所提供的媒體類型中的一個或更多被拒絕之外，向用戶指示稍后可以是可接受的(即稍后可以被提供的)那些被拒絕的媒體類型，以及要求用戶選擇稍后是否提供所述媒體類型。
在實施例中，所述用戶終端被配置為，在沒有任何用戶指令的情況下，稍后提供被推斷為"稍后可以被提供的媒體類型，，的被拒絕的媒體類型。
在其中被拒絕的媒體類型可關(guān)聯(lián)或可不關(guān)聯(lián)于拒絕原因的指示的實施例中，所述用戶終端被配置為，如果所述指示缺失，則推斷稍后不提供該媒體類型。
在實施例中，所述用戶終端被配置為，響應(yīng)于接收所述響應(yīng)(步驟402 )立即使用被接受的媒體類型觸發(fā)通信。
圖5和6示出了主機的實施例。由于主機典型位于服務(wù)器中，所以為清楚起見在下文中使用術(shù)語服務(wù)器。
通過參考圖5中所示的實施例，服務(wù)器在步驟501中接收帶有一個或更多媒體類型提供的會話建立請求。響應(yīng)于該請求，服務(wù)器在步驟502中檢查該會話是否已存在。如果該會話不存在，則服務(wù)器在步驟503中繼續(xù)該會話建立。該會話如何被實際建立和/或該會話內(nèi)的通信如何繼續(xù)對于本發(fā)明無關(guān)緊要，因此其在這里未被詳細(xì)描述。
如果該會話已存在，則服務(wù)器在步驟504中取出媒體類型提供，并在步驟505中檢查該媒體類型是否在使用中，即針對該M的被協(xié)商的媒體類型。如果是，則服務(wù)器在步驟506中接受該媒體類型，并且然后在步驟507中檢查是否所有被提供的媒體類型都被檢查。如果不是，則服務(wù)器通過取出媒體類型提供從步驟504繼續(xù)。
如果該々某體類型未在使用中(步驟505),則服務(wù)器在步驟508中拒絕該媒體類型，并且在步驟509中負(fù)責(zé)拒絕原因的指示被添加到響應(yīng)。然后，服務(wù)器通過檢查是否所有被提供的媒體類型被檢查而從步驟507繼續(xù)。
如果所有被提供的媒體類型被檢查(步驟507 )，則服務(wù)器在步驟510發(fā)送對該請求的響應(yīng)，該響應(yīng)將每個被提供的媒體類型指示為被接受或被拒絕，并且將每個被拒絕的媒體類型與拒絕原因的指示關(guān)聯(lián)。
圖5中的實施例的優(yōu)點是，所述會話的其它參與者不會被在步驟501中接收的會話建立請求打擾。
在圖6的實施例中，所述服務(wù)器優(yōu)選維護(hù)關(guān)于會話的參與者的信息，或否則被配置為接收所需的信息。然而，由于該實施例不需要對關(guān)于參與者的信息的取回的任何改變，所以其在這里未被詳細(xì)描述。
通過參考圖6中所示的實施例，步驟601至607分別對應(yīng)于圖5中所示的步驟501至507，并且因此沒有在里^^皮無益地重復(fù)。
如果所述^^某體類型未在使用中(步驟605)，則服務(wù)器在步驟608中檢查該媒體類型是否滿足策略要求，即該媒體類型是否符合針對用戶終端、會話、群組、服務(wù)器或其它什么而定義的策略。本發(fā)明不限制策略定義，并且任何策略都可以被使用。所述策略要求可以例如由一個規(guī)則或一組規(guī)則來定義。如果該纟某體類型未能滿足策^求，則服務(wù)器在步驟609中拒絕該媒體類型，并且通過檢查是否所有被提供的媒體類型被檢查而從步驟607繼續(xù)。如果該^某體類型滿足所述策^求，則服務(wù)器在步驟610中將該媒體類型添加到提供，并且通過檢查是否所有被提供的媒體類型被檢查而從步驟607繼續(xù)。
如果所有被提供的媒體類型被檢查(步驟607 )，則服務(wù)器在步驟611中將媒體類型提供發(fā)送給參與者，所述提供包含在步驟610中被添加的一個(多個)媒體類型。服務(wù)器在步驟612中接收來自參與者的響應(yīng)，每個響應(yīng)指示所提供的一個(多個)媒體類型中的哪些被接受，哪些被拒絕。所述服務(wù)器被配置為，在步驟613中形成對在步驟601中接收的請求的響應(yīng)，該響應(yīng)將每個被提供的媒體類型指示為被接受或被拒絕，并將每個被拒絕的媒體類型與拒絕原因的指示關(guān)聯(lián)。所述響應(yīng)包含被所述服務(wù)器拒絕或接受的媒體類型(即步驟606和609)。至于被提供給參與者的媒體類型，所述服務(wù)器^L配置為，如果所有參與者都接受則接受該媒體類型，如果至少一個參與者拒絕則拒絕該媒體類型。取決于實現(xiàn)，所述拒絕原因的指示可以是相同的，不管其^J良務(wù)器還是被參與者拒絕，或者所述指示可以取決于拒絕所述媒體類型的實體。進(jìn)一步地，關(guān)于所述拒絕的一些附加信息可以^皮添加。
然后，所述服務(wù)器在步驟614中發(fā)送所述響應(yīng)。
圖6中的實施例的優(yōu)點是，步驟601的請求的發(fā)送者想要為會話的參與者提供但未在使用中的媒體類型被提供給其它參與者，由此滿足最初意圖。
在其中如果媒體類型被拒絕則原因被指示的上面描述的實現(xiàn)的優(yōu)點是，所述用戶終端可以推斷出其是否合理，例如在會話的稍后階段重新提供被拒絕的媒體。例如，如果定義僅現(xiàn)存會話中已在使用中的媒體類型被接受而其它媒體類型被自動拒絕并且被指示的原因是"會話已正在進(jìn)行"的規(guī)則或任何其它策略存在，則所述用戶終端可以被配置為，從關(guān)聯(lián)(被拒絕的媒體類型，被指示的原因)推斷，稍后向會話提供被決絕的媒體類型的提供將被拒絕，并且因而沒有意義提供它，但是在會話已被終止并且新會話被建立之后，被拒絕的4某體類型可以隨后被再次提供。該實現(xiàn)的進(jìn)一步的優(yōu)點是通過它，例如試驗和錯誤類型方法之類的可以被避免，其中，所述方法導(dǎo)致降低的末端用戶滿意度。
盡管上文未詳細(xì)描述，如果存在可用的附加信息，使得對于提供特定的媒體類型的用戶該媒體類型不被允許或授權(quán)，則對于用戶終端的響應(yīng)可以還包含指示所述附加信息的其它原因，例如用戶未被授權(quán)將所述々某體類型添加到所述會話。在此情況下，用戶終端可以被配置為，推斷再次提供被拒絕的4某體是不合理的，因為其未被授權(quán)這樣做。換句話說，在所述響應(yīng)中可以包括一個或更多關(guān)于所述媒體類型的拒絕的原因。
圖7是示出根據(jù)本發(fā)明實施例的拒絕原因的指示可以怎樣被利用的信令圖，盡管用于建立會話的請求不包^*體提供。在圖7的示例中，假設(shè)會話已存在，并且正想要建立該會話的用戶終端被允許加入該會話。
通過參考圖7，用戶終端UT想要建立會話，并且發(fā)送用于會話建立的請求7-1。在所示的示例中，所述請求不包含々某體提供，并且其可以是發(fā)送到主持所述會話或為所述用戶終端提供會話通信的服務(wù)器的URI的SIP INVITE。響應(yīng)于該請求，所述服務(wù)器在點7-2檢測到所述^S舌已存在，并且因此在點7-3向指示所述請求的接受的響應(yīng)添加拒絕原因的指示，并且發(fā)送該響應(yīng)7-4。該響應(yīng)可以是SIP 200 OK,并且該指示可以是任何以上描述的拒絕原因的指示。
所述用戶終端在點7-5檢測到其接收到帶有拒絕原因的指示的接受，并且在點7-6推斷，所述接受是指示所述會話建立已被轉(zhuǎn)換為加入所述會話的部分接受，即所述會話已存在，并且在點7-7通知用戶該用戶正在加入現(xiàn)存會話。
假設(shè)他/她正在建立會話但實際上正在加入現(xiàn)存會話的用戶接收關(guān)于所述會話已存在的信息的優(yōu)點是，該用戶知道在何處與所述通信一致，即精神上準(zhǔn)備好是正在進(jìn)行的通信的一部分?，F(xiàn)有技術(shù)的解決方案缺乏為用戶提供此種信息的機制。
以上在圖4到7中描述的步驟/點、信令消息和相關(guān)功能不是按絕對的
時序順序，并且所述步驟/點中的一些可以#:同時或按照不同于所給出的順序來實施。其它功能也可以在所述步驟/點之間或在所述步驟/點內(nèi)被執(zhí)行，并且其它信令消息在所示的消息之間被發(fā)送。所述步驟/點中的一些或所述步驟/點的 一部分可以被省略，或被對應(yīng)步驟/點或所述步驟/點的 一部分代替。所述服務(wù)器操作和用戶終端操作示出了可以在一個或更多物理或邏輯實體中凈皮實現(xiàn)的過程。所述信令消息僅是示例性的，并且甚至可以包括用于發(fā)送相同信息的若干單獨的消息。另外，所述消息還可以包含其它信息。對于本領(lǐng)域的技術(shù)人員將顯而易見，隨著技術(shù)進(jìn)步，本發(fā)明概念可以用各種方式來實現(xiàn)。本發(fā)明及其實施例不限于以上描述的示例，而可以在權(quán)利要求的范圍內(nèi)改變。
權(quán)利要求
1. 一種方法，包括發(fā)送關(guān)于會話的請求，所述請求提供用于所述會話的一個或多個媒體類型；以及接收對所述請求的響應(yīng)，所述響應(yīng)指示至少一個被拒絕的媒體類型以及拒絕原因的指示。
2. 根據(jù)權(quán)利要求l所述的方法，所述方法進(jìn)一步包括 基于所述響應(yīng)確定所述拒絕原因。
3. 根據(jù)權(quán)利要求1或2所述的方法，其中，所述請求是會話建立請求。
4. 根據(jù)權(quán)利要求l、 2或3所述的方法，進(jìn)一步包括
5. —種方法，包括接收關(guān)于會話的請求，所述請求提供用于所述會話的一個或多個媒體 類型；響應(yīng)于被提供的媒體類型被拒絕，向?qū)λ稣埱蟮捻憫?yīng)添加拒絕原因 的指示；以及發(fā)送所述響應(yīng)。
6. 根據(jù)前述權(quán)利要求中任一個所述的方法，其中，所述原因包括以下 組中的一個，所述組包括現(xiàn)存會話、參與者拒絕和基于策略的拒絕。
7. 根據(jù)權(quán)利要求5或6所述的方法，進(jìn)一步包括 注意到所述請求是對于現(xiàn)存會話的M建立請求；將被提供的 一個或多個々某體類型與所協(xié)商的用于所述會話的 一個或多 個媒體類型比較；以及如果被提供的媒體類型不是所協(xié)商的媒體類型，則拒絕被提供的媒體 類型并指示所述原因是現(xiàn)存會話。
8. 根據(jù)權(quán)利要求5或6所述的方法，進(jìn)一步包括 注意到所述請求是用于現(xiàn)存會話的會話建立請求；將被提供的 一個或多個媒體類型轉(zhuǎn)發(fā)到所述會話的其它參與者； 接收來自所述其它參與者的確認(rèn)；以及如果被提供的媒體類型未被參與者接受，則拒絕該被提供的媒體類型， 并指示拒絕原因。
9. 根據(jù)權(quán)利要求8所述的方法，進(jìn)一步包括將所述被提供的一個或多個媒體類型與所協(xié)商的用于所述會話的一個 或多個媒體類型比較；以及轉(zhuǎn)發(fā)不是所協(xié)商的媒體類型的被提供的媒體類型。
10. —種方法，包括 接收會話建立請求； 檢測所述會話已存在；以及 向?qū)λ稣埱蟮捻憫?yīng)添加所述會話已存在的指示。
11. 一種方法，包括 請求會話建立；以及 接收指示所述會話已存在的響應(yīng)。
12. 根據(jù)前述權(quán)利要求中任一個所述的方法，其中，所述響應(yīng)指示所 述請求的接受。
13. 根據(jù)前述權(quán)利要求中任一個所述的方法，其中，所述指示是包括 三位文本代碼和解釋文本的告警^t艮頭。
14. 一種模塊，被配置為，響應(yīng)于拒絕被提供在請求中的媒體類型，消息。
15. 根據(jù)權(quán)利要求14所述的模塊，其中，所述消息是肯定地確認(rèn)所述 請求的會話發(fā)起協(xié)議響應(yīng)消息，并且所述模塊被配置為，將所述指示作為 文本串添加到告警報頭。
16. —種模塊，被配置為實施根據(jù)權(quán)利要求1至12中任一個所述的方法。
17. 根據(jù)權(quán)利要求14、 15或16所述的模塊，所述模塊是操作處理器。
18. —種設(shè)備，包括用于實施根據(jù)權(quán)利要求1至12中任一個所述的方 法的裝置。
19. 一種設(shè)備，包括一個或多個根據(jù)權(quán)利要求14、 15、 16或17所述 的模塊。
20. —種設(shè)備，包括 接收單元，被配置為接收響應(yīng)；應(yīng)用客戶端單元，被配置為形成關(guān)于會話的請求，所述請求提供用于 所述會話的一個或多個媒體類型，以及響應(yīng)于所述接收單元接收對所述請 求的響應(yīng)，所述響應(yīng)指示至少一個被拒絕的媒體類型以及拒絕原因的指示； 以及發(fā)送單元，-故配置為響應(yīng)于所述應(yīng)用客戶端單元而發(fā)送所述請求。
21. 根據(jù)權(quán)利要求20所述的設(shè)備，其中所述應(yīng)用客戶端單元被進(jìn)一步 配置為，基于所述指示確定所述原因，以及使用所述原因推斷是否稍后嘗 試提供用于所述會話的所述媒體類型。
22. 根據(jù)權(quán)利要求20或21所述的設(shè)備，其中所述應(yīng)用客戶端單元是 包括以下的組中的一個中央處理單元、操作處理器、可通過操作處理器 來執(zhí)行的軟件應(yīng)用以及用于形成所述請求和接收所述響應(yīng)的裝置。
23. —種設(shè)備，包括 接收單元，被配置為接收請求；應(yīng)用主機單元，被配置為響應(yīng)于所述接收單元接收到關(guān)于會話的請求， 其中，形成對所述請求的響應(yīng)，所述請求提供用于所述會話的一個或多個 媒體類型，響應(yīng)于所提供的媒體類型被拒絕而添加拒絕原因的指示；以及發(fā)送單元，被配置為響應(yīng)于所述應(yīng)用主機單元，發(fā)送所述響應(yīng)。
24. 根據(jù)權(quán)利要求23所述的設(shè)備，其中所述應(yīng)用主機單元被進(jìn)一步配 置為注意到所述請求是關(guān)于現(xiàn)存會話的會話建立請求；將所述被提供的 一個或多個媒體類型與所協(xié)商的用于所述會話的一個或多個媒體類型比 較；以及響應(yīng)于被提供的媒體類型不是所協(xié)商的媒體類型，拒絕該被提供 的媒體類型并指示所述原因是現(xiàn)存會話。
25. 根據(jù)權(quán)利要求23所述的設(shè)備，其中所述應(yīng)用主機單元被進(jìn)一步配 置為注意到所述請求是關(guān)于現(xiàn)存會話的務(wù)活建立請求；經(jīng)由所述發(fā)送單 元將所述被提供的一個或多個媒體類型轉(zhuǎn)發(fā)到所述會話的其它參與者；以 及響應(yīng)于參與者不接受被提供的媒體類型，拒絕該被提供的媒體類型并指 示拒絕原因；以及所述接收單元被進(jìn)一步配置為接收來自所述其它參與者的確認(rèn)，所述 確認(rèn)指示被提供的媒體類型是否被參與者接受。
26. 根據(jù)權(quán)利要求25所述的設(shè)備，其中所述應(yīng)用主機單元被進(jìn)一步配 置為將所述被提供的一個或多個々某體類型與所協(xié)商的用于所述會話的一個 或多個媒體類型比較；以及轉(zhuǎn)發(fā)不是所協(xié)商的媒體類型的被提供的媒體類 型。
27. 根據(jù)權(quán)利要求23、 24、 25或26所述的設(shè)備，其中所述應(yīng)用主機 單元是包括以下的組中的一個中央處理單元、操作處理器、可通過操作 處理器執(zhí)行的軟件應(yīng)用以及用于形成所述請求和接收所述響應(yīng)的裝置。
28. —種系統(tǒng)，包括一個或多個根據(jù)權(quán)利要求18、 19、 20、 21、 22、 23、 24、 25或26所述的設(shè)備和/或一個或多個根據(jù)權(quán)利要求14、 15、 16 或17所述的模塊。
29. —種計算機程序，包括當(dāng)所述程序在計算機或微處理器上運行時 適于實施根據(jù)權(quán)利要求1至12中任一個所述的任何步驟的程序代碼裝置。
全文摘要
一種盡管會話已存在還請求會話建立的用戶終端，在對所述請求的響應(yīng)中被通知所述現(xiàn)存會話。如果所述用戶終端在所述請求中提供了一個或多個被拒絕的媒體類型，則所述響應(yīng)包含拒絕原因的指示。
文檔編號H04L29/06GK101536458SQ200780040956
公開日2009年9月16日 申請日期2007年10月30日 優(yōu)先權(quán)日2006年11月3日
發(fā)明者P·庫雷, T·帕沃寧 申請人:諾基亞公司