[0085] ?Refer-To=″sip:conf-123@shenzhen.example.com″;method=REFER>[0086] 步骤402,第二用户代理UA2接收到上述REFER参考消息后,根据Refer-To头字段中的指示和消息体中的相应接收者列表向对应的每个地址分别发送相应的REFER参考消息,所分发的REFER参考消息举例如下:
[0087] REFER sip:bill@example.com SIP/2.0
[0088] Refer-To:sip:conf-123@shenzhen.example.com
[0089] 可见与第一实施例取得了相同的技术效果,后续步骤与第一实施例基本类似,此处不再赘述。
[0090] 第三实施例描述了使接收REFER参考消息的用户代理发送包含地址列表的SIP INVITE请求的方法。如一个日程服务器在设定的时间或事件发生时,向相应的用户发送一个召开临时会议的指示,其中会议参加者的名单列表也已经事先设置在了日程服务器中。参照图4,主要包括以下步骤:
[0091] 步骤401,第一用户代理UA1(如日程服务器)向第二用户代理UA2发送REFER参考消息。REFER参考消息的部分内容举例如下:
[0092] REFER sip:bill@example.com SIP/2.0
[0093] Refer-To:[0094] Content-Type:application/resource-lists+xml
[0095] Content-Disposition:refer-with;recipient-list
[0096]
[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参考消息中应当保留原来的携带指示。
[0098] 步骤402,第二用户代理UA2收到参考消息后返回202Accepted响应。
[0099] 步骤403,第二用户代理UA2根据上述的REFER参考消息发送包含接收者列表的相应SIP请求消息,举例如下:
[0100] INVITE sip:conf-fact@example.com SIP/2.0
[0101] Require:recipient-list-invite
[0102] Content-Type:multipart/mixed;boundary=″boundary1″
[0103] --boundary1
[0104] (SDP)
[0105] --boundary1
[0106] Content-Type:application/resource-lists+xml
[0107] Content-Disposition:recipient-list
[0108]
[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”,接收者地址列表举例如下:
[0110]
[0111] 步骤404,会议服务器收到上述SIP INVITE请求消息后,返回200OK响应,在第二用户代理UA2返回ACK后可以建立相应的会话,为简单起见流程图中进行了省略。
[0112] 步骤405和406,会议服务器向上述SIP INVITE请求的消息体中接收者列表的各地址分别发送相应的SIP INVITE请求,邀请各接收者加入会议,所分发的SIP INVITE请求消息举例如下:
[0113] INVITE sip:bill@example.com SIP/2.0
[0114] Contact:;isfocus
[0115] Require:recipient-list-invite
[0116] Content-Type:multipart/mixed;boundary=″boundary1″
[0117] --boundary1
[0118] (SDP)
[0119] --boundary1
[0120] Content-Type:application/resource-lists+xml
[0121] Content-Disposition:recipient-list-history;handling=optional[0122]
[0123]
[0124] 所分发的SIP INVITE请求消息中可以包含接收者列表,当然相应的内容处理方式中的指示如“recipient-list-history”和“handling=optional”表示对该列表可以仅当作一种历史提示信息,说明该INVITE消息的分发情况。所分发的SIP INVITE请求消息中也可以不包括接收者列表,只要包含SDP(Session Description Protocol)内容即可。另外会议服务器所分发的SIPINVITE请求消息中Contact头字段中为实际会议中心(Focus)的地址,并且通过特性标签“isfocus”指示发送请求的是个会议中心。
[0125] 步骤407和408,收到分发的SIP INVITE消息的第三用户代理UA3和第四用户代理UA4等向会议服务器返回200OK响应,随后会建立相应的会议会话。
[0126] 还可以利用本实施例的方法,指示用户发送SIP MESSAGE到多个目标。其中REFER参考消息中的Refer-To中指定请求方法为MESSAGE,Refer-To的内容举例如下:
[0127] Refer-To:
[0128] 在消息体中也类似包含接收者列表,接收该REFER参考消息的用户代理将该列表携带在发向分发服务器地址“sip:list-service.example.com”的MESSAGE的消息体中,当然该MESSAGE的消息体一般还包括消息的正文内容,可以是文本、图像等任意的MIME类型。分发服务器则将该MESSAGE消息分发给接收者列表中的各个地址。
[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头字段的内容,只要让最终接收者能认证最初发参考消息是谁发出的以及发出的日期时间等即可。
[0130] 第四实施例描述了如何指示REFER参考消息的接收者按指定的SDP参数发起呼叫。
[0131] 步骤501,第一用户代理UA1发送REFER参考消息,其消息体中包含SDP参数内容。消息内容举例如下:
[0132] REFER sip:bill@example.com SIP/2.0
[0133] Refer-To:
[0134] Content-Type:application/sdp
[0135] Content-Disposition:referred-with
[0136] m=message 0TCP/MSRP*
[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完整内容举例如下:
[0138] v=0
[0139] o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
[0140] s=-
[0141] c=IN IP4 alicepc.example.com
[0142] t=00
[0143] m=message 7777TCP/MSRP*
[0144] a=accept-types:text/plain
[0145] a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp
[0146] 在向Refer-To头字段中指定的目标地址发送的INVITE请求中携带上述完整的SDP内容。本实施例的方法也可以应用于以上几个其他的实施例中。
[0147] 第五实施例描述了通过REFER参考消息指示分发服务器来向多个目标地址发送指定内容的MESSAGE消息。
[0148] 首先第一用户代理发送REFER参考消息,指定触发的会话初始协议方法为MESSAGE,消息体中包括接收者地址列表和MESSAGE的消息正文,并在正文的内容处理方式中包含携带指示如“refer-with”。REFER参考消息的部分内容举例如下:
[0149] REFER sip:list-service.example.com SIP/2.0
[0150] Refer-To:
[0151] Refer-Sub:false
[0152] Require:multiple-refer,norefersub
[0153] Content-Type:multipart/mixed;boundary=″boundary1″
[0154] --boundary1
[0155] Content-Type:text/plain
[0156] Content-Disposition:refer-with
[0157] Hello World!
[0158] --boundary1
[0159] Content-Type:application/resource-lists+xml
[0160] Content-Disposition:recipient-list
[0161] Content-ID:cn35t8jf02@example.com
[0162]
[0163] 在上述参考消息的Refer-To头字段中包含与接收者地址列表内容相对应的内容标识,在消息体正文内容如“Hello World!”的内容处理方式中包含携带指示如“refer-with”。
[0164] 第二用户代理如分发服务器“sip:list-service.example.com”收到该参考消息后,对接收者列表中的每个地址分别发送相应的MESSAGE消息,并且在消息体中携带原参考消息中的带有携带指示的消息体正文内容。分发的MESSAGE消息部分内容举例如下:
[0165] MESSAGE sip:bill@example.com SIP/2.0
[0166] Content-Type:text/plain
[0167] Hello World!
[0168] 如图5所示,本发明的用户代理包含基本的三个模块:传输处理模块S53,消息处理模块S52和参考消息处理模块S51。其中传输处理模块用于接收上层的消息处理模块发来的SIP消息,并采用相应的承载协议如UDP(User Datagram Protocol)或TCP(Transmission Control Protocol)将其发送出去。消息处理模块用于对SIP消息进行编解码、以及事务控制等。参考消息处理模块用于进行与参考消息的相关处理等,将与参考消息相关的消息通过消息处理模块编解码并管理相应事务收发消息。参考消息处理模块可以指示所述消息处理模块在即将发送的参考消息中包含Refer-To头字段,指定目标地址和相应参数,以及在消息体中包含接收者列表等;或者从消息处理模块接收已经解码的与参考消息相关的消息,并进行相应处理,如向消息体中包含的接收者列表各个地址分发参考消息等。参考消息处理模块还可以与认证鉴权模块S511、嵌套处理模块S512、内容携带处理模块S513、分发处理模块S514等进行交互,完成相应的功能。如通过分发处理模块获取参考消息中的接收者列表,并将参考消息或所触发的SIP请求消息调用消息处理模块分发给接收者列表中各个地址,最终通过传输处理模块用UDP或TCP等协议发送出去。嵌套处理模块用于生成和解析嵌套的参考消息,并根据嵌套的参考消息产生相应的参考消息,通过调用消息处理模块发送出去。
[0169] 参考消息处理模块还可以通过认证鉴权模块在即将发送的参考消息中增加签名信息,或对收到的SIP请求消息中包含的Referred-By头字段和签名内容进行认证或鉴权等。另外通过内容携带处理模块在要发送的参考消息中增加相应的消息体内容并在内容处理方式中设置应当在所触发的消息中携带该内容的指示,或者在参考消息所触发的SIP请求消息中携带已经被其修改的原参考消息中的消息体内容。
[0170] 用户代理实际上一般同时具有上述实施例中UA1、UA2和UA3等发送方和接收方的处理能力,可以位于用户终端如手机、个人计算机等中,也可以位于
应用服务器中。
[0171] 显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明
权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。