按照会话启动协议发送系统消息的系统和方法

专利名称：按照会话启动协议发送系统消息的系统和方法
技术领域：
本发明通常涉及会话启动协议(SIP)技术，更具体地，涉及用于向例如即时消息(IM)、无线一键通(PoC)、多媒体消息服务(MMS)的各种基于SIP的服务订户和由服务供应商提供的其它任何基于SIP的服务发送系统消息的方法。
系统消息是系统为了不同目的而发送的特殊类型的消息(例如，付款通知书、服务通知、警报、指令等)。系统消息可以包括可能的选项的列表，并要求来自用户的响应。
SIP是用于控制通过网络的多媒体会话的会话启动协议，其包括但并不限于MESSAGE方法、消息会话中继协议(MSRP)方法和SIP INFO方法。
背景技术：
下面将描述MESSAGE方法、MSRP方法和SIP INFO方法MESSAGE方法-SIP扩展RFC 3428MESSAGE方法(参见请求注释(RFC)3428，“Session InitiationProtocol(SIP)Extension for Instant Messaging(用于即时消息的会话启动协议(SIP)扩展)”，B.Campbell，Ed.，et.al.，RFC 3428，2002年12月)提出了MESSAGE方法，其为SIP的扩展(参见RFC 3261，“SIPSession InitiationProtocol(SIP会话启动协议)”，J.Rosenberg，et.al.，RFC 3261，2002年6月)，其允许发送即时消息。MESSAGE请求是SIP的扩展，因而其继承了SIP协议的所有请求路由和安全特征。MESSAGE请求在其中携带多用途网际邮件扩充协议(MIME)主体部分的形式的内容。MESSAGE请求本身不生成SIP对话。通常，每个即时消息各自独立，很像寻呼消息。可以在另一个SIP请求生成的对话内容中发送MESSAGE请求。
MSRp方法消息会话中继协议(MSRP)(参见“The Message Session Relay Protocol(消息会话中继协议)”，B.Campbell，Ed.，et，al.，draft-ietf-simple-message-sessions)是用于在会话中发送一系列相关即时消息的协议。MSRP是基于文本定向连接的协议，用于交换任意的或二进制MIME内容，特别是即时消息。
SIPINFO方法-RFC 2976SIP INFO方法(参见RFC 2976，“The SIP INFO Method(SIP INFO方法)”，S.Donovan，RFC 2976，2000年10月)允许携带在会话期间生成的会话相关控制信息。
然而，使用上述传统方法的系统消息传送会引起一些意外的关键问题，其中基本不能辨别系统消息和正常消息，并且也不能正确识别从客户端接收的关于系统消息的响应。此外，上述传统方法还有其他缺点，当服务器期待来自客户端的响应时，它们排除了特定的持续时间，而且对于服务器来说要提供友好的用户服务级别访问控制是非常困难的。

发明内容
因此，本发明旨在解决在传统技术中发生的上述难题，本发明的一个方面是提供一种传送系统消息的方法，用于区分系统消息和正常消息。
根据本发明的另一个方面，提供了一种传送系统消息的方法，用于识别客户端将从服务器接收的响应的类型。
根据本发明的另一个方面，提供了一种传送系统消息的方法，用于当服务器期待来自客户端的响应时，等待特定的持续时间。
在本发明的另一个方面中，提供了一种传送系统消息的方法，用于提供来自服务器的友好的用户服务级别访问控制。
在本发明的另一个方面中，提供了一种传送系统消息的方法，其中服务器将系统消息发送到客户端，服务器从客户端接收其响应而且基于服务供应商的策略确定任何随后的动作。
仍在本发明的另一个方面中，提供了一种可应用于MESSAGE方法、MSRP SEND方法和SIP INFO方法的系统消息传送方法。
为了实现本发明上述和其他方面，根据本发明的一个方面，提供了一种按照SIP传送系统消息的方法，包括通过服务器，将表示系统消息的特征标记引入SIP消息的消息首标，并且将表示包含与系统消息相关的内容的多用途网际邮件扩充协议(MIME)内容类型引入消息主体，并在消息主体中携带包括与系统消息相关的内容的系统消息请求可扩展标记语言(XML)文档，从而创建用于发送到客户端的对应于当前状况的系统消息请求；并且，通过客户端，接收系统消息请求，根据接收的系统消息请求将特征标记和MIME内容类型添加到SIP消息的消息首标，从而创建用于发送到服务器的系统消息请求，该系统消息请求在消息主体中携带包括与系统消息请求响应相关的内容的系统消息响应XML文档。
并且，通过MESSAGE、MSRP SEND、INFO或其他恰当的SIP方法发送系统消息请求和系统消息响应。
优选地，在SIP消息首标的Accept-Contact(接受-联系)字段中携带特征标记，并且在Content-Type(内容-类型)字段中携带MIME内容类型。
优选地，特征标记可以是“+g.application.smsg”标记，而MIME内容类型可以是“vnd.example.system-message+xml”。
有利地，系统消息请求XML文档可以从<system-message>根元素开始，系统请求消息XTML文档包括<smsg-type>元素，该元素指示该系统消息是系统消息请求或系统消息响应；<smsg>元素，该元素包括唯一标识编号以关联系统消息响应和系统消息请求；<smsg-text>元素，该元素包括要被发送到客户端的信息；<smsg-response-type>元素，该元素向用户指示依照系统消息请求而被客户端请求的用户的响应类型；<answer-options>元素，通过包含在<smsg-response-type>中的响应类型确定该元素内容，该元素包括响应的具体内容和标识符；<verification>元素，该元素包括用于确认用户已阅读系统消息请求的代码；<time-out>元素，该元素指示等待时间的持续时间，在该等待时间内，期待用户对于系统消息请求的响应；以及<restrict-access>元素，该元素允许服务器协助客户端阻止对相应服务的进一步访问，直到用户相对于系统消息请求进行响应。
优选地，<smsg-response-type>元素可以包括no-answer(无应答)、only-one-answer(仅有一个应答)和multiple-answer(多个应答)中的至少一个，如果不期待来自用户的响应，则使用“no-answer”，如果要选择两个不同应答(接受或拒绝)中的一个，则使用“only-one-answer”，如果系统消息需要带有多个应答的用户响应，则使用“multiple-answer”。
优选地，如果<smsg-response-type>元素值是“no-answer”，则<answer-options>元素可以不包括在系统消息请求文档中，并且如果是只有一个应答或有多个应答，则每个<answer-options>元素包括<answer-option-id>子元素，该子元素包括对应于用于标识应答选项的唯一编号的标识符；以及<answer-option-text>子元素，该子元素包括表示每个应答选项的具体含义的文本。
优选地，<verification>元素可以包括两个子元素<verification-text>元素和<verification-uri>元素，<verification-text>元素包括用户必须在系统消息响应中输入的字母数字代码，而<verification-uri>元素包括字母数据代码位置的统一资源标识符(URI)。
优选地，在系统消息请求XML文档中可以选择性地包括<time-out>元素、<restrict-access>元素和<verification>元素。
此外，系统消息响应XML文档可以包括<smsg-type>元素、<smsg>元素、具有用户对系统消息请求的应答的<answer>元素以及包括用户根据系统消息请求的<verification>元素中包括的字母数字行而输入的字母数字行的<verification>元素。


从下面结合附图的本发明的详细描述中，本发明的上述和其它目标、特征和优点将会变得更加明显，其中图1是示出了通过客户端接收来自服务器的接收系统消息请求的控制过程的流程图；图2是示出了客户端向服务器发送系统消息响应的控制过程的流程图；图3是示出了根据通用SIP MESSAGE方法发送系统消息的过程的流程图；图4是示出了根据MSRP SEND方法发送系统消息的过程的流程图；并且图5是示出了根据SIP INFO方法发送系统消息的过程的流程图。
具体实施例方式
以下将参照附图描述本发明的优选实施例。在下面本发明的描述中，当此中包括的已知功能和配置会混淆本发明的主题时，将会把其省略。
系统消息是系统为不同目的发送的特定类型的消息(例如，付费通知、服务提醒、警告、指令等)。这些系统消息可以包括可能的选项的列表，而且要求来自用户的响应。发送这样的消息的周期取决于服务供应商的策略。终端用户的响应可以用来改变服务流通。
本发明提供一种方法，通过将新内容引入MIME形式的SIP消息主体、将新特征标记引入已有的SIP消息首标，而将系统消息进行传送，以领会各种系统消息需求；然后将其作为系统消息来发送，用于发送信息并且接收用户响应。在MIME类型的SIP消息主体中携带新内容的所述方法可以应用于例如MESSAGE方法、MSRP SEND方法、SIP INFO方法等。
客户端和服务器必须支持系统消息特征。此外，客户端和服务器必须特定地标识系统消息，区分系统消息和其他正常消息。因此，根据本发明，将新特征标记引入SIP消息的消息首标中有助于服务器确定客户端是否支持系统消息，还有助于发送和接收系统唯一地标识系统消息。该新特征标记可以被称为“+g.applications.smsg”，而且该新特征标记可以应用于任何服务，例如IM服务、PoC服务、MMS服务。特征标记“+g.applications.smsg”的ASN.1标识符是IANA的新分配，而且该特征标记表示客户端支持系统消息。适用于该特征标记的值是布尔值。特征标记起初意欲用于今后的应用、协议、服务或流通机制中，并且在通信应用中最为有用，用于描述例如电话或PDA等设备的性能。
上述典型用途的一个例子是将系统消息路由到能够支持系统消息的移动电话。新特征标记在SIP REGISTER步骤过程中必须被客户端注册。SIP首标字段用于指示对系统消息的支持，例如，以便能够使用接受-联系首标来根据RFC 3841“Caller Preferences for the Session Initiation Protocol(用于会话启动协议的呼叫参考)”的规则和程序连同“require(需求)”和“explicit(显式)”参数一起携带新特征标记。新特征标记可以被使用在用于系统消息的各种SIP方法中。与是否在一个会话中发送系统消息无关，在本发明中可以使用SIPMESSAGE方法来发送和接收系统消息。同样，可以将SIP IFO方法和MSRPSEND方法应用于本发明，用于会话期间中发送系统消息。
根据本发明，必须为系统消息定义新的MIME类型。例如，利用“vnd.example.system-message+xml”MIME内容类型唯一地标识新的MIME类型。该MIME内容类型用于标识该SIP MESSAGE主体包括符合特定方案(XML方案)的系统消息。新的MIME内容类型被应用于例如IM服务、PoC服务、MMS服务的任何服务。此外，在用于系统消息的各种SIP方法中，必须指示新的MIME内容类型。与是否在会话中发送系统消息无关，SIPMESSAGE方法可以被用于发送和接收系统消息，并且，SIP INFO和MSRPSEND方法也可以用于在会话期间发送系统消息。在SIP MESSAGE的首标字段中(例如在内容类型首标中)可以携带新的MIME类型。
同时，在发送和接收系统消息期间，在各种SIP方法的消息主体中携带根据新的MIME内容类型的系统消息。因此，必须基于由新的MIME内容类型定义的新的方案来描述消息主体。只有在必要时(例如首次使用等)，才将系统消息发送到客户端。所以，服务器保持这样一种状态，即从中服务供应商可以知道已经向谁发送了系统消息并且仍然要向谁发送系统消息。因此，可以用如下方式来限定由新的MIME内容类型定义的消息主体能够被服务器用来发送的系统消息应当具有与客户端用于响应回服务器的消息相同的方案。例如，可以具有能够实现系统消息请求和系统消息响应的单个方案。
以下将描述系统消息请求文档的结构。系统消息请求是结构良好的而且必须有效的XML文档。该系统请求消息文档基于XML 1.0，并且使用联码转换格式8(UTF-8)编码。本发明利用XML命名空间来唯一地标识系统消息请求文档或该文档的片段。由本发明的详细描述所定义的用于元素的命名空间统一资源标识符(URI)是使用命名空间标识符“example”统一资源名(URN)，。下面阐明该URN“urn:example:params:xml:ns:application:system-message”上述系统消息请求文档可以从<system-message>根元素开始，它还可以包括<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<answer-option-id>元素、<answer-option-text>元素、<verification>元素、<verification-text>元素、<verification-uri>元素、<time-out>元素和<restrict-access>元素。在下面的表格1中提供了每个元素的定义。
表格1


参照上面的表格1，将详细描述关于上述的各个元素。
<smsg-type>元素表示系统消息是“request”类型，其意味着它是从服务器到客户端。<smsg>元素是包括用来将将响应和系统消息请求进行关联的唯一标识编号的元素。该元素使系统同时发送多于一个的系统消息，从而减少消息传送和信令的开销。同样，它有助于在服务器端将稍后可以从客户端接收的响应和系统消息进行关联。
<smsg-text>是提供要呈现给用户的某些消息的元素。<smsg-response-type>元素是向用户通知来自应答该系统消息请求的用户所期望的响应类型的指示符，该响应包括“no-answer”、“only-one-answer”或“multiple-answer”，其中，在服务器发送的系统消息仅仅与用户信息有关、而且不期待来自用户的响应的情况下，使用“no-answer”，在服务器发送的系统消息需要知道仅仅带有接受/拒绝或者是/否类型的响应的用户的响应的情况下，使用“only-one-answer”，在服务器发送的系统消息需要知道带有多个应答的用户的响应时，使用“multiple-answer”。服务器基于用户所需的响应类型而确定<smsg-response-type>元素中的值。客户端必须依照服务器请求的响应类型进行回应。
<answer-options>元素是描述可由用户选择且可组成多个元素的可能的应答选项的元素。当存在该元素时，意味着服务器期待来自用户的响应。因此，在<smsg-response-type>元素值是“no-answer”的情况下，不存在<answer-options>元素。<answer-options>将允许客户端显示用户可以从中选择的应答选项。在仅有一个应答或多个应答的情况下，每个应答选项对包括唯一的ID和表示该选项含义的文本消息。该唯一的ID有助于服务器标识用户响应于系统消息所作出的选择。每个<answer-options>元素包括对应于标识应答选项的唯一编号的<answer-option-id>元素，以及提供解释相应应答选项的空白文本的<answer-option-text>元素。如果不存在子元素，那么这意味着客户端将向用户提供用于填写该应答的选项。
<verification>元素是确认用户已阅读系统消息的元素。如果存在该字段，那么这表示服务器需要用于声明用户已阅读过该消息的回执(acknowledgement)。是否包括该<verification>元素是可选的，并由服务器来决定。<verification>元素包括以下两个子元素中的一个子元素，即<verification-text>和<verification-uri>元素，其中<verification-text>元素描述用户必须在系统消息响应中重新输入的字母数字代码，，而<verification-uri>元素描述表示用户必须在系统消息响应中插入该代码的代码位置的URI值。
<time-out>元素是通知用户持续时间的元素，在该持续时间内期望用户的响应。该元素包括服务器期望用户在某一时间/持续时间内响应系统消息的情况。如果用户没有在预定的时间/周期内作出响应，则服务器可以基于本地策略确定动作的未来方向。是否包括该<time-out>元素是可选的，这由服务器来决定。
<restrict-access>元素是允许服务器协助客户端阻止对服务的进一步访问直到用户响应系统消息的元素。是否包括该元素也是可选的，并且由服务器决定。如果服务器通过<restrict-access>元素请求阻止对该服务的访问，则客户端不应该允许用户进一步访问该服务。从而，在服务器希望限制该服务访问直到客户端进行响应的情况下，服务器保持访问状态并且等待响应，直到时间用尽为止，在时间用尽的情况下，该服务器基于服务供应商策略而决定下一步的动作。在时间用尽的状态下服务器可以重发系统消息，但是根据服务供应商的策略而决定系统消息的重发。应当用MIME内容类型“vnd.example.system-message+xml”来标识系统消息请求文档。
下面将在表格2中描述表格2中所示系统消息的请求文档的XML方案。
表格2



根据本发明的包括上述元素的系统消息请求文档的例子如下面的表格3所示。
表格3



接下来，将描述系统消息响应文档的结构。系统消息响应文档必须是结构良好并且有效的XML文档。系统消息响应文档基于XML1.0并使用UTF-8编码。本发明利用XML命名空间唯一地标识系统消息响应文档或文档的片段。本发明定义的元素的命名空间URI是URN，其使用命名空间标识符“example”。该URN的描述如下urn:example:params:xml:ns:application:system-message系统消息响应文档以<system-message>根元素开始，它还包括<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素。各个元素的定义如下面的表格4所示。
表格4

参考上面的表格，进一步详细描述其中各个元素。
<smsg-type>元素表示系统消息是“response(响应)”类型，这意味着它是从客户端到服务器的。<smsg>元素是具有包括在系统消息请求的<smsg>元素的“id”属性中的值的元素。该元素有助于寻找在服务器的请求和响应之间的匹配。在单个消息中发送多于一个的系统消息的情况下，该<smsg>元素还有助于使所述响应相关联，以减少消息传送和信令的开销。
<answer>元素是表示根据应答选项列表的用户选择的元素，并且可以包括许多元素。该元素是在系统消息请求中定义的一组应答选项中的选择。每个<answer>元素包括子元素<answer-id>。如果在系统消息请求中的<smsg-response-type>元素中的值是“multiple-answer”，则还可以有多个<answer-id>元素。这允许用户使用相同的消息对一个请求发送多个应答。仅使用ID服务器以减少该消息的尺寸。同样，每个<answer>元素可以包括子元素<answer-text>和<answer-id>，其中存在用户输入的空白文本应答。应答响应有利于服务供应商决定同意给予用户的服务级别，以及诸如密码复位、新的登记、收费、特征等的各种要素。
<verification>元素是确认用户已阅读系统消息的元素。例如，用户输入在系统消息请求中出现的代码，从而允许服务器确认用户已经阅读过该系统消息。否则，该元素可以是在如特定URI(如系统消息请求中提到的)所描述的位置出现的代码。如果用户提供的响应的验证失败，则服务器策略将决定下一步的动作。例如，可能是服务器不允许对服务的进一步访问，且服务器可以重发该系统消息。应当由MIME内容类型“vnd.example.system-message+xml”标识系统消息响应文档。
系统消息响应文档的XML方案如下面的表格5所述。
表格5



根据本发明的系统消息响应文档的例子如下面的表格6所示。
表格6


现在参照图1和图2描述系统消息的传送和接收过程，其中，图1示出了由客户端接收来自服务器的系统消息请求的控制过程，图2示出了客户端向服务器发送系统消息响应的控制过程。
首先参照图1描述系统消息请求的传送过程。如果服务器X(130)根据现有的通信环境确定需要发送系统消息到客户端X，那么它向SIP/IP核心(120)发送SIP请求消息，即系统消息请求。这里，SIP请求消息的Request-URI包括客户端X(110)的地址，且SIP消息首标的Accept-Contact标题包括特征标记“+g.application.smsg”。此外，消息首标的Content-Type字段包括MIME内容类型的“application/vnd.example.system-message+xml”，用于表示消息主体具有与系统消息相关的内容，并且将SIP消息的消息主体配置成具有与系统消息请求相关的内容的XML文档。
所述SIP请求消息的例子如下面的表格7所示。
表格7


在步骤203中，SIPIP/Core X(120)基于存储在登记步骤中的信息，将从服务器(130)接收的SIP请求消息发送到客户端X(110)。在步骤205中，客户端X(110)允许将接收的SIP请求消息(即系统消息请求)向用户X显示。然后，在步骤207中，客户端X(110)将SIP 200“OK”响应发送到SIP/IP核心X(120)，以便确认已经接收了系统消息请求。将SIP 200“OK”响应沿着信令路径发送到服务器X，其配置如下面的表格8所示。
表格8

在步骤209中，接收SIP 200“OK”响应的SIP/IP核心X(120)将响应发送到服务器X。服务器X(130)接收SIP 200“OK”响应，从而确认客户端X(110)已接收系统消息请求。参照图2，其描述了根据本发明，在客户端X(110)接收SIP请求消息(即系统消息请求)之后，使用SIP响应消息的新信息传送系统消息响应的过程，。如图2所示，客户端X(110)向SIP/IP核心X(120)发送SIP响应消息，以对在图1的步骤中接收的SIP请求消息进行应答。这里，SIP响应消息的Request-URI可以包括服务器X(130)的地址，SIP消息首标的Accept-Contact首标可以包括特征标记“+g.application.smsg”。此外，消息首标的Content-type字段可以包括MIME内容类型的“application/vnd.example.system-message+xml”，用于表示所述消息主体具有与系统消息相关的内容，而且SIP消息的消息主体可以被配置成具有与系统消息响应相关的内容的XML文档。该SIP响应消息的例子如下面表格9所示。
表格9

在步骤303中，SIP/IP核心X(120)根据Accept-Contact首标中的特征标记“+g.application.smsg”将所接收的SIP响应消息发送到服务器X(130)。在步骤305中，服务器X(130)接收SIP响应消息，从而接收客户端X(110)对系统消息请求的响应。然后，在步骤307中，服务器X(130)将如下面表格10中所示的SIP 200“OK”响应发送到SIP/IP核心X(120)。
表格10

接下来，在步骤308中，SIP/IP核心X(120)将SIP 200“OK”响应传送到客户端X(110)。
本发明提供了一种用于传送系统消息以领会(comprehend)各种系统消息需求的方法，该方法将MIME内容类型和表示上述系统消息的新特征标记引入SIP消息的消息首标中，并且还在SIP消息的MIME类型主体中携带具有与系统消息相关的内容的XML文档。这里，可以通过MESSAGE方法、MSRP SEND方法、SIP INFO方法等实现SIP消息。
参照图3到图5，描述了根据上述各个方法的系统消息传送方法。在所述附图中，图3示出了根据通常的SIP MESSAGE方法发送系统消息的过程，图4示出了根据MSRP SEND方法发送系统消息的过程，图5示出了根据SIPINFO方法发送系统消息的过程。
如图3所示，在SIP MESSAGE方法中，服务器20在步骤11中根据表格2的XML方案构成用于提供信息或警告的系统消息请求，从而请求接受/拒绝和多个应答。换句话说，服务器20使用<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<verification>元素、<verification-text>元素和<restrict-access>元素构成包含在系统消息请求中的内容，然后在步骤13中使用MESSAGE方法将相同的内容发送到客户端10。在步骤15中，客户端10使接收的系统消息请求与正常消息区分显示，而且如果被系统消息请求所请求，则它就控制用户对特定服务的访问，然后在步骤17中将SIP 200“OK”响应发送到服务器20。其后，在步骤19中，如果有必要的话，客户端10就在系统消息请求预定的时间内根据表格5的XML方案构成对系统消息请求的响应消息。例如，客户端10使用<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素构成包含在系统消息响应中的内容，然后在步骤21中使用SIP MESSAGE方法将相同内容发送到服务器20。一旦服务器20识别出所发送的响应消息，其就确认用户已阅读了该消息，并且向客户端10发送200“OK”响应。
如图4所示，在MSRP SEND方法中，服务器20在步骤31中根据表格2的XML方案构成用于提供信息或警告的系统消息请求，从而请求接受/拒绝和多个应答。例如，服务器20使用<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<vertification>元素、<time-out>元素和<restrict-access>元素构成包含在系统消息请求中的内容，然后在步骤33中通过使用MSRP SEND方法将相同内容发送到客户端10。在步骤35中，客户端10使所接收的系统消息请求与正常消息区分显示，而且如果被系统消息请求所请求，则它就控制用户对特定服务的访问，随后在步骤37中将SIP 200“OK”响应发送到服务器20。其后，在步骤39中，客户端10在系统消息请求中预定的时间内根据表格5的XML方案构成对系统消息请求的响应消息。例如，客户端10使用<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素构成包含在系统消息响应中的内容，然后在步骤41中使用MSRP SEND方法将相同内容发送到服务器20。一旦服务器20识别出所发送的响应消息，则其确认用户已经阅读过该消息，并且向客户端10发送200“OK”响应。
如图5所示，在SIP INFO方法中，服务器20在步骤51中根据表格2的XML方案构成用于提供信息或警告的系统消息请求，从而请求的接受/拒绝和多个应答。换句话说，服务器20使用<smsg-type>元素、<smsg>元素、<smsg-text>元素、<smsg-response-type>元素、<answer-options>元素、<verification>元素、<time-out>元素和<restrict-access>元素构成包含在系统消息请求中的内容，然后在步骤53中使用SIP INFO方法将相同内容发送到客户端10。在步骤55中，客户端10显示所接收的系统消息请求，而且如果被系统消息请求所请求，它就控制用户对特定服务的访问，然后客户端10在步骤57中将200“OK”响应发送到服务器20。其后，在步骤59中，客户端10在系统消息请求中所预定的时间内根据表格5的XML方案构成对系统消息请求的响应消息。例如，客户端10使用<smsg-type>元素、<smsg>元素、<answer>元素、<answer-id>元素、<answer-text>元素和<verification>元素构成包含在系统消息响应中的各种内容，然后在步骤61中通过使用SIP INFO方法将相同内容发送到服务器20。服务器20检测所发送的响应消息，确认用户已阅读了该系统消息，随后向客户端10发送200“OK”响应。
从上面的描述可以看到的，本发明提供了一种使用SIP消息传送系统消息的方法，其将系统消息类型的MIME内容和表示该系统消息的特征标记引入SIP消息的消息首标，从而在SIP消息的消息主体中携带描述与系统消息相关的内容的XTML文档。因此，根据本发明的使用SIP来传送系统消息的方法可以区分系统消息和正常消息，而且可以使服务器标识对于从客户端接收的系统消息的响应。此外，该方法允许当服务器等待来自客户端的响应时，等待特定的持续时间，并且本本方法提供了来自服务器的友好的用户服务级别访问控制。而且，服务器可以向客户端发送系统消息，且服务器可以从客户端接收对其的响应。服务器可以基于服务供应商的策略来确定任何接下来的动作。此外，传送系统消息的该方法可适用于SIP MESSAGE方法、MSRPSEND方法和SIP INFO方法。
对于本领域技术人员来说显而易见的是，通过描述和附图的教导，可以从本发明的各种方法和装置的组合中得到其他控制方法和装置，并且这些也被认为在本发明的范围之内。而且，因此在前面省略了对上述组合和变化的描述。还应该注意的是，用于存储上述应用的主机包括但不限于计算机、移动通信设备、移动服务器或多功能设备。虽然已结合其优选实施例并参照附图全面描述了本发明，但要注意的是，可以做出各种变化和修改，而且这种变化和修改对于本领域的技术人员来说是显而易见的。除非上述变化和修改背离了本发明的范围，否则上述变化和修改可以被理解为包括在由所附的权利要求书所定义的本发明的范围之内。
[RFC2976]“The SIP INFO Method”，S.Donovan，RFC 2976，October 2000，URI:http://www.ietf.org/rfc/rfc2976.txt[RFC3261]“SIPSession Initiation Protocol”，J.Rosenberg，et.al.，RFC3261，June 2002，URL:http://www.ietf.org/rfc/rfc3261.txt[RFC3428]“Session Initiation Protocol(SIP) Extension for InstantMessaging”，B.Campbell，Ed.，et .al.，RFC 3428，December 2002，URL:http://www.ietf.org/rfc/rfc3428.txt[MSRP]“The Message Session Relay Protocol”，B.Campbell，Ed.，et.al.，draft-ietf-simple-message-sessions，URL:http://www.ietf.org/intemet-drafts/draft-ietf-simple-message-sessions-15.txt
权利要求
1.一种使用会话启动协议SIP传送系统消息的方法，包括以下步骤通过服务器，将表示系统消息的特征标记引入SIP消息的消息首标，而且将表示包含与系统消息相关的内容的多用途网际邮件扩充协议MIME内容类型引入消息主体，并携带描述消息主体中与系统消息相关的内容的系统消息请求XML文档，从而构成用于发送到客户端的与当前状况对应的系统消息请求；而且通过客户端，接收系统消息请求，根据所接收的系统消息请求将所述特征标记和所述MIME内容类型引入到SIP消息的消息首标中，从而构成用于发送给服务器的携带系统消息响应XML文档的系统消息响应，该系统消息响应XML文档描述了对消息主体中的系统消息请求进行响应的相关内容。
2.如权利要求1所述的方法，在所述构成并发送系统消息请求的步骤中，客户端构成与提供信息、提供警告、请求对任意服务的接受/拒绝或请求多个应答中的至少一个对应的系统消息请求。
3.如权利要求2所述的方法，所述构成并发送系统消息响应还包括步骤如果接收的系统消息请求包括特征标记，则将所述系统消息与一般的SIP消息区别显示。
4.如权利要求3所述的方法，在所述构成并发送系统消息响应的步骤中，如果所接收的系统消息请求包括用于请求响应的内容，则客户端构成系统消息响应。
5.如权利要求4所述的方法，根据SIP MESSAGE方法、MSRP SEND方法或SIP INFO方法中的一个来发送系统消息响应。
6.如权利要求5所述的方法，其中，在所述消息首标的Accept-Contact字段中携带所述特征标记，在Content-type字段中携带MIME内容类型。
7.如权利要求6所述的方法，其中，所述特征标记是“+g.application.smsg”标记，而且所述MIME内容类型是“vnd.example.system-message+xml”。
8.如权利要求6所述的方法，其中，所述系统消息请求XML文档以<system-message>根元素开始。
9.如权利要求8所述的方法，其中，所述系统消息请求XML文档包括<smsg-type>元素，该元素表示该系统消息是系统消息请求；<smsg>元素，该元素包括用于关联对系统消息请求的响应的唯一编号；<smsg-text>元素，该元素包括要发送到客户端的信息；<smsg-response-type>元素，该元素表示依照系统消息请求向客户端请求的用户的响应类型；<answer-options>元素，通过包含在<smsg-response-type>中的响应类型确定该元素内容，该元素包括响应的具体内容和标识符；<verification>元素，该元素包括用于确认用户已阅读所述系统消息请求的代码；<time-out>元素，该元素表示其间期望对所述系统消息请求的用户响应的等待时间的持续时间；以及<restrict-access>元素，该元素允许服务器协助客户端阻止对相应服务的进一步访问，直到用户关于该系统消息请求进行响应。
10.如权利要求9所述的方法，其中，所述<smsg-response-type>元素包括no-answer、only-one-answer和multiple-answer中的至少一个，其中，在不期待来自用户的响应的情况下，使用“no-answer”，在要选择两个不同的应答中的一个的情况下，使用“only-one-answer”，在系统消息需要带有多个应答的用户响应的情况下，使用“multiple-answer”；其中，在<smsg-response-type>元素值是“no-answer”的情况下，系统消息请求文档不包括<answer-options>元素，在只有一个或多个应答的情况下，每个<answer-options>元素包括<answer-option-id>子元素和<answer-option-text>子元素，该<answer-option-id>子元素具有与用于标识应答选项的唯一编号对应的标识符，该<answer-option-text>子元素具有表示每个应答选项的具体含义的文本；而且其中，所述<verification>元素包括两个子元素<verification-text>元素和<verification-uri>元素，所述<verification-text>元素包括用户必须在系统消息响应中输入的字母数字代码，而所述<verification-uri>元素包括该字母数据代码的位置的统一资源标识符URI。
11.如权利要求10所述的方法，其中，在所述系统消息请求XML文档中可选地包括<time-out>元素、<restrict-access>元素和<verification>元素。
12.如权利要求11所述的方法，其中，所述系统消息请求XML文档包括<smsg-type>元素、<smsg>元素、具有用户对系统消息请求的应答的<answer>元素以及具有字母数字行的<verification>元素，该<verification>元素是用户根据<verification>元素中包括的字母数字行而输入的。
全文摘要
本发明提供了一种系统和方法，通过将MIME主体形式的新内容和新特征标记引入现有SIP框架来实现SIP中的系统消息通信，用于发送服务特定信息并接收用户响应。该系统消息可以包括可能选项的列表并要求来自用户的响应。
文档编号H04L29/06GK1972302SQ20061014928
公开日2007年5月30日 申请日期2006年8月14日 优先权日2005年8月12日
发明者帕滕·J·巴萨瓦拉, 雷德希卡·雷加文德兰 申请人:三星电子株式会社