在分布式環境中處理消息內容的內容部署系統和方法

2023-05-21 16:58:56

專利名稱：在分布式環境中處理消息內容的內容部署系統和方法
技術領域：
本專利公開總體涉及通信網絡中的消息處理。更具體且沒有任何限制地，本專利 公開涉及用於在分布式環境(例如，包括網際網路協議(IP)多媒體子系統(IMS)網絡在內的 網絡環境)下處理消息體的內容部署系統和方法。
背景技術：
在描述與通信協議中實現的消息相關的信息的過程中使用標記語言。在不同實體 使用可擴展的標記語言形式的消息體來彼此通信的網絡環境中，語言以及任何用於理解語 言的元結構在環境中兼容變得重要。否則，可能發生例如導致通信失敗、不可預測的行為等 等的顯著的互操作性問題。


參考結合附圖而進行的以下詳細描述，可以更完整地理解本專利公開的實施例， 附圖中圖1示出了可以實施本專利公開的一個或多個實施例的示例分布式網絡環境；圖2示出了根據實施例的用戶設備(UE)設備的框圖；圖3示出了根據一個實施例的網絡節點的框圖4示出了在示例分布式網絡環境中處理通信協議消息的實體處採用的軟體架 構的實施例，其中，通信協議消息可以包括多種版本的消息體或文檔；圖5A示出了具有一個初始行、一個或多個首部欄位以及消息體的示例通信協議 消息(例如，會話發起協議(SIP)消息)的結構，其中，消息體可能包括多個主體部分；圖5B和5C示出了分布式環境中兩個實體之間的示例消息流，其中，發送具有消息 體的通信協議消息；圖5D示出了用於驗證作為通信協議消息中的消息體而提供的可擴展標記語言 (XML)文檔的不同模式的示例集合。圖6A示出了對與通信協議的消息體相關的模式和文檔版本信息進行協商的方法 的實施例；圖6B示出了對與通信協議的消息體相關的模式和文檔版本信息進行協商的方法 的另一實施例；圖6C示出了對與通信協議的消息體相關的模式和文檔版本信息進行協商的方法 的另一實施例；圖6D示出了對與通信協議的消息體相關的模式和文檔版本信息進行協商的方法 的另一實施例；圖7示出了涉及對版本化的消息體(或主體部分)的驗證的消息處理方法的實施 例；圖8示出了根據本公開的實施例的涉及多個實體的示例消息流程圖，其中，中間 節點用於對關於上遊和下遊實體的模式信息進行協商；圖9示出了根據本公開的實施例的電信服務(緊急服務)的示例實施方式；圖IOA至IOC示出了與用於處理和/或解釋消息體的內容的內容部署方案相關的 各個實施例；以及圖11是示出了用於本專利公開目的的通信設備的實施例的附加細節的框圖。
具體實施例方式本專利公開概括地涉及一種用於在分布式環境中處理消息內容的內容部署系統 和方法，其中，所述消息內容可以在通信協議的一個或多個版本化的消息體或主體部分中 提供。在本專利申請的上下文中，「消息」或「消息體」可以指代一個或多個消息體，該一個 或多個消息體可以進而等價於一個或多個主體部分。在一方面，實施例涉及一種針對每個 消息解釋至少一個消息體的內容的方法，其中，所述內容與內容類型相對應。要求保護的實 施例包括以下一個或多個並且不必限於此接收方從發送方接收消息，所述消息在所述消 息的主體中包括至少一個消息體內容；檢查是否至少一個指示符與所述消息相關聯；以及 響應於該檢查，禁止對所述消息的主體中的所述至少一個消息體內容的處理並對所述消息 的主體中的所述至少一個消息體內容應用備選處理。在本專利公開的另一實施例中，公開了一種用於針對每個消息解釋至少一個消息 體的內容的設備，其中，所述內容與內容類型相對應。要求保護的實施例包括以下一個或多 個並且不必限於此被配置為從發送方接收消息的、與接收方相關聯的組件，所述消息在所 述消息的主體中包括至少一個消息體內容；被配置為檢查是否至少一個指示符與所述消息
6相關聯的組件；以及響應於該檢查而被配置為禁止對所述消息的主體中的所述至少一個消 息體內容的處理並對所述消息的主體中的所述至少一個消息體內容應用備選處理的組件。在特定的其他方面，本專利公開還公開了以下附加實施例。提供了一種用於處理 通信協議的消息體的方法，其中，所述消息體可以以一種或多種版本存在。要求保護的實施 例包括以下一個或多個特徵並且不必限於此接收方從發送方接收通信協議消息，所述通 信協議消息包括消息體；檢查與所述通信協議消息相關聯的指示符(例如，內容部署指示 符或內容類型指示符)(即，是否存在指示符，如果存在，則檢查其可能具有的值等等)；以 及響應於該檢查，禁止對所述消息體的呈現並對所述消息體的內容調用備選處理。在另一 實施例中，公開了一種便於處理通信協議的消息體的方法，其中，所述消息體可以以一種或 多種版本存在。要求保護的實施例包括以下一個或多個特徵並且不必限於此發送方向接 收方產生通信協議消息，所述通信協議消息包括消息體；以及在所述通信協議消息中提供 指示符，以向接收方指示對所述消息體的內容的過程處理。在另一實施例中，公開了一種 便於處理通信協議的消息體的設備，其中，所述消息體可以以一種或多種版本存在。要求保 護的設備包括以下一個或多個特徵並且不必限於此被配置為向接收方產生通信協議消息 的、與發送方相關聯的組件，所述通信協議消息包括消息體；以及被配置為在所述通信協議 消息中提供內容部署指示符以向接收方指示對所述消息體的內容的過程處理的、與所述發 送方相關聯的組件。在如上所述的一個或多個實施例中，所述內容部署指示符在一種實施 方式中可操作用於對涉及解釋和/或執行在所述通信協議消息中提供的指令集合的過程 處理進行標識。在另一種實施方式中，所述內容部署指示符可操作用於對涉及解釋和/或 執行在所述通信協議消息中提供的腳本的過程處理進行標識。在附加實施方式中，所述內 容部署指示符可操作用於對用於處理所述消息體的內容的標準主體規範、功能和/或應用 進行標識，其中，所述內容部署指示符可以在所述通信協議消息的首部欄位或主體中提供。本專利公開中的術語「文檔」可以根據其上下文來表示以下之一文檔可以是SIP 消息(其可以是請求或響應)的主體，或者文檔可以是SIP消息(請求或響應)的主體部 分(如果主體包含多個部分的話)，或者文檔可以是XML模式(schema)文檔，或者文檔可以 是XML實例文檔(典型地，一個或多個XML模式文檔的實例)。術語「模式版本指示符」可 以指示以下內容(i)無或者一個或多個被接收方支持的文檔集合，或者，無或者一個或多 個其中元素是所發送文檔的文檔集合；或者(ii)無或者一個或多個被接收方支持的模式， 或者，無或者一個或多個可藉以驗證所發送文檔的模式；或者(iii)上述內容的組合。現在，將參照可以如何最佳地作出並使用實施例的各個示例來描述本專利公開的 系統和方法。貫穿說明書以及附圖的多個視圖，使用類似的參考標記來指示類似或對應的 部分，其中，各個元件不必按比例示出。現在參照附圖，更具體地，參照圖1，示出了示例分布 式環境100，其中，可以實施本專利公開的一個或多個實施例，以管理針對消息體的模式版 本協商。起初，應當認識到，儘管分布式環境100被示例為電信網絡，但本公開的實施例不 必限於此；而是可以在其他分布式多節點環境中實施實施例的一個或多個方面，其中，實體 或節點在具有版本化的消息體和消息體類型的合適通信協議下彼此通信。如圖所示，網絡環境100包括多個實體或節點，即，端點以及其間的實體中間點， 以實現各種電信服務。示例端點包括用戶設備(UE)設備102、104，分別通過合適的接入 網108、110耦合至核心網基礎設施112。接入網108、110可以共同被視為由可用於UE設備102、104的多種接入技術組成的接入空間。為了本公開的目的，UE設備可以是任何有 線或無線通信設備，並可以包括配備有合適無線數據機的任何個人計算機(例如，臺 式、膝上、掌上或手持計算設備)；或者移動通信設備(例如，能夠接收和發送消息、進行web 瀏覽等的蜂窩電話或具有數據能力的手持設備)；或者任何增強型PDA設備或集成信息裝 置，具有電子郵件、視頻郵件、網際網路接入、公司數據接入、消息收發、日程安排和時間安排、 信息管理等能力。在一個實施例中，UE設備可能能夠在多種模式中操作，這是由於其可以 參與電路交換(CS)以及分組交換(PS)通信並可以從一種通信模式轉換至另一種通信模式 而不失連續性。此外，本領域技術人員將認識到，無線UE設備有時可以被視為單獨的移動 設備(ME)和相關聯的可移除存儲模塊的組合。相應地，為了本公開的目的，在適用時，術語 「無線設備」和「UE設備」(概括地講是同義的)均被視為單獨表示ME設備以及表示ME設 備與可移除存儲模塊的組合。包括接入網108、110在內的接入空間可以包括CS網絡、PS網絡或兩者都包括，其 可以涉及無線技術、有線技術、寬帶接入技術等。例如，無線技術可以包括全球移動通信系 統(GSM)網絡和碼分多址(CDMA)網絡以及任何符合第3代合作夥伴計劃(3GPP)的蜂窩網 絡(例如，3GPP或3GPP2)。寬帶接入網可以包括無線區域網或WLAN、Wi_MAX網絡以及固定 網絡，如數字訂戶線路(DSL)、線纜寬帶等等。因此，為了本公開的目的，接入技術可以包括 從 IEEE 802. Ila 技術、IEEE 802. Ilb 技術、IEEE 802. Ilg 技術、IEEE 802. Iln 技術、GSM/ EDGE無線接入網(GERAN)技術(CS域和PS域)和通用移動電信系統(UMTS)技術以及演 進-數據優化(EVDO)技術及其後繼者(如長期演進(LTE))等等中選擇的無線接入技術。 此外，在一些實施方式中，接入網108、110還可以包括傳統有線PSTN基礎設施。網絡基礎設施112可以包括IP多媒體子系統(IMS)核心層以及服務/應用層。 眾所周知，IMS核心由3GPP團體所提出的標準來定義，該標準被設計為允許服務提供商管 理經由任何網絡類型上的IP而傳送的多種服務，其中，IP用於傳輸承載業務量和基於會話 發起協議(SIP)的信令業務量。概括地講，IMS是用於管理應用(即，服務)和網絡(即， 接入)的能夠提供多媒體服務的框架。IMS將「應用伺服器」定義為傳送服務訂戶使用(例 如，語音呼叫連續性(VCC)、一鍵通(PTT)、蜂窩一鍵通(PoC)或其他IMS集中式服務(ICS)服務等)的網絡單元。IMS 通過定義每個應用伺服器(AS)(例如AS-I 120-1至AS-N 120-N)需要具有的公共控制組 件(例如，訂戶簡檔、IMS移動性、網絡接入、認證、服務授權、收費和記帳、互操作器功能以 及與傳統電話網的互操作)來管理應用。應當理解，IMS由主要處理GSM網絡的3GPP標準團體來定義，而另一個組3GPP2 涉及定義被稱作多媒體域(MMD)的非常類似的架構。MMD基本上是CDMA網絡的IMS，並且， 由於MMD和IMS大致等價，因此在適用時，可以在本專利公開中使用術語「IMS」來共同指代 IMS和MMD。此外，基於和/或重用IMS的NGN(下一代網絡)的固定網絡標準也由如ETSI TISPAN、Cablelabs和ITU-T之類的團體來開發。NGN和IMS大致等價，相應地，在適用時， 也可以在本專利公開中使用術語「IMS」來共同指代IMS和NGN。繼續參照圖1，參考標記106指代包括核心基礎設施在內的一個或多個網絡節 點。作為示意，網絡節點106可以作為代理呼叫會話控制功能(P-CSCF)節點、服務CSCF或 S-CSCF節點、詢問CSCF或I-CSCF節點、中斷網關控制功能(BGCF)節點、互連邊界控制功能(IBCF)節點、媒體網關控制功能(MGCF)節點、歸屬訂戶伺服器(HSS)節點等等的示例。如 前所述，這些節點以及端點UE設備採用SIP作為通信協議用於會話控制，即，建立和拆除通 信會話。相應地，網絡節點和UE設備可以共同被稱作「SIP實體」，或更一般地稱作「通信協 議實體」，其參與發送和接收合適的通信協議消息(例如SIP消息)以實現各種服務，例如 VCC, PTT、PoC、緊急服務等等。典型地，每個SIP實體配備有可採用以下兩種方式操作的用戶代理(UA) (i)用戶 代理客戶端(UAC)，向伺服器產生請求消息；以及(ii)用戶代理伺服器(UAC)，接收請求消 息、處理請求消息並產生合適響應。在一些應用場景中，單個UA可以在SIP實體(例如UE 設備或網絡節點)處充當這兩者。在最基本的形式下，SIP使用六種類型(方法)的請求· INVITE 指示用戶或服務正被邀請參與呼叫會話；· ACK 確認客戶端已接收到對INVITE請求的最終響應；· BYE 終止會話/呼叫並可以由主叫者或被叫者發送；· CANCEL 取消任何未決的搜索但不終止當前進行的呼叫/會話；· OPTIONS 詢問伺服器的能力；· REGISTER 將To 首部欄位中列出的地址註冊至SIP伺服器。隨著SIP可能繼續演進，接收方可能接收其無法識別的請求方法。這樣的請求方 法被作為UNKNOWN請求方法而處理。響應於請求，SIP使用以下類別的響應· Ixx信息消息；·2χχ成功響應；·3χχ重定向響應；· 4χχ請求失敗響應；· 5χχ伺服器失敗響應；· 6χχ通用失敗響應。典型地，SIP消息具有標準化消息結構。圖5Α示出了具有一個初始行、一個或多 個首部欄位以及消息體的示例通信協議消息(例如，會話發起協議(SIP)消息)的結構， 其中，消息體可能包括多個主體部分。命令行部分502標識初始行(例如，請求中的請求 行和響應中的狀態行)。首部部分504標識傳遞各個信息的一個或多個首部欄位508-1 至508-Ν。可以在消息體部分506中提供一個或多個消息體510-1至510-Ν。眾所周知， 消息體可操作用於保存任何內容，例如明文、編碼圖像或可採用例如標記語言(如XML、 HTML等)呈現的任何信息。使用提供與其內容有關的信息的首部欄位(例如但不限於 Content-Disposition (內容部署)、Content—Encoding (內容編碼)禾口 Content—Type (內 容類型)等)來描述每個消息體(或主體部分)。典型地，Content-Type首部欄位的值是 多用途網際網路郵件擴展(MIME)類型。此外，如果使用標記語言來描述消息內容，則這種消 息體還可以稱作文檔。這種文檔與模式文檔相符合。每個模式可以產生一個或多個文檔實 例或者文檔或示例。由於標記語言的可擴展性，如果模式文檔演進，則該模式可能產生附加 的甚至不同的文檔實例集合。可以利用令牌來標識由各種(演進)模式文檔產生的、具有 實例文檔的集合。在一個實施例中，可以利用與用於標識演進模式文檔的令牌相同的令牌 來標識具有實例文檔的集合。在另一實施例中，該令牌可以是數位、小數、URN名字空間或 字符串。在另一實施例中，可以利用令牌來標識具有模式文檔的集合。在另一實施例中，可
9以利用令牌來標識具有實例文檔的集合。 包括在通信網絡(例如圖1所示的網絡100)中實現的通信服務的會話控制應用 在內的基於SIP的應用越來越多地依賴於XML文檔來交換數據和/或其他信息。一般地，各 個SIP實體可以使用XML文檔作為公共數據交換語言來彼此通信，以實現通信會話、商家對 商家(B2B)和商家對客戶(B2C)應用等。此外，如web伺服器、小服務程序、web應用、web 服務等技術也一般以某種方式依賴於根據XML規範而組織的數據。
XML是標準化通用標記語言(SGML)族的子集並由W3協會進行標準化。由此，XML 是其中實體可包含一個或多個元素的實體層級集合。每個元素包括開啟標記或標籤、文本 以及關閉標記或標籤。典型地，元素還包含一個或多個屬性，所述屬性操作用於修改元素 中包含的信息。作為對在節點之間傳遞的信息或數據進行描述的描述性語言，XML具有特 定的語法規則，例如(i)XML文檔必須具有根元素；(ii)XML元素必須具有關閉標籤；(iii) XML標籤是區分大小寫的；(iv)XML元素必須被適當地嵌套和/或排序；(V)XML屬性值必須 被引用等等。具有正確語法的XML文件被稱作「合式(well formed)」 XML文件。由於可擴 展性(允許任何作者定義他們自己的應用專用元素、屬性等)，XML文檔可以以多種變型存 在，但接收方仍可以僅被配置為使用以各種可能變型存在的元素和屬性的子集。為了便於 多個節點之間的文檔兼容，在交易節點處實現了與特定文檔類型相關的特定元級別結構或 「模式」。可以指示用於定義可能的XML實例文檔的集合的各種元級別結構或「模式」。交易 節點中的發送節點可以使用該指示符來標識由XML實例文檔作為成員的集合。交易節點中 的接收節點可以使用該指示符來標識可以在語義上和/或語法上對其已知要處理的XML文 檔集合的接收元素進行處理的另一組件(例如，消息體部分(或主體部分)專用層)。因此，XML模式可以被認為是在對應XML文檔中可接受的結構、組織和數據類型的 定義。XML模式還定義了 XML元素的集合、XML元素屬性和所期望的XML元素間的組織，從而 XML模式充當XML元素的詞彙。此外，由於模式自身基於XML，因此模式還可以被擴展並可以 以多種版本存在。由於可擴展性(允許任何作者定義他們自己的應用專用元素、屬性等)， 使用相同標識符或媒體類型而標識的XML模式文檔可以以多種變型存在。為了便於多個節 點之間的文檔兼容，在交易節點處實現了與特定文檔類型相關的公共/特定元級別結構或 「模式」。在一些XML實施方式中，可以提供文檔類型定義(DTD)、XML模式、NGRelax或文檔 內容定義(DCD)或其他XML模式，以對XML文件的元結構定義規則集合。另一種實施方式 是提供DTD的基於XML的備選(即，XML模式)，例如，XML模式、NGRelax或其他。XML模式 語言有時也被稱作XML模式定義(XSD)。應用XML模式的組件使用其來典型地驗證XML文 檔。相應地，「有效的」文檔是也符合被交易節點所支持的XML模式的規則的「合式」文檔。關於IMS網絡環境中的SIP消息，可應用的標準(例如，3GPP TS24. 229 「 IP multimedia call control protocol based on Session Initiation Protocol (SIP)and Session Description Protocol (SDP) 」 ；Stage 3 (Release8))規定與 XML 消息體相關聯 的MIME類型是「application/3gpp-ims+xml」。該標準還規定如在任何SIP消息中可能 需要的，SIP UA或代理可以插入或移除XML消息體或其部分。相應地，SIP消息中的XML主 體或文檔可以根據具有不同版本的XML模式而存在。典型地，接收方還需要用於產生主體 或主體部分的XML模式(或兼容版本)，以驗證主體或主體部分。否則，如本專利公開的背 景技術部分所述，無效的XML文檔可能對所請求的電信服務導致不可預測的行為或錯誤結果。此外，如果由於缺少兼容性(前向或後向)而使得發送方的XML消息體未被接收方的 驗證器所接受，則在通信環境中可能發生顯著的互操作性問題。現在參照圖2，其中示出了根據實施例可操作為能夠對XML消息體進行交易的SIP 實體的UE設備200的框圖。提供了一個或多個處理實體202以對設備上可執行的各種過程 進行總體控制。用戶代理204可操作為關於如SIP過程之類的通信協議過程的UAS或UAC。 參考標記206指代示例協議過程模塊。驗證器208可操作用於驗證例如在SIP消息體中接 收到的XML文檔。驗證器208還可以用於產生特定版本的XML文檔並可能在文檔中包括文 檔版本。應用210可操作用於基於XML消息文檔的內容來執行或調用合適軟體。還可以針 對消息解析，提供字典和解析器212。包括可以與可應用的協議過程結合進行操作的消息產 生器214，消息產生器214還能夠在如下所述向另一 SIP實體產生的通信協議消息中提供指 示符，例如模式版本指示符。圖3示出了根據實施例可操作為能夠對XML消息體進行交易的SIP實體的網絡節 點300的框圖。作為示意，網絡節點300的實施例作為如上所述的任何IMS基礎設施實體的 示例。提供了一個或多個處理實體304以對由網絡節點306執行的各種過程進行總體控制， 不論網絡節點306的架構或代理功能性如何。合適的發送/接收(Tx/Rx)塊302可操作用 於發送或接收在消息體中具有XML文檔的各種通信協議消息。背對背用戶代理(B2BUA)310 可操作為關於如SIP過程之類的通信協議過程312的UAS或UAC。驗證器314可操作用於 驗證例如在來自發送方的SIP消息體中接收到的XML文檔，或能夠產生一個或多個版本的 XML文檔，並可能在文檔中包括文檔版本。應用320可操作用於基於XML消息文檔的內容來 執行或調用合適軟體。還可以針對消息解析，提供字典和解析器316。包括可以與可應用 的協議過程結合進行操作的消息產生器318，消息產生器318還能夠在如下所述向另一 SIP 實體產生的通信協議消息中提供指示符(例如模式版本指示符)。提供了附加硬體306和 本地存儲器308，以便於與潛在地沿通信路徑的上遊和下遊方向管理和協商消息流中的模 式/文檔版本信息相關的其他功能。圖4示出了在示例分布式網絡環境中用於處理通信協議消息的實體(UE設備 200或網絡節點300)處採用的軟體架構400的實施例，其中，通信協議消息可以包括多 種版本的消息文檔。在從發送方接收到通信協議消息時，合適的通信協議層402控制對 接收到的消息的處理。在確定了接收到的消息是根據通信協議架構的適當消息(例如， 命令行、首部欄位等的有效性)之後，執行消息體(或主體部分)專用層404(例如，基於 Content-Disposition 欄位的值、Content-Type 的預設 Content-Disposition、在特定實體 上接收時Content-Type的預設Content-Disposition)。例如，如果消息體(或主體部分) 專用層是考慮了合式性的XML層，則可以執行驗證。如果在該階段有差錯，則該處理可以在 有報警或沒有報警的情況下得體地停止，或可以根據在消息自身或在先配置中提供的任何 指示來採取備選動作過程。此後，執行應用專用層406。圖5B和5C示出了在分布式網絡環境中兩個實體之間的示例消息流，其中，可以發 送具有版本化的消息體(和/或根據版本化的模式)的通信協議消息。具體地，圖5B中的 參考標記500B指代關於特定服務的兩個網絡節點(例如服務CSCF節點522和AS節點524) 之間的消息流。針對SIP方法的請求526以SIP REGISTER消息作為示例，該SIP REGISTER 消息包括可包含根據MIME類型「applicati0n/3gpp-imS+xml」的版本化XML文檔在內的消
11息體，其中，MIME類型(表示XML文檔)可以具有傳遞可用於驗證XML文檔的XML模式的參 數。圖5C中的參考標記500C指代端點(例如UE設備)550與網絡節點(如代理CSCF節 點)556之間的消息流。為了本專利公開的目的，「SIP消息」可以根據上下文表示請求消息 或響應消息。SIP INVITE請求消息作為請求552的示例，請求552包括緊急服務標識符， 用於指示UE設備550預期在IMS網絡上發起緊急服務呼叫。來自P-CSCF 556的SIP響應 554可以包括SIP 380(備選服務)響應，該SIP 380響應包括消息體。本領域技術人員可 以認識到，在這兩個消息流場景中，如果消息的接收方根據與接收方所支持的消息體集合 不兼容的或不能被接收方的驗證器驗證的模式(例如，由於缺少必需的模式)來接收消息 體集合的消息體文檔部分，則將損害服務行為，導致非預期或錯誤的結果。圖5D示出了用於驗證文檔的不同模式。參考標記572-1至572-3作為三個文檔 的示例，其中，每個文檔是相同類型的單獨模式，例如，MIME或內容類型文檔572-1包含 版本X的模式；文檔572-2包含版本Y的模式；以及文檔572-3包含版本Z的模式。實例 文檔——包含模式的文檔(例如XML模式文檔)的實例(例如XML文檔)——還可以根據 產生模式文檔的單個MIME類型X、Y或Z來指示模式文檔的版本。每個實例文檔是具有由 特定版本的單個模式文檔產生的一個或多個實例文檔的集合的一部分。實例文檔——包含 模式的文檔(例如XML模式文檔)的實例(例如XML文檔)——還可以根據產生模式文檔 的單個MIME類型X、Y或Z來指示模式文檔的版本。每個實例文檔是具有由特定版本的單 個模式文檔產生的一個或多個實例文檔的集合的一部分。包括版本指示符「X」的實例文檔 (即，XML文檔實例574-1至574-N)可以最低限度地由模式文檔572-1適當驗證。同樣，版 本Y的文檔的實例(即，文檔實例576-1至576-M)可以由模式文檔572-2適當驗證。版本 Z的文檔的示例為可以由模式文檔572-3驗證的單個實例578。包括版本指示符「Y」的實 例文檔也可以被示例為實例文檔576-M和模式文檔572-1的其他模式文檔接受和驗證。圖6A示出了對與通信協議的消息體相關的模式版本信息進行協商的方法的實施 例600A。發送方向接收方產生通信協議消息(例如SIP請求或SIP響應)(框602)。在一 種變型中，通信協議消息可以包括合適的消息體(或主體部分)。通信協議消息還包括模式 版本指示符(例如在Accept (接受)首部或首部欄位中)，或包括充足的信息以指示發送方 可以驗證和接受(i)特定內容類型的消息體/主體部分的哪個集合或(ii)特定內容類型 的哪些文檔，以用於處理(框604)。在一種變型中，接收方可以將缺少模式版本指示符解釋為指示發送方可以驗證和 接受特定內容類型的消息體(部分)內容或文檔的預設集合。在產生初始INVITE請求時， UE設備可操作用於通過包括如3GPP TS 24. 229的子條款7. 6. 1中定義的其MME類型，來 指示其對Acc印t首部欄位中的3GPP IMS XML主體的支持。可選地，可以添加名為「sv」或 「schemaversion」的版本參數，以指示所支持的IM CN子系統XML主體的XML模式的版本。可 以在本文中其他地方找到schemaversion參數的語法。如果缺少「sv」或「schemaversion」 參數，則應假定UE支持IM CN子系統XML主體的XML模式的版本1。如果沒有指示對Accept 首部欄位中的3GPP IMS XML主體的支持，則應假定UE支持IM CN子系統XML主體的XML 模式的版本1。圖6B示出了對與通信協議的消息體相關的模式版本信息進行協商的方法的另一 實施例600B。接收方從發送方接收通信協議消息(如SIP請求或SIP響應消息)(框610)。在一種變型中，通信協議消息可以包括合適的消息體(或主體部分)。響應於接收到的通 信協議消息，接收方向發送方產生響應消息，其中，響應消息包括文檔/模式版本指示符、 一個或多個消息體(或主體部分)、與主體部分相關聯的類型，以指示(i)主體或部分是特 定類型的消息體/主體部分內容的哪些集合的成員或(ii)可用於驗證消息體(或主體部 分)的特定類型的XML模式文檔的版本(框612)。此外，發送方可以使用指示符來標識可 用於處理信息的應用層組件。圖6C中闡述了對與通信協議消息的消息體(或主體部分)相關的模式版本信息 進行指示的方法的另一實施例600C。發送方向接收方產生通信協議消息(如SIP請求或 SIP響應)。通信協議消息還包括一個或多個消息體(或部分)、與消息體相關聯的類型、模 式版本指示符(例如在Content-Type首部欄位中)，以指示(i)主體(部分)是特定類型 消息體(部分)內容的哪些集合的成員，或(ii)特定類型的XML模式文檔的哪些版本可用 於驗證消息體(部分)(框622)。此外，接收方可以使用指示符來標識可用於處理信息的應 用層組件。本領域技術人員將認識到，可以以一個或多個組合來混合併實現上述實施例的方 面。此外，應當認識到，在實體之間進行協商過程並且調用服務的意義上，動態執行上述協 商方法。作為另一備選，圖6D示出了對與通信協議的消息體相關的模式版本信息進行協商 的方法的實施例600D，其中，可以採用查找方案。潛在地在關於通信協議的初始發現過程 中，利用通信環境的不同單元的文檔/模式版本能力來填充資料庫(框652)。資料庫可以 是分布式的、鏡像的、位於端點處、或集中位於通信環境的核心部分內。接收方從發送方接 收通信協議消息(例如SIP消息)(框654)，該通信協議消息可以包括合適的消息體(或主 體部分)。響應於接收到的通信協議消息，接收方詢問資料庫，以確定發送方可以接受或驗 證的特定類型的文檔版本(框656)。附加地或備選地，接收方可能能夠基於所述詢問來確 定發送方使用的模式版本。還可以詢問發送方將特定版本的文檔轉換為與一個或多個下遊 節點兼容的另一版本的能力。在另一種變型中，發送方可以在交易之前詢問資料庫和確定 接收方的模式和/或文檔能力。相應地，發送方可以確定僅包括對於接收方兼容版本的文 檔。本領域技術人員將認識到，這裡以及本專利公開中其他地方描述的發送方和接收方可 以是在端點、網絡節點或這兩者上執行的、在適當時充當UAS或UAC的用戶代理。圖7示出了涉及驗證版本化的消息體的消息處理方法的實施例700。在參與如上 所述關於通信協議消息收發的協商方法(框702)時，接收方從發送方接收通信協議消息 (框704)。協議處理器(包括例如消息解析器)可以處理命令行和首部欄位(框706)，從 而確定作為主體的在協議消息中接收到的各種文檔的內容類型(可選地，包括解析為可用 於驗證其中主體(部分)是元素的主體(部分)或文檔集合的一個或多個模式版本的指示 符)(框708)。此後，每種類型的文檔可以由在接收方處實例化的適當的模式處理器/驗證 器來驗證，或者接收方可以確定是否可以處理接收到的文檔。如果接收到無效文檔或不能 處理的文檔，則還可以實現合適的備選動作過程(例如，得體的退出)，而不會導致不期望 的結果，例如接收節點的凍結。這些動作統一為框710。以下詳細闡述關於上述實施例的各種實現方面，尤其參照符合3GPP的IMS網絡環 境中的基於SIP的消息收發。如上所述，可應用的3GPP標準提供了可以與XML實例文檔或 對應XML模式的一個或多個集合相關聯的MIME類型「application/3gpp-ims+xml」。由於可以將XML消息體擴展為包括新元素和/或屬性，或者可以將XML消息體改變為使得重新 定義元素和/或屬性，因此在IMS環境內進行交互的各種SIP UA實體可能彼此不兼容。此 外，UA實體可能希望指示其對不同3GPP IMS XML主體或文檔的支持。在一個場景中，在將 現有XML主體擴展為包括新元素/屬性的情況下，接收方仍可能能夠處理一些XML，可能跳 過未知的元素和/或屬性(作為前向兼容性的示例)。在將現有XML主體改變為使得重新 定義元素/屬性的情況下也可以應用相同處理。在該場景中，可以在驗證期間簡單地忽略 重新定義的元素和/或屬性。備選地或附加地，接收方可以具有向發送方返回信號通知接 收方不理解接收到的XML文檔(例如，通過SIP415消息(不可接受的Content-Type)，具有 所支持的MIME類型，以及可選地具有在SlPAccept首部欄位中列出的其模式版本指示符) 的能力。本領域技術人員將認識到，關於接收這種響應信號的SIP UA或代理應當如何對其 進行處理、是否應當存儲該響應信號以及在應當存儲的情況下存儲在哪以及存儲多長時間 等等，存在多種實現選擇。可以通過放置具有以下效果的特定代碼或指令來實現多種版本之間的前向兼容 性在不使接收方的XML驗證器聲明XML文檔實例無效的情況下，允許附加元素、屬性或兩 者都允許。在一個實施例中，可以插入以下代碼部分然而，不是所有XML處理器或驗證器都可以支持隨機放置上述「XS:any」行。 為了增強與XML驗證器的兼容性，一個示例實施例規定將「xs:any」行放置為任何 complexType、組等的定義的最後一行。相應地，緊接在上述代碼部分之上插入更新的XML 模式中的任何新元素。還可以通過放置「 」或具有以下效果的類似行 來實現前向兼容性在不使XML驗證器聲明XML文檔實例無效的情況下，允許附加屬性。以下在表1中闡述了與各種適用的模式版本兼容性問題相一致的示例構造。表 1 以下在表2A和2B中闡述了 XML模式構造的另一種可能的實現。表 2A 表 2B</xssimpleType〉</xschoice〉 如表2A和2B中體現的3GPP IMS XML的根元素描述如下 這是3GPP IMS XML主體的根元素。其應始終存在。在本文中描述 的XML模式版本是1。在表2A和2B中定義的XML模式的未來版本的XML實例文檔(其中， xsischema元素的XML模式版本屬性部分小於2並大於或等於1)應相對於在本文中表2A 和2B中定義的XML模式有效。在本文中的表2A和2B中定義的XML模式的XML實例文檔 應具有版本屬性值(ims-3gpp元素的一部分)，其等於在本文中描述的XML模式版本的值。在另一種表示中，XML模式的版本屬性或參數可以是可選的，其中，可以分配適當 的預設值。在這兩種情況下，即，在模式的版本屬性被設置為預設的情況下以及在模式的版 本屬性被設置為可以以多種方式編碼的預定義值的情況下，都可以提供XML實例文檔中的 schemaValue,以與從其中導出文檔實例的XML模式的版本屬性相匹配。如上所述，允許任何UA添加和修改XML文檔。相應地，UA實體知道可接受的 XML模式及其版本是有利的。根據一個實施例，可以提供特定指示，以指示版本號或版 本號的範圍、描述符技術(如XML)和根元素名稱。可以將MIME類型擴展為例如包括 「app 1 ication/3gpp-ims+xml ；sv = 1-1. 99」這樣的信息，其中，「sv」代表模式版本，連字 符表示版本值的範圍。此外，可以提供單個值以指示對單個模式版本的支持，並可以提供以 逗號分隔的列表以指示如所列舉和由逗號分隔的特定模式版本。可以將這種字符串置於合適的SIP消息首部中，該SIP消息首部包括但不限於Accept首部欄位、Record-Route (記 錄-路由)首部欄位等。還可以定義其他新首部欄位(例如P-header)，從而每個UA實體 可以插入其XML文檔處理能力和/或兼容性。此外，如果在信令路徑中可以涉及多個UA實 體，則每個實體可以支持不同的XML模式。在這種多節點場景中，還可以提供功能元素(fe) 名稱以便如以下示例所述在多個Accept首部中標識節點(例如P-CSCF、S-CSCF、UE、AS等 等)「application/3gpp-ims+xml ；sv = 1-1. 99 ；fe = ue，as，s-cscf，，，，。在多節點場景中，用於信號通知XML文檔處理能力的一般語法如下Functions =〈fe namel token〉，〈fe name2token>. . .〈fe nameN token〉還可以根據實施方式來提供附加規則。例如，缺少IMS功能元素(ife)令牌可能 意味著在首部中提供的XML模式版本和文檔實例信息可應用於任何下遊節點。同樣，缺少 sv參數可能意味著任何模式版本都可應用或可接受。備選地，缺少sv參數可能意味著預設 版本(例如版本「1」)可應用或可接受。應當清楚，也可以使用除「sv」或「ife」以外的令 牌名稱，只要所有節點(例如發起者或發送方、接收方或終結者、以及中間節點)都知道與 其相關聯的術語、功能、語法和規則。闡述了具有離散編號以及範圍的sv令牌的示例，以指 示對各種模式版本的可支持性sv = 1-2，10-12，14，16以上示例指示了模式版本1和2 (含)、10至12 (含)以及版本14和16得到支 持。由於也可以在上遊包括XML主體文檔，因此可能情況是接收UA(以背對背用戶代理或 B2BUA配置)或代理希望使用非臨時SIP消息來指示其對特定XML模式的支持。備選地，在 不支持所需版本號的情況下，接收UA可能希望在SIP差錯消息中指示這種信息。如果發送 方接收到非臨時SIP響應，則可能接下來會有SIP請求(如CANCEL請求)，可選地包括這種 動作的原因。Accept首部中的sv令牌的另一示例如下Acceptapplication/3gpp_ims+xml ；sv ="1,1. l，，；ife =，，ue, p-cscf, s-cscf,
3.S 9 · · ·以上示例可能使所涉及的不同SIP UA實體(在需要時)能夠利用所有其MIME類 型「application/3gpp-ims+xml」的模式版本來填充Accept首部(例如，在INVITE消息 中)。以下闡述了根據可用於適當地對sv和ife令牌進行編碼的已知標準(例如RFC 2616 和RFC 3261)的Acc印t首部格式的示例。表 3
17 以下在表5中闡述了 XML模式構造的另一種可能的實現。將根據3GPP TS 24. 229 的子條款 5. 1. 3. 1 在 Accept 首部欄位中使用的 application/3gpp-ims+xml MIME類型擴展為包括IM CN子系統功能實體所需的特定版本信息。如果缺少參數，則 應假定利用Accept首部發起SIP方法的UA支持IM CN子系統XML主體的XML模式 的版本1。sv或schemaversion參數具有表5中描述的語法。為了方便，已從IETF RFC3261拷貝了 media-range組件。sv或schemaversion參數是來自Accept首部的當 Hf media-range ^E^f牛的 m-parameter 的歹|J，胃中，m-type i application, m_sub_type 是3gpp-imS+xml。如果sv或schemaversion參數被設置為「無」，則發起SIP方法的UA指示其沒有發現可接受的〃 application/3gpp-ims+xml 〃 MIME類型。表5示出 了 「 application/3gpp-ims+xml〃 MIME 類型的"sv」或"schemaversion」參數的可能的語法。表 5 如以上示例所述，sv令牌或參數可以具有以逗號分隔的離散數值以及數字或數位 範圍，其優點是在指定模式版本時是順序的。此外，sv令牌可以採用被提供為但不限於文 本串、字符、字母數字序列等的值。還可以在SIP消息首部欄位中提供附加信息，以指示可 在通信協議處理層的級別執行的另外的指令。作為示意，接收UA可以在檢查Accept首部 時推定哪些UA作用或甚至UA或功能單元支持何種類型的內容。在一個實施方式中，插入 XML內容類型文檔實例的任何接收UA可能能夠插入用於引導下遊單元的指令，以處理一個 或多個XML內容類型文檔。附加指令可以包括但不限於以下各項「在處理之後移除」、「如 果不理解則跳過」、「必須理解」或「可以移除」等。指令可以被編碼為文本串或二進位值，如 下所示 必須認識到，以上僅是一個示意性示例，指令的順序可以是任意的並可以被編碼 為任何數目的比特。一種包括這種信息的合適信息元素可以是URI或MIME參數，優選地以文本串表 示。在另一備選方案中，還可以在消息體內或在消息體部分內對這種指令進行編碼。在另 一備選方案中，如果支持多個主體部分，則可以將信息表示為附加主體部分(例如，在某主 體部分中利用引用其他主體部分的指令來編碼)。例如，可以採用XML並針對每接收節點存
19在的每個XML模式對表示進行編碼。在另一備選實施例中，在用於標識內容的返回的SIP 消息中使用的Content-Type首部欄位中針對每個主體(或主體部分)放置針對每個接收 節點的指令。以下是這種表示的高級結構 開始SIP消息和首部欄位-包括Content-Type首部欄位+可選參數，包括零或多個指令、模式版本或其他參 數-如果支持多部分/*MIME主體並包括多個主體部分，包括零或多個指令、模式版 本或其他參數在內的參數結束SIP消息》還可以使用名字空間來提供sv值的另一種備選編碼。作為示意，在以下示例中闡 述了 PoC服務中的XML模式版本化，以表明對用於信號通知SV信息的名字空間的使用。Accept:appIication/poc-settings+xml ；sv ="urn:oma:params:xml:ns:poc:po c-settings，urn:oma:xml :poc:poc2. 0-settings，，基本上，可以利用名為「ns」的令牌來替換以上示例中名為「sv」的令牌，以指示一 個或多個XML名字空間標識符的列表遵循引用並被逗號分隔。此外，類似的方式還可以用 於其他的服務專用UA實體，例如，與語音呼叫連續性(VCC)、IMS集中式服務(ICS)、IMS會 話連續性(ISC)等相關的UA0除了傳遞SIP級消息指令外，還可以傳輸基於每個節點來定義關於XML文檔的處 理能力的各種屬性。即，屬性信息可以用於通過與XML驗證器相關聯地執行的策略管理機 制來指示每個所標識的SIP UA或代理單元的可允許行為。示意了以下策略(i)可以忽略， 繼續處理消息文檔，丟棄元素；(ii)強制理解，如果不理解則拒絕消息文檔；(iii)強制跳 過，如果不理解則無需處理；等等。可以將行為策略擴展為指示每個接收節點處的節點專有 行為，例如⑴UE需求；(ii) P-CSCF需求；(iii) S-CSCF需求；(iν)服務需求(例如，ICS標 識符或ISCI信息)等等。如上所述，參照圖6C所示的實施例，用於信號通知模式版本和文檔集合版本信息 的備選機制可以涉及基於每個節點來訪問配置有版本1支持能力的資料庫。資料庫對於 IMS網絡中的任何節點來說可以是可訪問的。此外，可以經由任何合適機制(例如，基於RFC 4483的機制)向節點提供資料庫的位置。可以在節點可用以訪問資料庫的消息中提供對數 據庫的位置進行標識的統一資源定位符(URL)。此外，資料庫可以處於單個節點中或散步在 分布式資料庫架構中的多個節點上。以下在表6中提供了 sv或schemaversion參數的示例語法結構。表6 以上所示的sv語法(以Backus-Naur格式或BNF形式表示)可以用於傳遞 各種類型的值(數位、串等)以指示⑴如果在Content-Type首部中存在MIME類型 和參數，可以用於驗證3GPP IMS XML主體的3GPPIMS XML模式的版本；以及(ii)如果 在Acc印t首部中存在MIME類型和參數，3GPP IMS XML主體的所接受版本。如上所述， 在缺少sv或schemaversion參數的情況下或缺少sv或schemaversion參數時，預設 規則可以適用。在一個實施例中，如果缺少sv或schemaversion參數，則應當理解為 支持特定版本或版本集合(如版本1)。在另一實施例中，如果缺少MIME類型(例如， application/3gpp-ims+xml)並且缺少對應的sv或schemaversion參數，貝Ij應當理角軍為 MIME類型(例如「applicati0n/3gpp-ims+Xml」)的特定版本或版本集合無論如何都可接 受(如版本1)。在另一實施例中，如果缺少sv或schemaversion參數值，則應當理解為不 支持MIME類型的版本或版本集合。後一種特徵在以下情況下可能是有利的其中即使缺少 對應的MIME類型(例如「application/3gpp-ims+xml」)，接收方還認為MIME類型和版本 參數的預設值無論如何都是可接受的。在這種情況下，發送方可以使用SIP首部欄位(例 如Accept首部欄位)來明確指示MIME類型及其任何版本都不可接受。本領域技術人員將認識到，可能需要將MIME類型及其參數註冊至合適的註冊權 威機構(即，註冊器(registrar))，例如，網際網路分配數字權威機構或IANA。以下闡述了可 用於註冊目的的示例模板MIME 媒體類型名稱applicationMIME 子類型名稱3gpp_ims+xml所需參數無可選參數「sv」 或「schemaversion，，以上註冊條目可以包括以加強BNF(ABNF)形成存在的、以上在表5中所示的sv語法。現在參照圖8，示出了根據本公開的實施例的涉及多個SIP實體的示例消息流程 圖800，其中，中間節點可操作用於對關於上遊和下遊實體的模式和文檔版本信息進行協 商。UA1802是最終發往充當接收方的UA2806的請求的發起者或發送方。B2BUA804(例如， 如BGCF或IBCF之類的邊界網關節點)可操作為中間節點。UA1802產生SIPINVITE請求 808，其中，其Accept首部欄位被設置為application/3gpp-ims+xml ；sv =" 1,1. 1" ；ife ="ual"中間節點804截獲INVITE808，修改Accept首部，並向UA2806產生新INVITE請求 810。修改後的Accept首部現在包括以下內容application/3gpp-ims+xml ；sv =" 1,1. 1,2. 5" ；ife ="ual",application/3gpp-ims+xml ；sv =" 2. 5" ；ife = b2bua"本質上，通過如上所述修改Accept首部信息，中間節點804傳遞了其可操作用於 將符合目的地為UAl (在上遊路徑上)的模式版本2. 5的applicati0n/3gpp-imS+xml內 容轉換為與UA1802所支持的模式版本1或1. 1兼容的XML內容，或者不轉換而傳遞符合 模式版本2. 5的applicati0n/3gpp-imS+xml內容(儘可能地執行上述操作；另一方面， 在不可能時，還可以信號通知不能轉換的信息)。此外，中間節點804還信號通知其可操 作用於接受根據目的地為B2BUA的模式版本2. 5的applicati0n/3gpp-imS+xml內容。
21在返迴路徑上將合適的響應消息812和814返回傳播，這些消息可能或可能不包括如以 content-type (內容類型)「application/3gpp-ims+xml 」為SIP主體或主體部分的文檔之 類的任何文檔。應當認識到，在3GPP標準的一些當前版本(即，3GPP TS 24. 229的版本5、版本6、 版本7和版本8)沒有規定UA在Accpet首部中顯式包括「application/3gpp-ims+xml"MIME 類型的情況下，可能需要實現附加變型。為了防止修改所部署的符合版本5/6/7/8的UA並 需要插入 「*/*」 或「application/*」 或「application/3gpp-ims+xml」，本公開的附加實施 例規定可以預留特殊版本指示符(例如，缺少schemaversion或sv參數的值中的版本 application/3gpp-ims+xml ；sv =」」)或令牌(如「無」)，以指示上述MIME類型的內容不能 被發起SIP方法的UA所接受。特殊版本令牌還可以用於表示缺少「*/*」、「applicati0n/*」 或"application/3gpp-ims+xml」，或者在存在 「application/3gpp-ims+xml」MIME 類型的 同時缺少「sv」或「schemaversion」參數，指示對預設版本(例如，與上述MIME類型相關的 模式版本1)的可支持性和應用。圖9示出了具有SIP消息收發的IMS網絡上的電信服務(例如，緊急服務(ES)呼 叫)的示例實施方式。本領域技術人員可以認識到，當UE設備想要在IMS網絡上進行ES 呼叫時，P-CSCF節點(典型地，UE設備與之進行交互的第一 IMS節點)可能出於多種原因 不允許ES呼叫。例如，地區或國家內的管理權威機構可能禁止在IP網絡上進行ES呼叫， 而強制僅在傳統CS網絡上進行ES呼叫。在一些實例中，基於IP的ES呼叫可能非常昂貴， 此外，可能沒有關於這種呼叫的運營商級的可靠性。在另外的場景中，即使允許基於IP的 ES呼叫，IMS網絡也可能想要在不同IP網絡上路由該呼叫，而不是自身處理該呼叫。無論 出於何種原因，當各種實體(即，UE設備、P-CSCF等)關於建立ES呼叫使用XML消息體和 /或XML模式的不同版本時，這些消息體或模式都可能不兼容，從而導致不可預測的行為。 不僅可能不會完成預期ES呼叫，而且請求UE設備可能不會接收到對任何可能的備選動作 過程的任何提醒或指示。在圖9所示的示例方案900中，SIP實體具有對版本信息進行協商並在需要時信號 通知備選動作過程的能力。相應地，當UE設備向IMS節點(S卩，P-CSCF節點)發出針對經 由IP網絡進行ES呼叫的服務請求(框902)時，IMS節點適於處理輸入請求並執行適當的 服務邏輯以產生可能不會經由所請求的網絡建立ES呼叫的響應消息(框904)。IMS節點 還適於向UE設備提供針對在備選網絡(例如，不同的IP網絡)上進行ES呼叫的指示(例 如，經由響應消息)，並可以包括適用的路由信息(框906)。在另一備選方案中，IMS節點 可以適於向UE設備提供要在傳統CS網絡上進行ES呼叫的指示，這可以再次包括適當的路 由信息(框908)。備選地或附加地，IMS節點還可以向UE設備提供不能完成所請求的ES 呼叫的提醒和/或指示，從而可以便於得體的退出，包括例如，原因代碼或文本原因，被編 碼為對網絡是否或為何建議備選服務的響應消息的一部分(框910)。此外，響應於包括在 響應消息中的指示或者由於本地預設過程，UE設備還可以詢問資料庫(再一次，在UE設備 內本地提供或在網絡環境中遠程提供)，以獲得與在備選網絡上建立ES呼叫相關的適當ID 和/或路由信息。包括典型地在IMS網絡環境中實現的XML主體的SIP消息收發還涉及例如 如上所述在消息中提供Content-Disposition首部欄位。Content-Disposition首部欄位描述了消息體或對於多部分消息來說的消息體部分將如何由UAC或UAS來解釋。 Content-Disposition首部的各種「disposition-types (部署類型)」是針對SIP而定義並 由IANA來註冊的。值「session (會話)」指示了主體部分描述針對呼叫或早期(呼叫前) 媒體的會話。值「render (呈現)」指示了主體部分應當被顯示或呈現給用戶。部署類型 "icon(圖標)」指示了主體部分包含圖像，該圖像適合作為當已接收到消息時或者持久地 在進行對話時UA實體以信息方式呈現的、主叫者或被叫者的圖標表示。值「alert (提醒)」 指示了主體部分包含UA實體在試圖向用戶提醒接收到請求(一般地，發起對話的請求)時 應當呈現的信息，例如音頻剪輯。如果在SIP消息中缺少Content-Disposition首部欄位，則根據RFC2161，服務 器可以實現「render」的預設值以便於兼容，儘管MIME類型可以在特定應用中確定預設內 容部署。此外，如果沒有MIME類型，則典型地實現預設「render」。相關地，「handling (處 理)，，參數handling-param描述了在USA接收到消息體並且其不理解該消息體的內容類 型或部署類型時UAS應當如何反應。傳統地，處理參數定義了值「optional (可選)」和 「required (必需)」。儘管與內容部署有關的以上規則可能在一些SIP應用中足夠，但在MIME類型是 「application/3gpp-ims+xml」的情況下出現了一些問題。例如，對於這些MIME類型，呈現 的預設內容部署是不合適的。作為示意，在上述ES呼叫場景中，如果提供SIP380(備選服 務)以經由XML主體向請求UE設備指示備選服務，則呈現這種內容的預設部署是無意義 的。相應地，本專利公開的其他實施例提供了一種機制，用於信號通知適當的內容部署，從 而避免呈現並實現適當部署，或由接收方調用適當應用以處理消息體的內容。此外，可以調 節內容部署信令機制，以基於接收方的功能來改變部署過程。換言之，接收UE設備可以參 與與接收網絡節點的部署行為不同的部署行為。圖10A-10C示出了與用於針對每個消息處理和/或解釋至少一個消息體的內容的 內容部署方案相關的各個實施例，其中，消息體內容具有對應的內容類型。圖IOA中的參考 標記1000A指接收方處的示例過程。在從發送方接收到消息(如SIP或HTTP消息)(框 1002)時，關於接收到的消息(例如消息體或主體部分)進行檢查以確定是否存在指示符 (例如，內容部署指示符)、指示符的值等(框1004)。響應於該檢查，禁止對接收到的消息 的內容進行預設的(例如，在缺少Content-Disposition首部時的預設部署)或甚至顯式 信號通知的處理。在一些情況下，該檢查還可以指示不明確的處理。可以確定(例如，在消 息中(在首部中或在消息體內)顯式信號通知或者在接收方處配置)接收方可用於處理消 息內容的備選處理。還可以將該確定修改為基於接收實體的功能或作用、接收到的消息的 上下文、包括在主體或其他首部中的任何指令等等來指示不同的部署。這些功能在框1006 中作為示例。圖10B示出了內容類型指示符用於確定接收方處的適當部署的實施例1000B。在 從發送方接收到通信協議消息(如SIP或HTTP消息)(框1010)時，關於接收到的消息(例如消息體或主體部分)進行檢查以確定是否 存在內容類型指示符、指示符的值等(框1012)。響應於該檢查，接收方可能基於接收實體 的功能或作用、接收到的消息的上下文、包括在主體或其他首部中的任何指令等等來實現 處理(框1014)。同樣，可以在消息中(在首部中或在消息體內)或者經由單獨的機制來信號通知內容類型指示符。圖IOC示出了基於Content-Disposition首部的缺失來進行確定的實施例1000C。 在從發送方接收到通信協議消息(如SIP或HTTP消息)時，確定接收到的消息是否具有 Content-Disposition首部。備選地，如果存在Content-Disposition首部，則可以對其是 否是空欄位進行進一步確定。如果是，則檢查Content-Type首部欄位。這些過程在框1022 中闡述。響應於該檢查，禁止對接收到的消息的內容的預設處理。接收方可能基於接收實 體的功能或作用、接收到的消息的上下文、包括在主體或其他首部中的任何指令等等來實 現備選部署處理(框1024)。本領域技術人員將認識到，在發送方實體處關於內容部署信令進行適當的消息 產生過程，這實質上是上述實施例的對等實施例。即，發送方可以產生SIP消息，該SIP 消息包括但不限於合適的內容部署和/或內容類型指示符、Content-Disposition和/ 或Content-Type首部欄位的適用值等等。以下，再一次具體參照用於進行特定服務(例 如，ES呼叫)的符合3GPP的IMS網絡環境中的基於SIP的消息收發，詳細地闡述了關於 上述實施例的附加實現方面。如上所述，可以沿兩個方向(即，上遊以及下遊方向)將根 據特定內容類型的內容添加至SIP消息。例如，上遊SIP消息可以使用指示符(例如，在 Acc印t首部欄位中)指示哪些MIME類型是可接受的。如果接收方接收到包含不支持的 內容類型的指示在內的Acc印t首部欄位，則可以產生合適的響應，例如SIP406(不可接 受)或SIP415(不支持的媒體類型)響應。具體地，在IMS的上下文中，可以在S-CSCF節 點與AS節點之間沿上遊方向或者在P-CSCF節點與UE設備之間沿下遊方向發送具有MIME 類型「appliCati0n/3gpp-imS+xml」的內容。同樣如上所述，SIP實體可以沿任一方向插 入或移除XML消息體或其部分。相應地，除了信號通知合適的XML模式和/或文檔版本 信息以使得消息體不僅被驗證而且被適當處理以外，在SIP消息的首部欄位(如Accept、 Content-Disposition、Content-Type等)中提供適當信息變得重要。在一個實施方式中，在Acc印t首部欄位中缺少顯式版本支持可能意味著SIP UA 節點接受上遊或下遊支持的任何MIME類型的最低版本。另一方面，如果UA節點支持MIME 類型的更高版本，則可以相應地在Acc印t首部中指示其支持。在一些情況下，UAS期望著 UAC能夠處理特定的內容類型。例如，在非UE可檢測的緊急會話的情況下，P-CSCF節點 可以期望UE設備接受MIME類型「application/3gpp-ims+xml，，的內容。如果在Accept 首部欄位中沒有信號通知MIME類型「applicati0n/3gpp-ims+Xml」 (及其版本)，則可能 出現特定的互操作性問題。相應地，在一個場景中，當P-CSCF節點使用要使用CS域進行 ES呼叫的指示進行響應時，假定將接收SIP380(備選服務)響應消息的UE設備接受符合 3GPP TS 24. 229標準的MIME類型的版本1，P-CSCF節點可以在SIP380 (備選服務)響應 中包括以下指示或設置=Content-Type首部欄位，其值被設置為指示符合的MIME類型； Content-Disposition首部欄位，被設置為與主體的或主體部分的內容類型和接收方中的 預期處理以及被設置為「required(必需)」的關聯處理參數相關聯的值。此外，P-CSCF節 點還可以在XML消息體中包括以下各項(i)〈alternative-service〉元素，被設置為備選 服務的適用參數；(ii)子元素，被設置為「emergency (緊急)，，以指示其為ES呼叫； 以及(iiiXreason〉子元素，被設置為運營商可配置原因。此外，P-CSCF節點可以在非緊急註冊場景內處理緊急會話建立。相應地，在另一
24實施方式中，當P-CSCF節點使用需要緊急註冊的指示來進行響應時，如前所述假定將接收 SIP380 (備選服務)響應消息的UE設備接受符合3GPP TS 24. 229標準的MIME類型的版 本1，P-CSCF節點可以在SIP380響應中包括以下指示或設置=Content-Type首部欄位，其 值被設置為指示與主體的或主體部分的內容類型和接收方中的預期處理相關聯的值。此 夕卜，P-CSCF節點還可以在XML消息體中包括以下各項(i)〈alternative-service〉元素， 被設置為備選服務的適用參數；(ii)子元素，被設置為「emergency (緊急)，，以指示 其為ES呼叫；以及(iii)〈action〉子元素，被設置為「emergency-registration (緊急注 冊)」以指示需要緊急註冊；以及(ivXreason〉子元素，被設置為運營商可配置原因。應當 注意，在該實施方式中，〈action〉元素僅用於向UE設備指示需要緊急註冊。在其他上下文 中，〈action〉元素的使用可能是可選的。此外，在該實施方式中，僅當P-CSCF節點從UE設 備接收到其為緊急會話的明確指示時，才可以發送SIP380(備選服務)響應消息，例如，通 過在請求-URI中提供緊急服務的統一資源名稱(URN)(按照RFC5031)。還應當注意，在「sv」或「schemaversion」屬性之後缺少版本值或者對於「sv」或 「schemaversion」屬性或m參數具有表示「無」的明確指示符或值可能意味著由UA實體 (例如UE設備)信號通知其不接受符合3GPP TS 24. 229標準的IMS XML主體的任何版本。 如上詳細描述，可以以多種方式(例如，以逗號分隔的數位、數位範圍、文本串等)信號通 知XML模式版本值，其中，符合的MIME類型被添加至Accept首部欄位。如果MIME類型被 添加至Content-Type首部欄位，則XML驗證器可以使用該值來識別XML模式及所需的其版 本(針對該版本可驗證消息體)。另一方面，不為此目的而具有版本屬性的XML文檔可以具 有所定義的名字空間。在對SIP380(備選服務)響應的具體參考中，如果接收方沒有理解 380(備選服務)響應的內容，則可以向SIP380響應的發送方產生ACK消息，可能包括具有 解釋或原因的差錯指示符。作為另一種變型，UA實體(例如UE設備)還可以包括Accept 首部欄位以提供其願意接收會話描述協議(SDP)內容以及其能夠處理的任何MIME類型的 指示。以下在表7中闡述以ABNF形式存在的示例Content-Disposition首部欄位表 7 應當認識到，「X-process」是在「disp-type」中指示時要應用的過程擴展，這種過程可以包括在沒有外部註冊或標準化的情況下在兩個協作代理之間雙邊定義的私有值。 可以對期望的部署過程給出任何名稱以指示特定行為，其他名稱也可以用於指示相同行 為。此外，Content-Disposition首部欄位還可以包含其他指示或屬性，以信號通知其他類 型的功能，包括但不限於(i)XML文檔應當由特定功能來處理；(ii)XML文檔應當由特定應 用來處理；(iii)XML文檔應當由特定功能中的特定應用來處理；(iv)XML文檔源自特定功 能；(ν)XML文檔源自特定功能中的特定應用；以及(Vi)XML文檔要根據特定標準及其中的 章節來處理。作為示意，SIP 380(備選服務)響應消息可以用於指示ES呼叫，或者其可以 用於向功能通知其需要從一種無線接入技術(RAT)和/或域改變至另一種RAT和/或域。 清楚地，也可以實現其他屬性以及以上屬性的任意組合。可以提供「process」或「X-process」或某其他通用值的disp-type值，以包括對 在不同條件下信號通知執行指令、腳本等的指示，例如⑴功能單元(例如，任何UA實體， 但不限於此)決定添加Content-Disposition首部，並且沒有定義其他合適值；(ii)需要 功能單元(例如，任何UA實體，但不限於此)添加Content-Disposition首部(以超控 預設行為(例如呈現內容))；(iii)功能單元(例如，任何UA實體，但不限於此)想要將 與Content-Disposition首部欄位相關聯的處理參數顯式設置為「required(必需)」或 「optional (可選)」；或(iv)以上各項的任意組合。示例部署過程名稱可以闡述如下(i)3gpp-alternative-service 指示P-CSCF 正在發送消息體；(ii) 3gpp-emergency 指示P-CSCF正在發送消息體，並且XML文檔包含 針對ES呼叫或應用的指令、腳本或其他信息；以及(iii)3gpp-serVice-inf0 指示XML文 檔用於接收消息體的AS節點。應當注意，可以允許多個內容部署值實現過程的組合。例如， 名為「3gpp-emergenCy，alert"的過程可操作用於指示CS域上的ES呼叫以及向這種呼叫 的用戶提供通知。以上所述的content-disposition值名稱可操作用於向接收方通知要以特定方 式處理MIME類型「 app 1 ication/3gpp-ims+xml 」的內容。具體地，作為示例，可能信號通 知在CS網絡上建立ES呼叫或執行緊急註冊。「process (過程)，，的處理可以包括短超時， 足以使用戶實現緊急號碼，儘管不是預期的，但已認識到。這樣，可以避免無意的ES呼叫。 此外，這裡所述的過程還允許網絡節點(如AS節點)或不存在人機接口(匪I)的UE設備 防止呈現緊急呼叫指示符(如SIP 380(備選服務)響應)的內容，從而不與預期處理相 衝突。然而，在可能和/或有用時，可以允許對特定文本或視聽信息的選擇性呈現。例如， 對於MIME類型「application/3gpp-ims+xml 」來說，值「render (呈現)」可以信號通知給 UE設備，以呈現或指示XML元素(具有文本信息)的內容。同樣，對於MIME類型 「appliCati0n/3gpp-imS+xml」來說，值「alert (提醒)」可以信號通知給UE設備以提醒用 戶。在一個實施例中，可以利用預設行為來如下增強3GPP TS 24. 229，以在接收到明 確定義的上下文中的主體時應用特定Content-Disposition首部欄位部署類型值。應當注 意，不同的預設Content-Disposition首部欄位部署類型值可以應用於不同上下文。在上述實施例的另一種增強形式中，可以增強3GPP TS 24. 229以便甚至超控/忽 略存在於SIP消息中的Content-Disposition首部欄位部署類型值，簡單地執行該上下文 的預設Content-Disposition首部欄位部署類型值。本實施例可以如下所示
在接收到對INVITE請求的380 (備選服務)響應時，其中380 (備選服務)響應 包括IM CN子系統XML主體，類型元素被設置為「emergency (緊急)」，動作元素被設置為 "emergency-registration，，，UE 將進行以下操作-應用「3gpp-alternative-service」的 content-disposition (見 3GPP TS24. 229 中的子條款7. 2A. 11)；-如3GPPTS 24. 229中的子條款5. 1. 6. 2中所述，在可用時使用不同VPLMN來執 行初始緊急註冊，並且如果新的緊急註冊成功，則如該子條款中所述，嘗試緊急呼叫；-在可用且尚未嘗試時，根據3GPPTS 24. 008中所述的過程，經由CS域，嘗試緊急 呼叫；或者-執行實現專用的動作，以建立緊急呼叫。或者，如下在接收到對INVITE請求的380 (備選服務)響應時，其中380 (備選服務)響應 包括IM CN子系統XML主體，類型元素被設置為「emergency (緊急)」，動作元素被設置為 "emergency-registration，，，UE 將進行以下操作-應用「3gpp-alternative-service」的 content-disposition (見 3GPP TS24. 229 中的子條款7. 2A. 11)；-如3GPPTS 24. 229中的子條款5. 1. 6. 2中所述，執行初始緊急註冊，並且如3GPP TS 24. 229中的子條款5. 1. 6. 8. 3中所述，嘗試緊急呼叫；-在可用且尚未嘗試時，根據3GPPTS 24. 008中所述的過程，經由CS域，嘗試緊急 呼叫；或者-執行實現專用的動作，以建立緊急呼叫。Content-Disposition 首部欄位部署類型值 3gpp-alternative_service 和 3gpp-service-info 已定義如下_ 當包括 7Π 素 時，^ 3gpp-alternative-service 與 Content-Type application/3gpp-ims+xml 一起使用。-當包括兀素 時，將 3gpp-service-info 與 Content-Type application/3gpp-ims+xml 一i^il!用。在一些實施方式中，可能在SIP消息內包括多個內容部署。以下闡述表8中的示 例。表8 如上關於緊急服務(ES)呼叫的示例實施方式所述(見圖9)，來自IMS網絡節點的 SIP380(備選服務)響應消息可以具有以下能力向接收UE設備信號通知各種功能指示， 例如，再次嘗試在PLMN或另一 PS網絡上進行ES呼叫，指定要使用的一種或多種RAT ；或者 提供具有另一內容部署值的附加XML主體，以指示執行UE設備中的簡檔。例如，SIP380 (備 選服務)響應消息可以通過發送「alert」元素來進行信號通知，並且當UE設備接收到該 指示時，觸發關於ES呼叫執行預配置的存儲簡檔。示例簡檔可以涉及播放鈴聲、蜂鳴聲等 以及在顯示屏上向用戶顯示文本消息/指令(例如，重試緊急呼叫)。在另一種變型中， SIP380 (備選服務)響應的XML主體實際上可以包含提供給UE設備的簡檔，該簡檔可以被 執行以指示UE設備應當進行何種操作。以更概括的方式，應當認識到，可以在任何SIP消息(例如，任何但不限於包括未 被UE檢測到和未表示為根據某種專用編號方案或PNP的地址的緊急會話地址在內的消息) 中實現關於SIP380(備選服務)響應的以上處理。應當認識到，可以使用以下格式之一來在 輸出的SIP請求的請求-URI中發送專用編號信息(i)符合RFC3966的TEL URI，其中本地 編號之後跟隨有電話上下文值；(ii)符合RFC3261的SIP URI，其中用戶=電話參數；(iii) 符合RFC3261和RFC4967的SIP URI，其中用戶=撥號串參數；以及(iv)符合RFC3261的 SIP URI，其中，用戶部分包含專用編號信息，並且域名具體到足以使網絡能夠理解用戶部 分包含專用編號信息。此外，當不理解部署類型或者部署類型與對應內容類型的預期部署 類型的範圍不匹配時，可以發送SIP400或4xx響應。與以上部分所述在Acc印t首部中缺少正確信息的效果或者在消息體中具有非 預期的內容的效果相類似，關於Content-Disposition首部也可以有多種潛在錯誤場 景。這些場景可以大致分類如下，例如(i)Content-Disposition首部存在但未知；(ii)Content-Disposition首部存在但未知，但參數已知；(iii)Content-Disposition首部存 在但不恰當；以及(iv) Content-Disposition首部不存在(即，缺少)。與以上部分中的教導類似，如果UA實體或代理不具有MMI或者知道消息體不會被 接收方呈現，則其潛在地可能不清楚UA實體可以如何有效地從需要經由合適的MMI與用戶 進行交互的SIP方法中的文件名參數或其他信息中獲益。如上所述，一個示例實施方式可 以涉及提供具有適當預設(例如，針對每個MIME類型)Content-Disposition及其參數值 的本地偏好設置。另一種變型可以涉及在存在特定首部(例如，Content-Encoding)或者 特定信息存在於所請求的SIP方法中的情況下提供附加處理。以下闡述了示出預設處理修改的示例，其中，接收具有Content-Type "appl ication/3gpp-ims+xml，，的SIP380 (備選服務)響應消息，超控預設處理(即，在缺 少另一值時呈現)，並可以獨立於Content-Disposition首部欄位的值或存在來應用 "3gpp-alternative-service"表9 以上處理作為名為「3gpp-alternative-service」的預設內容部署過程的示例。 通過提供具體的基於名稱的部署過程，在一些情況下(尤其是在SIP消息體包含不適於呈 現的指令或腳本的情況下)可以超控或忽略預設處理或首部值信息。還可以在超控或忽略 (預設)內容部署值之前評估其他條件，例如，其他SIP首部的存在或值、值、參數、主體部 分、主體(部分)值等等。該表對於不同的UA來說可能是不同的，並使表示特定功能單元 (例如UE設備)的一個UA能夠應用與由表示特定功能單元(例如AS節點)的另一 UA所 jSffl白勺 content-disposition( 胃胃)f 胃白勺 content-disposition( 胃胃)。上表中所示的預設處理信息可以由運營商、第三方、訂戶或以任意組合來提供。在一個實施方式中，可以以與初始過濾準則(IFC)相同的結構、或通過合適的公共策略框架、 或經由服務規定、或使用開放移動聯盟(OMA)設備管理(DM)、或其他方式(包括例如硬編碼 的部署)來表示這種表。可以使用OMA設備管理過程，可能經由傳輸機制(例如，非結構化 補充服務數據(USSD)、短消息服務(SMS)、多媒體廣播多播服務(MBMS)、IP等)，將預設處 理表下載至UA實體。相應地，可以在定義一組關於針對不同種類的內容等等的預設處理選項的策略的 SIP UA實體中提供內容部署策略管理器。例如，如果接收到具有特定內容類型的SIP消息， 則預設行為根據由UA管理的策略結構而依賴於部署值。以下在表10中闡述示例策略結 構表10 以上示例規定如果UA接收到具有內容類型(1)的消息，則UA在接收到部署值的 情況下要檢查部署值。然後，策略層級執行如下(i)接受的部署值(2)，在接收到該部署值 時，引導UA實體根據任何已知標準(例如，適用的IETF標準、3GPP標準等)來執行/處理； ( )拒絕的部署值(3)，針對內容類型而接收，引導UA實體拒絕整個消息體或忽略遵循特 定MIME類型的部分；(iii)忽略的部署值(4)，其中，在接收到該部署值時，引導UA實體應 用預設處理部署值(5) ； (iv)未接收到部署(6)，其中，引導UA實體應用另一預設處理部署 值⑵。對於與Content-Disposition首部欄位相關的各種潛在錯誤場景，附加實施方式 可以在以下在先美國臨時專利申請中找到「SIP CONTENT DISPOSITION HEADER SYSTEM AND METHOD, 」 申請號:Νο· 61/015，003，於 2007 年 12 月 19 日以 Jan John-Luc Bakker, Adrian Buckley和Andrew Allen的名義提交，其以引用的方式併入於此。總體上，實施例 提供一種方案，其中，即使在缺少適當值時，也可以基於本地UA條件、配置和策略管理來向 首部分配適當值。此外，在一些內容類型可以觸發或需要依賴於不同上下文的不同行為的情況下， 還提供了上下文化(contexualized)內容部署。例如，可以將SIP380響應消息中的內容類 型「appliCati0n/3gpp-imS+xml」強制為使得在接收到具有UE設備上的一些數據值的內容 類型時發起ES呼叫/會話建立。另一方面，當在AS節點處在SIP INVITE消息中接收到具 有不同數據的相同內容類型時，向AS節點上的應用通知特定訂戶信息。在這兩種情況下， 「rendering(呈現)」都是不恰當的；然而，在給定了相同MIME類型的兩種不同應用的情況 下，不能應用單個預設策略。相應地，如上述實施例中所述，可以針對UE和AS節點分別指定上下文專用的預設處理過程。圖11示出了為了本專利公開目的可操作為與SIP兼容的UE設備(如UE 102)的 通信設備的實施例的框圖。本領域技術人員在參照該通信設備時將認識到，儘管UE102的 實施例可以包括與圖11所示的配置類似的配置，但關於所示出的各個模塊，可以有硬體、 軟體或固件方面的多種變型和修改。相應地，圖11的配置應當被視為對本專利公開的實施 例的示意而非限制。用於提供對UE設備的實施例的總體控制的微處理器1102可操作地耦 合至可能能夠進行多模式通信(例如，CS域、IP域(如IMS)等)的通信子系統1104。通 信子系統1104 —般包括一個或多個接收機1108和一個或多個發射機1114以及關聯組件， 例如一個或多個本地振蕩器(LO)模塊1110和如數位訊號處理器(DSP) 1112之類的處理模 塊。通信領域技術人員將認識到，通信模塊1104的具體設計可以依賴於行動裝置預期操作 的通信網絡(例如，CDMA網絡、GSM網絡、WLAN等)。然而，無論具體設計如何，將天線1106 通過適當接入基礎設施1105 (例如蜂窩基站塔、WLAN熱點等等)接收到的信號提供給接收 機1108，接收機1108可以執行常見接收機功能，例如信號放大、下變頻、濾波、信道選擇、模 數(A/D)轉換等。類似地，要發送的信號由DSP1112處理(包括例如調製和編碼)並被提 供給發射機1114以進行數模(D/A)轉換、上變頻、濾波、放大以及經由天線1116通過空中 無線電接口來發送。微處理器1102還可以與另外的設備子系統接口連接，例如輔助輸入/輸出(I/ 0)1118、串行埠 1120、顯示器1122、鍵盤/鍵區1124、揚聲器1126、麥克風1128、隨機存取 存儲器(RAM) 1130、短距離通信子系統1132以及總體標記為參考標記1133的任何其他設 備子系統(例如，定時器機制)。為了控制接入，還可以針對可移除存儲模塊(通用/訂戶 標識模塊(U/SIM)或可移除用戶標識模塊(RUIM))提供接口 1134與微處理器1102進行通 信。在一個實施方式中，U/SIM或RUIM接口 1134可以與具有多種關鍵配置1144和其他信 息1146的U/SIM或RUIM卡一起操作，其他信息1146例如是預設內容部署簡檔、策略管理 器、備選網絡信息以及可對基於本地存儲的信息進行補充的標識和訂戶相關數據。作業系統軟體和可應用服務邏輯軟體可以在永久存儲模塊(即，非易失性存儲 器)中實現，例如快閃記憶體1135。在一個實施方式中，快閃記憶體1135可以被分隔為不同區域，例如， 用於電腦程式1136 (例如，服務處理邏輯)的存儲區域以及數據存儲區，例如設備狀態 1137、地址簿1139、其他個人信息管理器(PIM)數據1141以及總體標記為參考標記1143的 其他數據存儲區域。可以提供傳輸棧1145，以執行一個或多個適當的無線分組傳輸協議。此 外，提供了內容部署策略管理器和部署指示符邏輯模塊1148，以及在一些實施例中的XML 模式驗證器和版本協商邏輯塊，以便於以上詳細闡述的一個或多個實施例。應當認識到，本專利公開中闡述的各種操作、組件和過程，不論是可操作於UE設 備處、IMS網絡節點處還是其他網絡位置，可以經由多種手段，通常與處理系統相關聯地 被實現為被配置為執行特定功能的組件，該多種手段包括軟體(例如，程序代碼或指令序 列)、固件、硬體或任意組合。在該過程以軟體實現的情況下，這種軟體可以包括形成計算 機程序產品的程序指令、計算機可訪問介質上的指令、可上載的服務應用軟體、或可從遠程 站下載的軟體等等。此外，在過程、數據結構或這兩者存儲在計算機可訪問存儲器中的情況 下，這種存儲器可以包括半導體存儲器、內部和外部計算機存儲介質，並包括但不限於非易 失性介質、易失性介質和傳輸介質。非易失性介質可以包括CD-ROM、磁帶、PR0M、快閃記憶體或光學
31介質。易失性介質可以包括動態存儲器、高速緩存、RAM等。傳輸介質可以包括載波或其他 信號承載介質。如這裡使用的，短語「計算機可訪問介質」包括「計算機可讀介質」以及「計 算機可執行介質」。此外，儘管上述實施例已關於符合3GPP的網絡中基於SIP的消息收發而詳細描 述，但將認識到，本專利公開的的教導可以應用於涉及不同協議(例如HTTP)的其他分布式 環境。同樣，這裡的教導還可以關於以下的其他標記語言而應用其中，可能有版本化主體， 並且某種元結構用於驗證這種主體。相信從上述具體實施方式
中，本專利公開的實施例的操作和構造將變得顯而易 見。儘管所示和所述的示例實施例可能已被表徵為優選的，但應當容易理解，在不脫離如權 利要求所限定的本公開的範圍的前提下，可以對示例實施例進行各種變更和修改。
權利要求
一種針對每個消息解釋至少一個消息體的內容的方法，其中，所述內容與內容類型相對應，所述方法包括接收方從發送方接收消息，所述消息在所述消息的主體中包括至少一個消息體內容；檢查是否至少一個指示符與所述消息相關聯；以及響應於所述檢查，禁止對所述消息的主體中的所述至少一個消息體內容的處理，並對所述消息的主體中的所述至少一個消息體內容應用備選處理。
2.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述發送方是部署在網絡環境中的用戶設備UE設備。
3.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述發送方是部署在網絡環境中的網絡節點。
4.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述接收方是部署在網絡環境中的網絡節點。
5.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述接收方是部署在網絡環境中的UE設備。
6.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述消息的主體包括至少一個指令。
7.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述消息的主體包括可擴展標記語言XML文檔。
8.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述對應的內容類型是XML媒體類型或基於XML的媒體類型。
9.根據權利要求8所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述對應的XML媒體類型或基於XML的媒體類型由XML模式來定義。
10.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述消息包括會話發起協議SIP消息和超文本傳輸協議HTTP消息中的一個。
11.根據權利要求10所述的針對每個消息解釋至少一個消息體的內容的方法，其中， 所述至少一個指示符包括內容部署指示符和內容類型指示符中的一個，所述至少一個指示 符在會話發起協議SIP消息和超文本傳輸協議HTTP消息中的所述一個中的首部欄位中提 {共。
12.根據權利要求11所述的針對每個消息解釋至少一個消息體的內容的方法，其中， 所述首部欄位是Content-Type首部欄位和Content-Disposition首部欄位中的一個。
13.根據權利要求11所述的針對每個消息解釋至少一個消息體的內容的方法，其中， 所述首部欄位具有包括文本信息在內的名稱。
14.根據權利要求11所述的針對每個消息解釋至少一個消息體的內容的方法，其中， 所述禁止處理包括禁止預設處理。
15.根據權利要求14所述的針對每個消息解釋至少一個消息體的內容的方法，其中， 所述禁止預設處理包括禁止對Content-Disposition首部欄位部署類型「呈現」的預設處 理。
16.根據權利要求11所述的針對每個消息解釋至少一個消息體的內容的 方法，其中，所述備選處理包括應用Content-Disposition首部欄位部署類型"3gpp-alternative-service」 和 Content-Disposition 首部欄位部署類型 "3gpp-service-info"中的一個。
17.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述檢查指示不明確的處理。
18.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述備選處理包括開始緊急服務呼叫。
19.根據權利要求1所述的針對每個消息解釋至少一個消息體的內容的方法，其中，所 述備選處理包括向用戶提供指示。
20.一種用於針對每個消息解釋至少一個消息體的內容的設備，其中，所述內容與內容 類型相對應，所述設備包括與接收方相關聯的、被配置為從發送方接收消息的組件，所述消息在所述消息的主體 中包括至少一個消息體內容；被配置為檢查是否至少一個指示符與所述消息相關聯的組件；以及響應於所述檢查而被配置為禁止對所述消息的主體中的所述至少一個消息體內容的 處理並對所述消息的主體中的所述至少一個消息體內容應用備選處理的組件。
21.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述發送方是部署在網絡環境中的用戶設備UE設備。
22.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述發送方是部署在網絡環境中的網絡節點。
23.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述接收方是部署在網絡環境中的網絡節點。
24.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述接收方是部署在網絡環境中的UE設備。
25.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述消息的主體包括至少一個指令。
26.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述消息的主體包括可擴展標記語言XML文檔。
27.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述對應的內容類型是XML媒體類型或基於XML的媒體類型。
28.根據權利要求27所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述對應的XML媒體類型或基於XML的媒體類型由XML模式來定義。
29.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述消息包括會話發起協議SIP消息和超文本傳輸協議HTTP消息中的一個。
30.根據權利要求29所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述至少一個指示符包括內容部署指示符和內容類型指示符中的一個，所述至少一個 指示符在會話發起協議SIP消息和超文本傳輸協議HTTP消息中的所述一個中的首部欄位 中提供。
31.根據權利要求30所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述首部欄位是Content-Type首部欄位和Content-Disposition首部欄位中的一個。
32.根據權利要求30所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述首部欄位具有包括文本信息在內的名稱。
33.根據權利要求30所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述禁止處理包括禁止預設處理。
34.根據權利要求33所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述禁止預設處理包括禁止對Content-Disposition首部欄位部署類型「呈現」的缺 省處理。
35.根據權利要求30所述的用於針對每個消息解釋至少一個消息體的內容 的設備，其中，所述備選處理包括應用Content-Disposition首部欄位部署類 型"3gpp-alternative-service」 和 Content-Disposition 首部欄位部署類型 "3gpp-service-info"中的一個。
36.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述檢查指示不明確的處理。
37.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述備選處理包括開始緊急服務呼叫。
38.根據權利要求20所述的用於針對每個消息解釋至少一個消息體的內容的設備，其 中，所述備選處理包括向用戶提供指示。
全文摘要
在一個實施例中，公開了一種用於針對例如SIP或HTTP消息的每個消息，解釋至少一個消息體的內容的方案，其中，消息體內容與內容類型相對應。如SIP或HTTP消息之類的通信協議消息由發送方向接收方產生，其中，消息在消息的主體中包括至少一個消息體內容。與接收方相關聯的組件被配置為檢查是否至少一個指示符與消息相關聯。響應於該檢查而操作的組件被配置為禁止對消息體內容的處理並對該消息體內容應用備選處理。
文檔編號H04L29/06GK101919222SQ200880122526
公開日2010年12月15日 申請日期2008年10月22日 優先權日2007年10月27日
發明者安德魯·艾倫, 簡·約翰-盧克·貝克, 艾德裡安·巴克利 申請人:捷訊研究有限公司