一种发送会话初始协议参考消息的方法和用户代理

暂无

一种发送会话初始协议参考消息的方法和用户代理\n技术领域\n[0001] 本发明涉及通信领域的会话初始协议，尤其涉及会话初始协议的参考消息。\n背景技术\n[0002] 会话初始协议(SIP：Session Initiation Protocol)的参考(REFER)消息提供了允许一方指示另一方来发起指定SIP请求消息的机制，具体可参见相应的互联网工程组IETF(Internet Engineering Task Force)规范RFC3515。呼叫转移是REFER最典型的应用。举例来说，Alice正在和Bob通话，Alice有事需要离开，决定由Carol继续和Bob的通话，Alice可以用她的用户代理UA1发送REFER请求消息到Bob的用户代理UA2，提供Carol的SIPURI给Bob，以及指示所希望的通信方式如缺省的为发起SIP INVITE请求。如果Bob采纳允许了这一请求，Bob的用户代理将尝试根据Alice提供的信息呼叫Carol的用户代理UA3，并且Bob的用户代理将会向Alice的用户代理通知呼叫是否成功。呼叫流程图如图1所示，主要包括如下步骤：\n[0003] 步骤101～102.第一用户代理UA1发送REFER参考消息给第二用户代理UA2；第二用户代理UA2返回202Accepted响应；\n[0004] 步骤103～104.第二用户代理UA2建立与该REFER参考消息相应的订阅，并立即向第一用户代理UA1发送NOTIFY通知消息；第一用户代理UA1在收到NOTIFY通知消息后返回200OK响应；\n[0005] 步骤105～107.第二用户代理UA2根据上述的REFER消息向第三用户代理UA3发起INVITE呼叫请求；第三用户代理UA3接受该请求后返回200OK响应；第二用户代理UA2向第三用户代理UA3发送ACK消息；\n[0006] 步骤108～109.第二用户代理UA2将呼叫请求的结果发送NOTIFY通知消息给第一用户代理UA1；第一用户代理UA1在收到NOTIFY通知消息后返回200OK响应。\n[0007] 另外REFER参考消息也经常应用在会议业务中，如一个用户可以指示另外一个用户加入会议，具体的可以指示另一个用户代理向一个会议(Conference)的会议中心(Focus)对应的SIP统一资源标识符URI发送INVITE请求。目前REFER参考消息只能发送给一个接收者，而在会议业务中，一种常见的业务场景是一个用户向多个会议参与者指示加入一个会议中，按现有技术该用户只能向多个会议参与者一一发送REFER参考消息，指示其加入会议。这种方案由于要发送多个REFER参考消息，还要分别对REFER参考消息建立多个订阅，效率较低，尤其在无线网络环境中发送多个REFER参考消息需要消耗较多的空中网络资源。\n发明内容\n[0008] 本发明要解决的技术问题在于提供两种传送会话初始协议参考消息的方法，通过仅发送一个参考消息来指示多个接收者触发指定的会话初始协议消息。\n[0009] 本发明还提出了一种传送会话初始协议参考消息的方法，使参考消息仅触发一个会话初始协议消息就可以让多个接收者收到。\n[0010] 本发明还提出了一种传送会话初始协议参考消息的方法，使参考消息所触发的会话初始协议消息可以携带指定的消息体内容。\n[0011] 本发明还提出了一种用户代理，处理包含接收者列表的参考消息。\n[0012] 为解决上述问题，本发明提出的技术方案如下：\n[0013] 一种传送会话初始协议参考消息的方法，包括步骤：\n[0014] 分发服务器接收到第一用户代理发送的会话初始协议参考消息，所述参考消息的消息体中包含所述参考消息的接收者地址列表，并且在相应的内容处理方式头字段中包含分发指示信息；分发服务器根据所述的分发指示信息和接收者地址列表所述参考消息进行分发。\n[0015] 一种传送会话初始协议参考消息的方法，包括步骤：\n[0016] 第一用户代理向第二用户代理发送会话初始协议的参考消息，在所述参考消息中指定要触发的会话初始协议请求方法，以及在Refer-To头字段中包含内容标识，所述的内容标识与消息体中接收者地址列表的内容标识头字段中的值相同，并且在相应的内容处理方式头字段中包含分发指示信息；\n[0017] 第二用户代理接收所述参考消息，根据Refer-To头字段中包含内容标识获得消息体中具有相同值的内容标识头字段对应的接收者地址列表内容，并按所述的分发指示信息和指定要触发的会话初始协议请求方法向接收者地址列表分发相应的会话初始协议请求消息。\n[0018] 一种传送会话初始协议参考消息的方法，包括步骤：\n[0019] 第一用户代理向第二用户代理发送会话初始协议的参考消息，在所述参考消息的消息体中包含接收者地址列表，相应的内容处理方式头字段的值指示在触发的会话初始协议消息中要携带对应的内容；\n[0020] 第二用户代理接收所述参考消息，并根据所述接收者地址列表的内容处理方式头字段的指示在触发的会话初始协议消息中携带所述接收者地址列表。\n[0021] 一种用户代理，包括：\n[0022] 传输处理模块，用于接收消息处理模块发来的会话初始协议消息，并采用相应的承载协议将其发送出去；\n[0023] 消息处理模块，用于对会话初始协议消息进行编解码和事务控制；\n[0024] 参考消息处理模块，用于指示所述消息处理模块在即将发送的参考消息中包含指定的接收者地址列表；和/或，\n[0025] 从消息处理模块接收已经解码的与包含接收者地址列表的参考消息，并进行分发处理。\n[0026] 本发明的有益效果如下：本发明通过在发送的参考消息中包含接收者地址列表，并由分发服务器或用户代理进行分发参考消息，实现了仅发送一个参考消息就可以指示多个接收者触发指定的会话初始协议消息。而不必一一发送参考消息，这样大大提高了效率，节省了网络资源。另外还通过发送的参考消息中指示触发的会话初始协议消息携带指定的接收者列表，实现了仅触发一个会话初始协议消息就可以让多个接收者收到该消息，由网络侧的分发服务器对所触发的会话初始协议消息进行分发必终端侧一一发送各会话初始协议消息效率更高。一般的，通过在参考消息的消息体内容处理方式中指示是否携带相应内容，使被触发的会话初始协议消息可以携带指定的消息体内容，如SDP信息、MESSAGE消息体的正文等等，克服了目前的参考消息只能指定所触发的会话初始协议方法和头字段参数的不足。\n附图说明\n[0027] 图1为现有技术中REFER消息交互流程图；\n[0028] 图2为本发明第一实施例REFER消息的基本流程图；\n[0029] 图3为本发明第一实施例REFER消息传送的消息交互流程图；\n[0030] 图4为本发明第三实施例REFER消息传送的消息交互流程图；\n[0031] 图5为本发明用户代理的内部模块示意图。\n具体实施方式\n[0032] 第一实施例描述了通过分发服务器向多个接收者传送REFER参考消息的过程。参照图2，该图是本发明中REFER消息的基本流程图，主要包括如下步骤：\n[0033] 步骤201，分发服务器(REFER URI-list service)接收到第一用户代理UA1发送的包含接收者列表(URI-list)的REFER参考消息。分发服务器实际上也是一种SIP用户代理(User Agent)。\n[0034] 步骤202，分发服务器将REFER参考消息分别发送给接收者列表中的各个地址URI。\n[0035] 步骤203，接收到分发服务器所分发的REFER参考消息的第二用户代理等发送相应的SIP会议初始协议消息。\n[0036] 下面详细描述REFER参考消息的传送过程，参照图3，主要包括如下步骤：\n[0037] 步骤301，第一用户代理UA1向分发服务器(REFER URI-list service)发送REFER参考消息。REFER参考消息的部分内容举例如下：\n[0038] REFER sip:list-service.example.com；gruu；opaque＝hha9s8d-999a SIP/2.0[0039] Refer-To：sip:conf-123@shenzhen.example.com\n[0040] Refer-Sub：false\n[0041] Require：recipient-list-refer，norefersub\n[0042] Content-Type：application/resource-lists+xml\n[0043] Content-Disposition：recipient-list\n[0044] \n[0045] 本发明中为了简明起见，在消息的例子里都省略了一些消息内容。上述REFER参考消息的请求行中的请求地址(Request-URI)为分发服务器的SIP地址，如“sip:list-service.example.com”，并且通过“gruu”参数保证该REFER参考消息不会被分叉，关于GRUU(Globally Routable User Agent URIs)可参考相应的IETF规范，本发明的其他包含列表的REFER参考消息均可采用GRUU保证该REFER参考消息不会被分叉，为简单起见下面的消息例子中就不再包含“gruu”参数了。Refer-To头字段中包含的地址为第四用户代理UA4的地址，本实施例中是一个会议服务器的地址，如“sip:conf-123@shenzhen.example.com”。该参考消息的消息体中包含接收者列表，相应消息体的多用途互联网邮件扩展(MIME，Multipurpose Internet Mail Extensions)内容类型Content-Type为“application/resource-lists+xml”，内 容 处 理 方 式 Content-Disposition 为“recipient-list”，指示该参考消息应当要向该消息体的接收者列表进行分发。另外在SIP的头字段Require中还可以包含“recipient-list-refer”，以指示接收该消息的用户代理需要具有处理带有接收者列表的参考消息的能力。还有可以在REFER参考消息中增加不产生订阅的指示，即在Refer-Sub头字段中设置“false”值，在SIP的头字段Require中增加指示“norefersub”，表示需要处理Refer-Sub头字段压制参考消息产生默认订阅的能力。\n[0046] 步骤302，分发服务器接收到该REFER参考消息后，向第一用户代理UA1返回\n202Accepted响应。\n[0047] 步骤303和304，分发服务器根据REFER参考消息中接收者列表内容的内容处理方式Content-Disposition中的指示即“recipient-list”向接收者列表对应的地址分发相应的REFER参考消息，所分发的REFER参考消息的部分内容举例如下：\n[0048] REFER sip:bill@example.com SIP/2.0\n[0049] Refer-To：sip:conf-123@shenzhen.example.com\n[0050] 与第一用户代理UA1发送的REFER参考消息相比，分发服务器所分发的每个REFER参考消息中的请求地址(Request-URI)为接收者列表中的接收者的地址如“sip:bill@example.com”，而Refer-To头字段、Refer-Sub头字段和Require头字段与第一用户代理UA1发送的REFER参考消息中的相同，所分发的REFER参考消息中也不再包含接收者列表。\n[0051] 步骤305和306，接收者如第二用户代理UA2和第三用户代理UA3等收到所分发的REFER参考消息后，分别向分发服务器返回202Accepted响应。\n[0052] 步骤307和308，接收者如第二用户代理UA2和第三用户代理UA3等向Refer-To头字段指示的地址如会议中心(Foucs)“sip:conf-123@shenzhen.example.com”发送INVITE请求，后续的200 OK和ACK等消息此处为简明起见进行了省略。\n[0053] 在REFER参考消息除了缺省的INVITE请求，还可以在Refer-To头字段中指明其他的SIP请求方法，如下：\n[0054] Refer-To：[0055] 则最终的各接收者都会向目标地址“sip:tom@example.com”订阅(SUBSCRIBE)其呈现信息(presence)。\n[0056] 第二实施例描述了通过嵌套REFER参考消息来实现让多个接收者向同一目标发送SIP请求的方法。\n[0057] 步骤401，第一用户代理UA1向第二用户代理UA2发送嵌套REFER参考消息。嵌套REFER参考消息的部分内容举例如下：\n[0058] REFER sip:list-service.example.com SIP/2.0\n[0059] Refer-To：[0061] Refer-Sub：false\n[0062] Require：multiple-refer，norefersub\n[0063] Content-Type：application/resource-lists+xml\n[0064] Content-Disposition：recipient-list\n[0065] Content-ID：cn35t8jf02@example.com\n[0066] \n[0067] 上述REFER参考消息中的请求地址为第二用户代理UA2的地址如\n“sip:list-service.example.com”，在Refer-To头字段 中包含一 个内容标识 如“cid:cn35t8jf02@example.com”与消息体内容中的接收者列表的内容标识头字段Content-ID中相对应，同时还包括指示接收者要发送的SIP请求方法为method＝REFER？Refer-To＝″sip:conf-123@shenzhen.example.com″，即向接收者发送SIP REFER请求，并且该请求的Refer-To头字段的值为″sip:conf-123@shenzhen.example.com″。由于上述REFER参考消息还包含另外一个REFER参考消息，所以称为嵌套REFER参考消息。\n[0068] 还可以将所嵌套的REFER参考消息放在接收者列表地址后面，这更加符合REFER参考消息的语义，但需要在每个接收者列表地址后面都要写一遍，举例如下：\n[0069] REFER sip:list-service.example.com SIP/2.0\n[0070] Refer-To：\n[0071] Refer-Sub：false\n[0072] Require：multiple-refer，norefersub\n[0073] Content-Type：application/resource-lists+xml\n[0074] Content-Disposition：recipient-list\n[0075] Content-ID：cn35t8jf02@example.com\n[0076] \n[0077] 当然在uri参数中的有些特殊字符要用十六进制表示，如“Refer-To”后的等号(＝)可以用％3D表示，“Refer-To”对应地址的双引号(″)可以用％22表示，地址中的“@”可以用“％40”表示，“Refer-To”前的“？”可以用％3F表示，，此处为易读起见直接在例子中使用了原字符。实际的表达方式举例如下：\n[0078] \n[0080] 还可以采用和现有的Refer-To头字段中次序相对应的表达方式，举例如下：\n[0081] \n[0083] 上述表达方式与以下的Refer-To头字段等价：\n[0084] Refer-To：[0086] 步骤402，第二用户代理UA2接收到上述REFER参考消息后，根据Refer-To头字段中的指示和消息体中的相应接收者列表向对应的每个地址分别发送相应的REFER参考消息，所分发的REFER参考消息举例如下：\n[0087] REFER sip:bill@example.com SIP/2.0\n[0088] Refer-To：sip:conf-123@shenzhen.example.com\n[0089] 可见与第一实施例取得了相同的技术效果，后续步骤与第一实施例基本类似，此处不再赘述。\n[0090] 第三实施例描述了使接收REFER参考消息的用户代理发送包含地址列表的SIP INVITE请求的方法。如一个日程服务器在设定的时间或事件发生时，向相应的用户发送一个召开临时会议的指示，其中会议参加者的名单列表也已经事先设置在了日程服务器中。\n参照图4，主要包括以下步骤：\n[0091] 步骤401，第一用户代理UA1(如日程服务器)向第二用户代理UA2发送REFER参考消息。REFER参考消息的部分内容举例如下：\n[0092] REFER sip:bill@example.com SIP/2.0\n[0093] Refer-To：[0094] Content-Type：application/resource-lists+xml\n[0095] Content-Disposition：refer-with；recipient-list\n[0096] \n[0097] 其中REFER参考消息的请求地址为第二用户代理UA2的地址如“sip:bill@example.com”，在Refer-To头字段中包含目标地址，如会议服务器(conference server)地址“sip:conf-fact@example.com”，同时在消息体的接收者列表内容的内容处理头字段中包含被参考消息触发的SIP请求要携带该内容的指示如“refer-with”或“referred-with”，可以简称为携带指示，另外还包含其他的指示如“recipient-list”，这些其他的指示应当在被参考消息触发的SIP请求中的消息体内容中保留，而上述的携带指示“refer-with”则不必保留。但是在嵌套的REFER参考消息所触发的REFER参考消息中应当保留原来的携带指示。\n[0098] 步骤402，第二用户代理UA2收到参考消息后返回202Accepted响应。\n[0099] 步骤403，第二用户代理UA2根据上述的REFER参考消息发送包含接收者列表的相应SIP请求消息，举例如下：\n[0100] INVITE sip:conf-fact@example.com SIP/2.0\n[0101] Require：recipient-list-invite\n[0102] Content-Type：multipart/mixed；boundary＝″boundary1″\n[0103] --boundary1\n[0104] (SDP)\n[0105] --boundary1\n[0106] Content-Type：application/resource-lists+xml\n[0107] Content-Disposition：recipient-list\n[0108] \n[0109] 相应SIP请求消息为INVITE，请求地址为目标地址如会议服务器的地址“sip:conf-fact@example.com”，另外还包括REFER参考消息的Refer-To头字段中地址后的头字段参数如“Require：recipient-list-invite”，在消息体中则根据上述的内容处理方式“refer-with”指示，将接收者列表的相应内容也包含在SIP请求消息中。一般SIP INVITE请求消息体中还包括SDP信息，所以总的消息体内容类型采用了多部分混合“multipart/mixed”的MIME(Multipurpose Internet Mail Extensions)类型。在接收者列表的地址入口中还可以包含“copyControl”属性，表示该地址是该请求的主送地址“to”，还是抄送地址“cc”或密送地址“bcc”，以及包含是否匿名的属性“anonymize”，接收者地址列表举例如下：\n[0110] \n[0111] 步骤404，会议服务器收到上述SIP INVITE请求消息后，返回200OK响应，在第二用户代理UA2返回ACK后可以建立相应的会话，为简单起见流程图中进行了省略。\n[0112] 步骤405和406，会议服务器向上述SIP INVITE请求的消息体中接收者列表的各地址分别发送相应的SIP INVITE请求，邀请各接收者加入会议，所分发的SIP INVITE请求消息举例如下：\n[0113] INVITE sip:bill@example.com SIP/2.0\n[0114] Contact：；isfocus\n[0115] Require：recipient-list-invite\n[0116] Content-Type：multipart/mixed；boundary＝″boundary1″\n[0117] --boundary1\n[0118] (SDP)\n[0119] --boundary1\n[0120] Content-Type：application/resource-lists+xml\n[0121] Content-Disposition：recipient-list-history；handling＝optional[0122] \n[0123] \n[0124] 所分发的SIP INVITE请求消息中可以包含接收者列表，当然相应的内容处理方式中的指示如“recipient-list-history”和“handling＝optional”表示对该列表可以仅当作一种历史提示信息，说明该INVITE消息的分发情况。所分发的SIP INVITE请求消息中也可以不包括接收者列表，只要包含SDP(Session Description Protocol)内容即可。另外会议服务器所分发的SIPINVITE请求消息中Contact头字段中为实际会议中心(Focus)的地址，并且通过特性标签“isfocus”指示发送请求的是个会议中心。\n[0125] 步骤407和408，收到分发的SIP INVITE消息的第三用户代理UA3和第四用户代理UA4等向会议服务器返回200OK响应，随后会建立相应的会议会话。\n[0126] 还可以利用本实施例的方法，指示用户发送SIP MESSAGE到多个目标。其中REFER参考消息中的Refer-To中指定请求方法为MESSAGE，Refer-To的内容举例如下：\n[0127] Refer-To：\n[0128] 在消息体中也类似包含接收者列表，接收该REFER参考消息的用户代理将该列表携带在发向分发服务器地址“sip:list-service.example.com”的MESSAGE的消息体中，当然该MESSAGE的消息体一般还包括消息的正文内容，可以是文本、图像等任意的MIME类型。\n分发服务器则将该MESSAGE消息分发给接收者列表中的各个地址。\n[0129] 上述三个实施例中，如果在初始发送的REFER参考消息中包含Referred-By头字段以及消息体中有相应的签名内容，则在分发的REFER参考消息或分发的其他SIP请求消息中应当复制Referred-By头字段和相应的签名内容。最终接收到SIP请求消息的用户代理可以对其所包含的Referred-By头字段和相应的签名内容进行认证鉴权。关于Referred-By头字段可以参见规范RFC3892。由于Referred-By头字段相应的签名内容中一般都包含Refer-To头字段的原内容和签名内容，则对上述第二实施例，由于Refer-To头字段实际对应了消息体中的接收者列表，因此需要包含列表内容及其加密后的签名内容，信息量较大，而且如何接收者列表中如果有些地址是密送“bcc”或者匿名，则无法向最终接收者提供原始的接收者列表，即无法对签名内容进行验证，因此可以简单的只包含Referred-By头字段即可。或者签名中不包含Refer-To头字段的内容，只要让最终接收者能认证最初发参考消息是谁发出的以及发出的日期时间等即可。\n[0130] 第四实施例描述了如何指示REFER参考消息的接收者按指定的SDP参数发起呼叫。\n[0131] 步骤501，第一用户代理UA1发送REFER参考消息，其消息体中包含SDP参数内容。\n消息内容举例如下：\n[0132] REFER sip:bill@example.com SIP/2.0\n[0133] Refer-To：\n[0134] Content-Type：application/sdp\n[0135] Content-Disposition：referred-with\n[0136] m＝message 0TCP/MSRP*\n[0137] 上述消息的消息体中包含内容类型Content-Type为“application/sdp”的SDP内容，其内容处理方式为“referred-with”，指示在REFER参考消息所触发的请求中要携带该内容。当然对于上述SDP内容如“m＝message 0TCP/MSRP*”，在发送所触发的请求如INVITE时可以增加或修改该SDP内容，即该SDP内容仅仅作为参考和指示信息，并不是强制必须携带该SDP内容。通常在REFER参考消息中携带的SDP内容比较简单，可以只指定希望建立的会话类型如MSRP或RTP等，而不必包含具体的通信端口号等，因为这些需要接收REFER参考消息的用户代理自己来决定。如在发送的INVITE请求中可以补充SDP的其他内容，如版本号、端口号等等，修改后的SDP完整内容举例如下：\n[0138] v＝0\n[0139] o＝alice 2890844557 2890844559 IN IP4 alicepc.example.com\n[0140] s＝-\n[0141] c＝IN IP4 alicepc.example.com\n[0142] t＝00\n[0143] m＝message 7777TCP/MSRP*\n[0144] a＝accept-types:text/plain\n[0145] a＝path:msrp://alicepc.example.com:7777/iau39soe2843z；tcp\n[0146] 在向Refer-To头字段中指定的目标地址发送的INVITE请求中携带上述完整的SDP内容。本实施例的方法也可以应用于以上几个其他的实施例中。\n[0147] 第五实施例描述了通过REFER参考消息指示分发服务器来向多个目标地址发送指定内容的MESSAGE消息。\n[0148] 首先第一用户代理发送REFER参考消息，指定触发的会话初始协议方法为MESSAGE，消息体中包括接收者地址列表和MESSAGE的消息正文，并在正文的内容处理方式中包含携带指示如“refer-with”。REFER参考消息的部分内容举例如下：\n[0149] REFER sip:list-service.example.com SIP/2.0\n[0150] Refer-To：\n[0151] Refer-Sub：false\n[0152] Require：multiple-refer，norefersub\n[0153] Content-Type：multipart/mixed；boundary＝″boundary1″\n[0154] --boundary1\n[0155] Content-Type：text/plain\n[0156] Content-Disposition：refer-with\n[0157] Hello World！\n[0158] --boundary1\n[0159] Content-Type：application/resource-lists+xml\n[0160] Content-Disposition：recipient-list\n[0161] Content-ID：cn35t8jf02@example.com\n[0162] \n[0163] 在上述参考消息的Refer-To头字段中包含与接收者地址列表内容相对应的内容标识，在消息体正文内容如“Hello World！”的内容处理方式中包含携带指示如“refer-with”。\n[0164] 第二用户代理如分发服务器“sip:list-service.example.com”收到该参考消息后，对接收者列表中的每个地址分别发送相应的MESSAGE消息，并且在消息体中携带原参考消息中的带有携带指示的消息体正文内容。分发的MESSAGE消息部分内容举例如下：\n[0165] MESSAGE sip:bill@example.com SIP/2.0\n[0166] Content-Type：text/plain\n[0167] Hello World！\n[0168] 如图5所示，本发明的用户代理包含基本的三个模块：传输处理模块S53，消息处理模块S52和参考消息处理模块S51。其中传输处理模块用于接收上层的消息处理模块发来的SIP消息，并采用相应的承载协议如UDP(User Datagram Protocol)或TCP(Transmission Control Protocol)将其发送出去。消息处理模块用于对SIP消息进行编解码、以及事务控制等。参考消息处理模块用于进行与参考消息的相关处理等，将与参考消息相关的消息通过消息处理模块编解码并管理相应事务收发消息。参考消息处理模块可以指示所述消息处理模块在即将发送的参考消息中包含Refer-To头字段，指定目标地址和相应参数，以及在消息体中包含接收者列表等；或者从消息处理模块接收已经解码的与参考消息相关的消息，并进行相应处理，如向消息体中包含的接收者列表各个地址分发参考消息等。参考消息处理模块还可以与认证鉴权模块S511、嵌套处理模块S512、内容携带处理模块S513、分发处理模块S514等进行交互，完成相应的功能。如通过分发处理模块获取参考消息中的接收者列表，并将参考消息或所触发的SIP请求消息调用消息处理模块分发给接收者列表中各个地址，最终通过传输处理模块用UDP或TCP等协议发送出去。嵌套处理模块用于生成和解析嵌套的参考消息，并根据嵌套的参考消息产生相应的参考消息，通过调用消息处理模块发送出去。\n[0169] 参考消息处理模块还可以通过认证鉴权模块在即将发送的参考消息中增加签名信息，或对收到的SIP请求消息中包含的Referred-By头字段和签名内容进行认证或鉴权等。另外通过内容携带处理模块在要发送的参考消息中增加相应的消息体内容并在内容处理方式中设置应当在所触发的消息中携带该内容的指示，或者在参考消息所触发的SIP请求消息中携带已经被其修改的原参考消息中的消息体内容。\n[0170] 用户代理实际上一般同时具有上述实施例中UA1、UA2和UA3等发送方和接收方的处理能力，可以位于用户终端如手机、个人计算机等中，也可以位于应用服务器中。\n[0171] 显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。