在分布式环境中处理消息内容的内容部署系统和方法

专利名称：在分布式环境中处理消息内容的内容部署系统和方法
技术领域：
本专利公开总体涉及通信网络中的消息处理。更具体且没有任何限制地，本专利 公开涉及用于在分布式环境(例如，包括因特网协议(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文档实例无效的情况下，允许附加元素、属性或两 者都允许。在一个实施例中，可以插入以下代码部分<xs any namespace =，，##any^processContents =，，lax，，minOccurs =，，0”maxOccurs =，，unbounded，，/>然而，不是所有XML处理器或验证器都可以支持随机放置上述“XS:any”行。 为了增强与XML验证器的兼容性，一个示例实施例规定将“xs:any”行放置为任何 complexType、组等的定义的最后一行。相应地，紧接在上述代码部分之上插入更新的XML 模式中的任何新元素。还可以通过放置“ <xs anyAttribute/> ”或具有以下效果的类似行 来实现前向兼容性在不使XML验证器声明XML文档实例无效的情况下，允许附加属性。以下在表1中阐述了与各种适用的模式版本兼容性问题相一致的示例构造。表 1 以下在表2A和2B中阐述了 XML模式构造的另一种可能的实现。表 2A 表 2B</xssimpleType〉</xschoice〉</xscomplexType> 如表2A和2B中体现的3GPP IMS XML的根元素描述如下<ims-3gpp> 这是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)<type>子元素，被设置为“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)<type>子元素，被设置为“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设备，以呈现或指示<reaS0n>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Π 素 <alternative-service> 时，^ 3gpp-alternative-service 与 Content-Type application/3gpp-ims+xml 一起使用。-当包括兀素 <service-info> 时，将 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日
发明者安德鲁·艾伦, 简·约翰-卢克·贝克, 艾德里安·巴克利 申请人:捷讯研究有限公司