CN101355429A - 提供用户代理能力信息的方法及装置 - Google Patents

提供用户代理能力信息的方法及装置 Download PDF

Info

Publication number
CN101355429A
CN101355429A CNA2007101289593A CN200710128959A CN101355429A CN 101355429 A CN101355429 A CN 101355429A CN A2007101289593 A CNA2007101289593 A CN A2007101289593A CN 200710128959 A CN200710128959 A CN 200710128959A CN 101355429 A CN101355429 A CN 101355429A
Authority
CN
China
Prior art keywords
server
ability information
message
user
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CNA2007101289593A
Other languages
English (en)
Inventor
贾江涛
彭程晖
孙谦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CNA2007101289593A priority Critical patent/CN101355429A/zh
Publication of CN101355429A publication Critical patent/CN101355429A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例中公开了一种提供用户代理(UA)能力信息的方法,用于第一服务器向第二服务器提供用户的UA能力信息,所述第一服务器为:能够获取用户的UA能力信息的服务器,所述第二服务器为:不能获取用户的UA能力信息的服务器,该方法包括:第一服务器接收来自于第二服务器的UA能力获取请求,向第二服务器返回响应消息,在所述响应消息中携带所述用户的UA能力信息。本发明实施例中还公开了一种提供UA能力信息的方法和实施本发明所述方法的服务器。应用本发明能够实现向不能得到用户的UA能力信息的服务器提供UA能力信息。

Description

提供用户代理能力信息的方法及装置
技术领域
本发明涉及会话发起协议技术,特别涉及提供用户代理能力信息的方法及装置。
背景技术
在会话发起协议(SIP)中,用户代理(UA,User Agent)就是SIP终端设备,或简称终端设备。例如:用于创建和管理SIP会话的移动电话、多媒体手持设备、个人电脑(PC)、个人数字助理(PDA)等。
同一个用户可以拥有多个公共用户身份,其中,每一个公共用户身份以一个记录地址(AOR,Address of Record)来标识。用户的多个终端设备可以对应于同一个AOR,并通过各自不同的联系统一资源标识符(ContactURI)来区分所述多个终端设备。并且,同一个终端设备可以拥有多个不同的Contact URI。用户、AOR、终端设备、Contact URI之间的关系如下所示:
在通信过程中,UA的能力信息是非常重要的信息。在向用户转发数据或请求时,系统可以根据UA的能力信息来选择对应的接收终端设备;并且,还可以根据UA的能力信息进行代理服务器(Proxy)的路由。例如,假设用户的终端设备1支持视频(video)传输,而用户的终端设备2不支持视频传输,在系统收到的请求消息中指明需要UA支持video时,系统就可以根据UA的能力信息,将该请求消息发送给终端设备1。
现有RFC3840中,存在一种UA将其自身的能力信息发送给其他UA或注册服务器的方法。该方法通过在Contact头中增加描述UA能力信息的参数,并由UA将其自身的能力信息携带于所述增加的参数中,发送给其它UA或注册服务器。UA的能力信息包括UA的能力(capability)和特性(characteristics)等,例如:支持的媒体类型、支持的SIP方法、支持的语言以及支持的事件包等。
本申请的发明人在实现本发明的过程中发现:UA能够采用上述方法将其自身的能力信息发送给其他UA或注册服务器,但是,除注册服务器之外的其他服务器不能获取到UA的能力信息。如:应用服务器(AS)可能需要根据UA的能力信息进行业务提供,Proxy可能需要根据UA的能力信息进行路由处理,但是AS、Proxy等服务器均不能采用上述方法获取到UA的能力信息。
现有RFC3680中,定义了注册(reg)事件包,使得UA或服务器可以通过向注册服务器发送事件包类型为reg事件的订阅(SUBSCRIBE)请求,来向注册服务器订阅其他UA的注册信息。当被订阅者(即被订阅UA)的注册状态发生变化时,订阅者将收到注册服务器发出的关于所述注册状态变化的通知消息。所述通知消息中携带有用户的注册信息(reginfo),包括:用户注册的AOR、Contact URI等与用户的注册状态相关的信息。下面通过一段采用可扩展标记语言(XML)格式表示的注册信息示例,说明现有注册信息中所包含的信息:
<?xml version=″1.0″?>
 <reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
              version=″1″state=″partial″>
  <registration aor=″sip:joe@example.com″id=″a7″state=″active″>
                             //状态为active表示该AOR的状态为:注册
    <contact id=″76″state=″active″event=″registered″duration-registered=″0″>
             <uri>sip:joe@pc34.example.com</uri>  //注册的Contact URI
      </contact>
   </registration>
</reginfo>
本申请的发明人在实现本发明的过程中发现:上述RFC3680中所提供的方法,只能向订阅者提供被订阅UA的注册状态、Contact URI等注册信息,不能向订阅者提供被订阅UA的能力信息。
发明内容
有鉴于此,本发明实施例提出一种提供用户代理能力信息的方法,使服务器能够获取UA能力信息。
本发明实施例还提出另一种提供用户代理能力信息的方法,使服务器能够获取UA能力信息。
本发明实施例还提出一种实施本发明实施例所述方法的第一服务器和第三服务器,使第二服务器和第四服务器能够获取UA的能力信息。
为达到上述目的,本发明实施例的技术方案具体是这样实现的:
一种提供用户代理UA能力信息的方法,用于第一服务器向第二服务器提供用户的UA能力信息,所述第一服务器为:能够获取用户的UA能力信息的服务器,所述第二服务器为:不能获取用户的UA能力信息的服务器,包括:
第一服务器接收来自于第二服务器的UA能力获取请求;
第一服务器根据所述UA能力获取请求生成响应消息,在所述响应消息中携带所述第一服务器获取的用户的UA能力信息;
第一服务器向第二服务器返回所述响应消息
一种实施本发明实施例上述提供UA能力信息的方法的第一服务器,所述第一服务器为:能够获取用户的UA能力信息的服务器,包括:
第一收发模块,用于接收来自于第二服务器的UA能力获取请求,将所述UA能力获取请求发送给请求处理模块;并用于接收来自于请求处理模块的响应消息,向所述第二服务器返回所述响应消息;
请求处理模块,用于根据来自于第一收发模块的UA能力获取请求,生成相应的响应消息发送给第一收发模块,所述响应消息中携带所述第一服务器获取的用户的UA能力信息。
一种提供UA能力信息的方法,用于第三服务器向第四服务器提供用户的UA能力信息,所述第三服务器为:能够获取用户的UA能力信息的服务器,所述第四服务器为:不能获取用户的UA能力信息的服务器,包括:
第三服务器接收用户通过UA发送的注册请求,所述注册请求中携带有所述UA的UA能力信息以及表示所述注册请求中包含UA能力信息的指示;
第三服务器根据存储的过滤规则以及所述接收的注册请求,生成携带所述UA能力信息的第三方注册请求,向第四服务器发送所述第三方注册请求。
一种实施本发明实施例上述提供UA能力信息的方法的第三服务器,所述第三服务器为:能够获取用户的UA能力信息的服务器,包括:
第二收发模块,用于接收用户通过UA发送的、携带有所述UA的UA能力信息的注册请求,将所述注册请求发送给第三方注册模块;并用于接收来自于第三方注册模块的第三方注册请求,向第四服务器发送所述第三方注册请求;
第三方注册模块,用于根据来自于第二收发模块的注册请求以及存储的过滤规则,生成携带所述UA能力信息的第三方注册请求,将所述第三方注册请求发送给第二收发模块。
由上述技术方案可见,本发明实施例的第一种提供UA能力信息的技术方案中,通过在第一服务器向第二服务器返回的响应消息中携带UA能力信息,实现了由能够获取UA能力信息的第一服务器向不能获取UA能力信息的第二服务器提供用户的UA能力信息,从而使得第二服务器能够根据获取的UA能力信息选择合适的终端设备进行相关的业务处理。
并且,本发明实施例的第二种提供UA能力信息的技术方案中,通过在第三方注册过程中,由第三服务器将用户的UA能力信息发送给第四服务器,使得原本不能获取UA能力信息的第四服务器获取到UA能力信息,从而使得第四服务器能够根据获取的UA能力信息选择合适的终端设备进行相关的业务处理。
附图说明
图1为本发明实施例一中提供UA能力信息的方法的信令流程示意图;
图2为本发明实施例一中第一服务器的组成结构示意图;
图3为本发明实施例二中提供UA能力信息的方法的信令流程示意图;
图4为本发明实施例二中第三服务器的组成结构示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明作进一步详细说明。
本发明实施例中公开了两种提供UA能力信息的方法。其中,第一种提供UA能力信息的方法是由第一服务器根据来自于第二服务器的UA能力获取请求,向第二服务器返回相应的UA能力信息;第二种提供UA能力信息的方法是由第三服务器根据来自于UA的注册请求,向第四服务器发起第三方注册请求,并通过所述第三方注册请求将UA能力信息发送给第四服务器。上述两种方法的共同特征是:能够获取UA能力信息的服务器将UA能力信息提供给不能获取UA能力信息的服务器。
上述方法中,第一服务器和第三服务器是能够获取UA能力信息的服务器,其中,第一服务器包括注册服务器,第三服务器包括注册服务器或IP多媒体子系统(IMS)中的服务呼叫会话控制功能(S-CSCF)实体等。上述第二服务器和第四服务器是不能获取UA能力信息的服务器,其中,第二服务器包括:AS或Proxy等,第四服务器包括:AS、Proxy或在线状态服务器等。
在上述方法中,第一服务器可以将UA能力信息以及与UA能力信息对应的Contact URI一并发送给第二服务器,类似地,第三服务器也可以将UA能力信息以及与UA能力信息对应的Contact URI一并发送给第四服务器,这样,获取到UA能力信息的第二服务器和第四服务器就可以根据不同UA能力信息与不同Contact URI之间的对应关系进行相应的业务处理。
在上述第一种方法中,第二服务器向第一服务器发送的UA能力获取请求可以是预先定义的一个专用于获取UA能力信息的请求,也可以是对现有SIP协议中已有的消息进行相应的扩展所得到的消息。
例如,可以在现有SUBSCRIBE消息中扩展一个表示请求获取用户的UA能力信息的指示,第二服务器可以向第一服务器发送携带所述指示的SUBSCRIBE消息。此时,第一服务器可以通过NOTIFY消息来回应第二服务器的SUBSCRIBE消息,并根据SUBSCRIBE消息中携带的表示请求获取用户的UA能力信息的指示,将相应用户的UA能力信息携带于所述NOTIFY消息中。进一步地,第一服务器还可以在所述NOTIFY消息中携带表示所述NOTIFY消息中包含UA能力信息的指示,以使第二服务器知道该NOTIFY消息中包含有UA能力信息。
下面通过两个具体实施例对本发明上述两种提供UA能力信息的方法进行详细说明。
实施例一:
在本实施例中,第一服务器为注册服务器、第二服务器为应用服务器。UA通过注册请求将其自身的UA能力信息发送给注册服务器,应用服务器通过向注册服务器订阅用户的注册信息来获取UA的能力信息。
图1为本发明实施例一中提供UA能力信息的方法的信令流程示意图。参见图1,该信令流程包括:
步骤101:UA使用REGISTER消息向注册服务器发送注册请求,并在REGISTER消息中携带其自身的UA能力信息,以及表示该REGISTER消息中包含UA能力信息的指示。
本步骤中,UA可以在REGISTER消息的注册信息的Contact头中携带UA能力信息。本步骤中的REGISTER消息可以使用如下所示的消息格式:
REGISTER sip:example.com SIP/2.0      //SIP方法的类型为REGISTER
From:sip:A@example.com;tag=asd98   //源地址
To:sip:A@example.com                 //目的地址
Call-ID:hh89as0d-asd88jkk@host.example.com    //呼叫标识
CSeq:9987 REGISTER                            //呼叫序号
Max-Forwards:70                               //最大转发次数
Require:pref    //表示该REGISTER消息中包含UA能力信息的指示
Via:SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
Contact:<sip:A@example.com>;      //UA的Contact URI
   audio;video;actor=″msg-taker″;automata;mobility=″fixed″
   ;events=″!presence,message-summary″;language=″en,de″
   ;methods=″INVITE,BYE,OPTIONS,ACK,CANCEL″
                       //以上为所述Contact URI对应的UA能力信息
Content-Length:0
上述Contact头中携带了用户UA的能力信息。其中,
audio,video表明UA支持的媒体特性;
methods参数中的方法表示UA支持的SIP方法,本实施例中包括INVITE,BYE,OPTIONS,ACK,CANCEL;
language=”en,de”表示UA支持的语言类型为英语和德语;
events=″!presence,message-summary″表示UA支持的事件包为presence事件和message-summary事件;
mobility=”fixed”表示该UA为一个fixed类型的终端。
在Contact头中,除了可以携带上述示例中的表示UA能力信息的参数外,还可以携带其他表示UA能力信息的参数。包括:
Application参数,表示设备支持的流媒体应用类型;
Data参数,表示设备所支持的流媒体数据的类型;
Control参数,表示作为UA所支持的流媒体发言控制类型;
text表示UA支持的流媒体文本类型;
message表示业务支持作为流媒体类型的消息;
type表明MIME媒体的类型,用type/subtype字符串的形式表示;
automata表示UA是否作为自动装置(例如,语音邮箱服务器、会议服务器、记录设备功能等)或作为普通参与者;
class表示UA用作商务通信或个人通信设备;
duplex表示UA作为通信设备是否可以同时接收发送消息(full),或某一时间只能接收或发送消息(half),或只能接收消息(recieve-only),或只能发送消息(send-only);
description用来提供UA的文本描述;
event表示支持的事件包,事件包括presence,message-summary,reg,refer,winfo,spirits-user-prof,spirits-INDPs等;
Priority用来指示设备处理呼叫的优先级,包括不紧要(non-urgent),普通(normal),紧要(urgent)和紧急(emergency);
extensions列出了业务可以理解的SIP扩展,如rel100,join,path,replaces,histinfo等;
schemes中提供了业务支持的URI schemes集合;
Actor指明该有效URI的入口类型,包括principal,attendant,msg-taker和information等内容;
isfocus指明UA是否作为会议服务器(所说的焦点),将混合所有到该URI的媒体信息;
mobility表明设备是固定的还是移动的,包括fixed和mobile两种。
在实际应用中,还可以包括许多UA能力参数,具体请参考RFC3840,这里不再一一赘述。
步骤102:注册服务器记录REGISTER消息中携带的UA能力信息,并向UA发送200 OK响应消息。
步骤103:应用服务器向注册服务器发送SUBSCRIBE消息,将SUBSCRIBE消息中Event头中的参数置为reg事件包,来订阅用户的注册信息,并在SUBSCRIBE消息中携带表示请求获取用户的UA能力信息的指示。
本步骤中,应用服务器可以使用Require头的pref参数来指明希望从注册服务器获取UA能力信息,即向注册服务器请求获取用户的UA能力信息。本步骤中的SUBSCRIBE消息可以使用如下所示的消息格式:
SUBSCRIBE sip:A@example.com SIP/2.0
Via:SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
From:sip:app.example.com;tag=123aa9
To:sip:A@example.com
Call-ID:9987@app.example.com
CSeq:9887 SUBSCRIBE
Contact:sip:app.example.com
Event:reg             //事件包类型
Max-Forwards:70
Require:pref          //表示请求获取用户的UA能力信息的指示
Accept:application/reginfo+xml
本步骤中,也可以通过扩展reg事件包的参数来作为所述表示请求获取用户的UA能力信息的指示,从而指明AS希望在所订阅的注册信息包含的内容。例如,可以在reg事件包中携带如下所示参数:
Event:reg;info-type=pref
在上述示例中,使用info-type=pref指示希望注册服务器返回的reginfo信息中包含UA能力信息。
步骤104:注册服务器向应用服务器返回200 OK响应消息。
步骤105:注册服务器向应用服务器发送NOTIFY消息,在该NOTIFY消息中除包括用户的基本注册信息之外,还包括与该用户相关的UA能力信息。
     NOTIFY sip:app.example.com SIP/2.0
     Via:SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
     From:sip:A@example.com;tag=xyzygg
     To:sip:app.example.com;tag=123aa9
     Call-ID:9987@app.example.com
     CSeq:1289 NOTIFY
     Contact:sip:server19.example.com
     Event:reg
     Max-Forwards:70
     Content-Type:application/reginfo+xml
     Content-Length:...
<?xml version=″1.0″?>    //以下是注册信息
<reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
             xmlns:prefs=″urn:ietf:params:xml:ns:reginfo:prefsinfo″
             version=″1″state=″partial″>
 <registration aor=″sip:A@example.com″id=″a7″state=″active″>
  <contact id=″76″state=″active″event=″registered″duration-registered=″0″>
         <uri>sip:A-1@pc34.example.com</uri>    //UA的Contact URI
         <prefs:ua-prefs>audio;video;actor=″msg-taker″;automata//UA能力信息
           ;mobility=″fixed″;events=″!presence,message-summary″
           ;language=″en,de″;methods=″INVITE,BYE,OPTIONS,ACK,CANCEL″
         </prefs:ua-prefs>
    </contact>
   </registration>
</reginfo>
上述NOTIFY消息的<reginfo>和</reginfo>之间的内容为注册信息,其中包含了UA能力信息,如<prefs:ua-prefs>和</prefs:ua-prefs>之间的内容所示。在上述示例中,UA能力信息与contact中的参数信息一一对应。
其中,audio表示UA支持audio媒体类型,video表示UA支持video媒体类型;methods参数中的方法表示UA支持的SIP方法,包括INVITE,BYE,OPTIONS,ACK,CANCEL;language=”en,de”表示UA支持的语言类型为英语和德语;events=″!presence,message-summary″表示UA支持的事件包为presence事件和message-summary事件;mobility=”fixed”表示该UA为一个fixed类型的终端;automata表示UA是否作为自动装置(例如:语音邮箱服务器、会议服务器、记录设备功能等)或普通参与者。
在多终端情况下,同一个用户有多个终端设备对应于同一个AOR,这多个终端设备通过各自不同的Contact URI区分,而每个终端设备的UA有不同的UA能力信息。对于不同的Contact URI,其对应的UA能力信息可能不同。下面以两个不同的Contact URI为例,说明如何在注册信息reginfo中携带UA能力信息:
<?xml version=″1.0″?>
   <reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
            xmlns:prefs=″urn:ietf:params:xml:ns:reginfo:prefsinfo″
            version=″1″state=″partial″>
    <registration aor=″sip:A@example.com″id=″a7″state=″active″>
      <contact id=″76″state=″active″event=″registered″duration-registered=″0″>
        <uri>sip:A-1@pc34.example.com</uri>
        <prefs:ua-prefs>audio;video;actor=″msg-taker″;automata
         ;mobility=″fixed″;events=″!presence,message-summary″
         ;language=″en,de″;methods=″INVITE,BYE,OPTIONS,ACK,CANCEL″
       </prefs:ua-prefs>
     </contact>
    <contact id=″79″state=″active″event=″registered″duration-registered=″320″>
       <uri>sip:A-2@mobile.example.com</uri>
     <prefs:ua-prefs>audio;video;automata;mobility=″mobile″
       ;events=″!presence,message-summary″;language=″en,de″
       ;methods=″INVITE,BYE,NOTIFY,SUBSCRIBE,ACK,CANCEL″
     </prefs:ua-prefs>
   </contact>
  </registration>
</reginfo>
上述的两个例子中,<prefs>元素作为<contact>元素的子元素,作用范围为:对<contact>元素表示的Contact URI有效。
在单终端多地址的情况下,对于用户的同一个终端设备,可以同时注册多个Contact URI地址与其相关联,此时,UA能力信息表示的是与所述同一个终端设备对应的所有Contact URI的UA能力。这种情况,可以用如下的消息格式来表示:
<?xml version=″1.0″?>
<reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
              xmlns:prefs=″urn:ietf:params:xml:ns:reginfo:prefsinfo″
              version=″1″state=″partial″>
<registration aor=″sip:A@example.com″id=″a7″state=″active″>
 <prefs:ua-prefs>audio;video;actor=″msg-taker″;automata
   ;mobility=″fixed″;events=″!presence,message-summary″;language=″en,de″
   ;methods=″INVITE,BYE,NOTIFY,SUBSCRIBE,ACK,CANCEL″
</prefs:ua-prefs>
<contact id=″76″state=″active″event=″registered″duration-registered=″0″>
      <uri>sip:A-1@pc34.example.com</uri>
</contact>
<contact id=″79″state=″active″event=″registered″duration-registered=″320″>
      <uri>sip:A-2@PDA.example.com</uri>
</contact>
<contact id=″9″state=″active″event=″registered″duration-registered=″0″>
            <uri>sip:A-3@lab.example.com</uri>
      </contact>
   </registration>
</reginfo>
上述例子中的<prefs>元素为<registration>元素的一个子元素,表示所有<registration>元素下的所有<contact>地址对应的终端设备的UA能力信息一致。
当用户有多个公共用户身份时,注册信息中包括多个<registration>元素,此时表示UA能力信息的元素可能和<registration>属于同一层次。也存在着<registration>和<contact>中都包含prefs信息的情况,这里不再赘述。
上述实施例的reginfo中携带能力信息是通过扩展<prefs:ua-prefs>元素来表示的。在实际应用中,还可以用表示能力信息的每个参数为reginfo中的元素的方法来表示,具体的格式如下:
<?xml version=″1.0″?>
   <reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
            xmlns:prefs=″urn:ietf:params:xml:ns:reginfo:prefsinfo″
            version=″1″state=″partial″>
   <registration aor=″sip:A@example.com″id=″a7″state=″active″>
   <prefs:ua-prefs>
             <prefs:audio>true</prefs:audio>
             <prefs:video>true</prefs:video>
             <prefs:actor>msg-taker</prefs:actor>
             <prefs:methods>
                <prefs:supported>
                   <prefs:ACK/>
                   <prefs:BYE/>
                   <prefs:INVITE/>
                </prefs:supported>
                   </prefs:unsrpported>
                        <prefs:MESSAGE/>
                        </prefs:unsupported>
                   </prefs:methods>
               <prefs:mobility>
                  <prefs:supported>
                      <prefs:mobile/>
                  </prefs:supported>
             </prefs:mobility>
                   ......
    </prefs:ua-prefs>
    <contact id=″76″state=″active″event=″registered″duration-registered=″0″>
          <uri>sip:A-1@pc34.example.com</uri>
    </contact>
    <contact id=″9″state=″active″event=″registered″duration-registered=″0″>
          <uri>sip:A-3@lab.example.com</uri>
    </contact>
   </registration>
</reginfo>
上述示例中,将表示UA能力信息的参数作为reginfo的元素来呈现UA能力信息。
例如:<audio>的取值为true或false,取值true表明UA能力支持audio,取值为false表明UA能力不支持audio。在<methods>中包括<supported>或/和<unsupported>元素,<supported>中的内容表示该UA支持的SIP方法,如ACK,BYE,INVITE方法等;<unsupported>中的内容表示UA不支持的SIP方法,如MESSAGE方法等。
上述实施例的reginfo中携带的UA能力信息还可以通过<unknown-param>元素来表示,具体的格式如下:
<?xml version=″1.0″?>
   <reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
      version=″1″state=″partial″>
   <registration aor=″sip:A@example.com″id=″a7″state=″active″>
   <contact id=″76″state=″active″event=″registered″duration-registered=″0″>
      <uri>sip:A-1@pc34.example.com</uri>
      <unknown-param name=”sip.video”></unknown-param>
      <unknown-param name=”sip.methods”>
          “INVITE,BYE,NOTIFY,SUBSCRIBE,ACK,CANCEL”
      </unknown-param>
      <unknown-param name=”+g.poc.talkburst”></unknown-param>
    ....
    </contact>
    <contact id=″9″state=″active″event=″registered″duration-registered=″0″>
         <uri>sip:A-3@lab.example.com</uri>
    </contact>
    </registration>
</reginfo>
上述示例中,使用<unknown-param>元素和name参数来表示UA支持的能力信息,name的值为表示UA能力的参数,如上述的例子中,name=”sip.video”表示UA支持video;<unknown-param>的内容表示name中指定参数的内容,也可以为空。
步骤106:应用服务器收到NOTIFY消息后,向注册服务器发送200 OK响应消息。
至此,结束实施例一中提供UA能力信息的方法的信令流程示意图。
图2为本发明实施例一中第一服务器的组成结构示意图。参见图2,该第一服务器包括:
第一收发模块210,用于接收来自于第二服务器的UA能力获取请求,将该UA能力获取请求发送给请求处理模块220;并用于接收来自于请求处理模块220的响应消息,向所述第二服务器返回该响应消息;
请求处理模块220,用于根据来自于第一收发模块210的UA能力获取请求,生成相应的响应消息发送给第一收发模块210,所述响应消息中携带所述第一服务器获取的用户的UA能力信息。
图2所示第一服务器中,请求处理模块220中可以进一步包括:
请求消息分析单元221,用于对来自于第一收发模块210的UA能力获取请求进行分析,通知响应消息构造单元222构造与所述UA能力获取请求相应的响应消息;
响应消息构造单元222,用于根据请求消息分析单元221的通知,生成携带用户的UA能力信息以及与UA能力信息对应的Contact URI的响应消息,将所述响应消息发送给第一收发模块210。
进一步地,图2所示第一收发模块210中可以包括:
订阅消息收发单元211,用于接收来自于第二服务器的、携带有表示请求获取用户的UA能力信息的指示的SUBSCRIBE消息,将所述SUBSCRIBE消息发送给订阅消息分析子单元223;并用于接收来自于通知消息构造子单元224的NOTIFY消息,向所述第二服务器返回该NOTIFY消息。
此时,图2所示请求消息分析单元221中可以进一步包括:
订阅消息分析子单元223,用于对来自于订阅消息收发单元211的SUBSCRIBE消息进行分析,在判定所述SUBSCRIBE消息中携带有表示请求获取用户的UA能力信息的指示时,通知通知消息构造子单元224构造与所述SUBSCRIBE消息相应的NOTIFY消息;
所示响应消息构造单元222中可以进一步包括:
通知消息构造子单元224,用于根据订阅消息分析子单元223的通知,生成携带注册信息中携带用户的UA能力信息的NOTIFY消息,将所述NOTIFY消息发送给所述订阅消息收发单元211。
由上述实施例可见,本发明实施例通过在注册服务器向应用服务器返回的NOTIFY消息中携带UA能力信息,实现了UA能力信息和Contact URI信息有机的结合,扩充了注册信息中的内容,并丰富了注册信息中的数据信息。这样,不仅能够使应用服务器获取被订阅者的注册信息,还能够使应用服务器获取被订阅者的UA能力信息,实现了向不能获取UA能力信息的服务器提供UA能力信息。
在AS获取UA能力信息后,可以根据UA能力信息来选择合适的终端。下面通过一个例子进行说明。
在RFC3841中,Accept-Contact头和Reject-Contact头中的参数用来指明被叫UA的特征,应用服务器或proxy能够根据上述特性确定符合该特性的Contact URI地址。
假设AS从注册服务器中获取的注册信息中所包含的用户A的UA能力信息如下所示:
<?xml version=″1.0″?>
   <reginfo xmlns=″urn:ietf:params:xml:ns:reginfo″
            xmlns:prefs=″urn:ietf:params:xml:ns:reginfo:prefsinfo″
            version=″1″state=″partial″>
   <registration aor=″sip:A@example.com″id=″a7″state=″active″>
     <contact id=″76″state=″active″event=″registered″duration-registered=″0″q=″0.8″>
         <uri>sip:A-1@pc34.example.com</uri>
         <prefs:ua-prefs>audio;video;actor=″msg-taker″;automata;mobility=″fixed″
             ;events=″!presence,message-summary″;language=″en,de″
             ;methods=″INVITE,BYE,OPTIONS,ACK,CANCEL″
         </prefs:ua-prefs>
</contact>
<contact id=″79″state=″active″event=″registered″duration-registered=″0″q=″0.5″>
       <uri>sip:A-2@mobile.example.com</uri>
       <prefs:ua-prefs>audio;video;automata;mobility=″mobile″
           ;events=″!presence,message-summary″;language=″en,de″
           ;methods=″INVITE,BYE,NOTIFY,SUBSCRIBE,ACK,CANCEL″
         </prefs:ua-prefs>
</contact>
 </registration>
</reginfo>
当AS收到一个接收方为A@example.com的INVITE请求、且该请求消息中包括如下内容时:
Accept-Contact:*;mobility=″mobile″;methods=″INVITE″;require
表明呼叫者希望被叫方A的UA满足:mobility=″mobile″、methods=″INVITE″这两个条件。AS根据上述reginfo信息中的UA能力信息,选择Contact URI为sip:A-2@mobile.example.com为被叫者的接收地址。
当请求消息中没有指明被叫方的UA特征信息或者指定的特征信息在注册信息中没有对应的Contact URI时,应用服务器可以根据<Contact>元素中的q参数来确定被叫的Contact URI地址。通常,选择q值大的Contact URI作为联系地址。在上述例子中,如果这种情况发生,AS将选择q=”0.8”的Contact URI:sip:A-1@mobile.example.com作为被叫者的接收地址。
当AS收到一个接收方为A@example.com的MESSAGE请求,且根据终端A的UA能力信息中的methods方法中的参数值,发现A不支持MESSAGE方法时,AS将产生一个405 Method Not Allowed错误响应给MESSAGE消息的请求方。
除了上述应用方式之外,AS还可以根据获取的UA能力信息向UA发送欢迎通知。如对于methods参数中包括MESSAGE方法的终端,使用如下的格式的欢迎通知:
MESSAGE sip:A@pc34.example.com SIP/2.0
Via:SIP/2.0/UDP app.example.com;branch=z9hG4bKnash8ds
From:sip:app.example.com;tag=123aa10
To:sip:A@example.com
Call-ID:9988@app.example.com
CSeq:82779 MESSAGE
Max-Forwards:70
Content-Type:text/plain
Content-Length:...
Welcome to the app service!
对于不支持MESSAGE方法的终端,可以通过其它方式来通知,如SMS,MMS等。
除了上述欢迎通知外,AS还可以根据获取的UA能力信息,来确定UA的状态,如在能力信息中包含automata,在通知用户时,可以通知用户的注册状态为自动服务状态;对于AS获取的信息为请求转移的状态,将通知用户的所有呼叫将被转移的提示。
下面对本发明提供的通过第三方注册的方式向服务器提供UA能力信息的方法进行说明。
实施例二:
在本实施例中,第一服务器为S-CSCF、第二服务器为应用服务器。UA通过注册请求将其自身的UA能力信息发送给S-CSCF,S-CSCF根据存储的过滤规则向应用服务器发起第三方注册请求,在所述第三方注册请求种将UA能力信息发送给应用服务器。
图3为本发明实施例二中提供UA能力信息的方法的信令流程示意图。参见图3,该信令流程包括:
步骤301:UA使用REGISTER消息向S-CSCF发送注册请求,并在REGISTER消息中携带其自身的UA能力信息,以及表示该REGISTER消息中包含UA能力信息的指示。
与实施例一相同,UA可以在REGISTER消息的注册信息的Contact头中携带UA能力信息。本步骤中的REGISTER消息可以使用如下所示的消息格式:
REGISTER sip:scscf.example.com SIP/2.0
Via:SIP/2.0/UDP pcscf.example.com;branch=z9hG4bKnashds8
From:sip:A@example.com;tag=asd98
To:sip:A@example.com
Call-ID:hh89as0d-asd88jkk@host.example.com
CSeq:97 REGISTER
Max-Forwards:70
Require:pref
Contact:<sip:A@example.com>;audio;video    //UA的Contact URI
   ;actor=″msg-taker″;automata;mobility=″fixed″
   ;events=″!presence,message-summary″;language=″en,de″
   ;methods=″INVITE,BYE,OPTIONS,ACK,CANCEL″
                      //以上为所述Contact URI对应的UA能力信息
Content-Length:0
步骤302:S-CSCF服务器记录REGISTER消息中携带的UA能力信息,并向UA发送200 OK响应消息。
步骤303:根据设置的过滤规则进行过滤规则评估,触发代替用户完成向AS的第三方注册的操作。
本步骤中,所述过滤规则中通常包含触发条件以及与所述触发条件相应的操作,当触发条件符合时,即执行相应的操作。例如:初始过滤规则(iFC)。
步骤304:S-CSCF生成第三方注册请求,发送给AS。在所述第三方注册请求中携带用户的UA能力信息,消息格式如下:
REGISTER sip:as.example.com SIP/2.0
Via:SIP/2.0/UDP scscf.example.com;branch=z9hG4bKnas561
From:sip:scscf.example.com;tag=tsd23698
To:sip:A@example.com
Call-ID:fd89ws0d-aew88jkk
CSeq:987 REGISTER
Max-Forwards:70
Require:pref
Contact:<sip:scscf.example.com>;audio;video
  ;actor=″msg-taker″;automata;mobility=″fixed″
  ;events=″!presence,message-summary″;language=″en,de″
  ;methods=″INVITE,BYE,OPTIONS,ACK,CANCEL″
Content-Length:0
步骤305:AS记录REGISTER消息中携带的UA能力信息,发送200 OK响应消息给S-CSCF服务器。
至此,结束实施例二中提供UA能力信息的方法的信令流程示意图。
图4为本发明实施例二中第三服务器的组成结构示意图。参见图4,该第三服务器包括:
第二收发模块410,用于接收用户通过UA发送的、携带有所述UA的UA能力信息的注册请求,将所述注册请求发送给第三方注册模块420;并用于接收来自于第三方注册模块420的第三方注册请求,向第四服务器发送所述第三方注册请求;
第三方注册模块420,用于根据来自于第二收发模块410的注册请求以及存储的过滤规则,生成携带所述UA能力信息的第三方注册请求,将所述第三方注册请求发送给第二收发模块410。
进一步地,图4所示第三方注册模块420中可以包括:
注册请求分析单元421,用于对来自于第二收发模块410的注册请求进行分析,在收到携带有UA能力信息的注册请求时,通知第三方注册请求构造单元422构造携带UA能力信息的第三方注册请求;
第三方注册请求构造单元422,用于根据注册请求分析单元421的通知,生成携带用户的UA能力信息以及与UA能力信息对应的Contact URI的第三方注册请求,将所述第三方注册请求发送给第二收发模块410。
由上述实施例可见,本发明实施例通过在第三方注册过程中,由S-CSCF将用户的UA能力信息发送给应用服务器,使得原本不能获取UA能力信息的应用服务器获取到UA能力信息,从而使得应用服务器能够根据获取的UA能力信息选择合适的终端设备进行相关的业务处理。
以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (15)

1、一种提供用户代理UA能力信息的方法,用于第一服务器向第二服务器提供用户的UA能力信息,所述第一服务器为:能够获取用户的UA能力信息的服务器,所述第二服务器为:不能获取用户的UA能力信息的服务器,其特征在于,包括:
第一服务器接收来自于第二服务器的UA能力获取请求;
第一服务器根据所述UA能力获取请求生成响应消息,在所述响应消息中携带所述第一服务器获取的用户的UA能力信息;
第一服务器向第二服务器返回所述响应消息。
2、根据权利要求1所述的方法,其特征在于,生成所述响应消息时,进一步包括:
在所述响应消息中携带与所述UA能力信息对应的联系统一资源标识符Contact URI。
3、根据权利要求2所述的方法,其特征在于,所述接收来自于第二服务器的UA能力获取请求为:接收来自于第二服务器的订阅SUBSCRIBE消息,所述SUBSCRIBE消息携带有表示请求获取用户的UA能力信息的指示;
所述生成响应消息为:根据SUBSCRIBE消息携带的表示请求获取用户的UA能力信息的指示,生成通知NOTIFY消息,在所述NOTIFY消息中携带用户的UA能力信息、与所述UA能力信息对应的Contact URI以及表示所述NOTIFY消息中包含UA能力信息的指示。
4、根据权利要求3所述的方法,其特征在于,所述SUBSCRIBE消息为:事件包类型为注册reg事件包的SUBSCRIBE消息;
在所述NOTIFY消息中携带用户的UA能力信息为:将用户的UA能力信息携带于NOTIFY消息的注册信息中。
5、根据权利要求1至4任一项所述的方法,其特征在于,所述生成响应消息之前,进一步包括:
第一服务器获取用户的UA能力信息。
6、根据权利要求5所述的方法,其特征在于,所述第一服务器获取用户的UA能力信息为:
接收所述用户通过UA发送的注册请求,所述注册请求中携带有所述UA的UA能力信息以及表示所述注册请求中包含UA能力信息的指示;
存储所述UA能力信息。
7、根据权利要求1至4任一项所述的方法,其特征在于,所述第一服务器是:注册服务器;
所述第二服务器是:应用服务器AS或代理服务器Proxy。
8、一种实施权利要求1所述方法的第一服务器,所述第一服务器为:能够获取用户的UA能力信息的服务器,其特征在于,包括:
第一收发模块,用于接收来自于第二服务器的UA能力获取请求,将所述UA能力获取请求发送给请求处理模块;并用于接收来自于请求处理模块的响应消息,向所述第二服务器返回所述响应消息;
请求处理模块,用于根据来自于第一收发模块的UA能力获取请求,生成相应的响应消息发送给第一收发模块,所述响应消息中携带所述第一服务器获取的用户的UA能力信息。
9、根据权利要求8所述的第一服务器,其特征在于,所述请求处理模块中进一步包括:
请求消息分析单元,用于对来自于第一收发模块的UA能力获取请求进行分析,通知响应消息构造单元构造与所述UA能力获取请求相应的响应消息;
响应消息构造单元,用于根据请求消息分析单元的通知,生成携带用户的UA能力信息以及与UA能力信息对应的Contact URI的响应消息,将所述响应消息发送给第一收发模块。
10、根据权利要求9所述的第一服务器,其特征在于,所述第一收发模块中进一步包括:
订阅消息收发单元,用于接收来自于第二服务器的、携带有表示请求获取用户的UA能力信息的指示的SUBSCRIBE消息,将所述SUBSCRIBE消息发送给订阅消息分析子单元;并用于接收来自于通知消息构造子单元的NOTIFY消息,向所述第二服务器返回所述NOTIFY消息;
所述请求消息分析单元中进一步包括:
订阅消息分析子单元,用于对来自于订阅消息收发单元的SUBSCRIBE消息进行分析,在判定所述SUBSCRIBE消息中携带有表示请求获取用户的UA能力信息的指示时,通知通知消息构造子单元构造与所述SUBSCRIBE消息相应的NOTIFY消息;
所述响应消息构造单元中进一步包括:
通知消息构造子单元,用于根据订阅消息分析子单元的通知,生成携带注册信息中携带用户的UA能力信息的NOTIFY消息,将所述NOTIFY消息发送给所述订阅消息收发单元。
11、一种提供UA能力信息的方法,用于第三服务器向第四服务器提供用户的UA能力信息,所述第三服务器为:能够获取用户的UA能力信息的服务器,所述第四服务器为:不能获取用户的UA能力信息的服务器,其特征在于,包括:
第三服务器接收用户通过UA发送的注册请求,所述注册请求中携带有所述UA的UA能力信息以及表示所述注册请求中包含UA能力信息的指示;
第三服务器根据存储的过滤规则以及所述接收的注册请求,生成携带所述UA能力信息的第三方注册请求,向第四服务器发送所述第三方注册请求。
12、根据权利要求11所述的方法,其特征在于,在生成所述携带用户的UA能力信息的第三方注册请求时,进一步包括:
将与所述UA能力信息对应的Contact URI以及表示所述第三方注册请求中包含UA能力信息的指示,携带于所述第三方注册请求中。
13、根据权利要求11或12所述的方法,其特征在于,所述第三服务器是:注册服务器或服务呼叫会话控制功能S-CSCF实体;
所述第四服务器是:应用服务器、代理服务器或在线状态服务器。
14、一种实施权利要求11所述方法的第三服务器,所述第三服务器为:能够获取用户的UA能力信息的服务器,其特征在于,包括:
第二收发模块,用于接收用户通过UA发送的、携带有所述UA的UA能力信息的注册请求,将所述注册请求发送给第三方注册模块;并用于接收来自于第三方注册模块的第三方注册请求,向第四服务器发送所述第三方注册请求;
第三方注册模块,用于根据来自于第二收发模块的注册请求以及存储的过滤规则,生成携带所述UA能力信息的第三方注册请求,将所述第三方注册请求发送给第二收发模块。
15、根据权利要求14所述的第三服务器,其特征在于,所述第三方注册模块中进一步包括:
注册请求分析单元,用于对来自于第二收发模块的注册请求进行分析,通知第三方注册请求构造单元构造携带UA能力信息的第三方注册请求;
第三方注册请求构造单元,用于根据注册请求分析单元的通知,生成携带用户的UA能力信息以及与UA能力信息对应的Contact URI的第三方注册请求,将所述第三方注册请求发送给第二收发模块。
CNA2007101289593A 2007-07-27 2007-07-27 提供用户代理能力信息的方法及装置 Pending CN101355429A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNA2007101289593A CN101355429A (zh) 2007-07-27 2007-07-27 提供用户代理能力信息的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNA2007101289593A CN101355429A (zh) 2007-07-27 2007-07-27 提供用户代理能力信息的方法及装置

Publications (1)

Publication Number Publication Date
CN101355429A true CN101355429A (zh) 2009-01-28

Family

ID=40308041

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2007101289593A Pending CN101355429A (zh) 2007-07-27 2007-07-27 提供用户代理能力信息的方法及装置

Country Status (1)

Country Link
CN (1) CN101355429A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102244648A (zh) * 2010-05-11 2011-11-16 大唐移动通信设备有限公司 一种传输会话消息的方法及装置
WO2013026327A1 (zh) * 2011-08-22 2013-02-28 华为技术有限公司 一种能力查询的方法、通信终端及应用服务器

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102244648A (zh) * 2010-05-11 2011-11-16 大唐移动通信设备有限公司 一种传输会话消息的方法及装置
CN102244648B (zh) * 2010-05-11 2015-02-04 大唐移动通信设备有限公司 一种传输会话消息的方法及装置
WO2013026327A1 (zh) * 2011-08-22 2013-02-28 华为技术有限公司 一种能力查询的方法、通信终端及应用服务器

Similar Documents

Publication Publication Date Title
CN101299785B (zh) 一种会话处理的方法、系统以及业务服务器
US20060230154A1 (en) Method and entities for performing a push session in a communication system
CN100401724C (zh) 发送即时消息的方法和设备
MXPA04006881A (es) Metodo y sistema para facilitar servicios en red de comunicacion por medio de publicacion de datos mediante un servidor de senalizacion.
WO2009124943A1 (en) Apparatus, method, system and program for communication
CA2721062A1 (en) Differentiated message delivery notification
US9246955B2 (en) Capability query handling in a communication network
US10638299B2 (en) Dynamic scrolling-ticker for initiating telecommunications services
US9699220B2 (en) System and method to provide combinational services to anonymous callers
CN101223746A (zh) 寻呼模式消息收发
CN1984132B (zh) 一种对会话能力信息进行处理的方法和终端
US9571563B2 (en) Handling a shared data object in a communication network
CN100581197C (zh) 一种获取媒体特征信息的方法和系统以及终端设备
KR101002150B1 (ko) 이동통신 단말 간의 인스턴트 메시징 서비스 제공 방법 및 장치
KR100922953B1 (ko) 인터넷 프로토콜 멀티미디어 서브시스템에서 호 변경 요청의 처리 방법 및 시스템
CN101355429A (zh) 提供用户代理能力信息的方法及装置
KR100980440B1 (ko) 모바일 인스턴트 메신저 시스템 및 그 서비스 방법
KR20100115438A (ko) 인스턴트 메시지 서비스 시스템 및 이동통신 단말기, 및 그 서비스방법
WO2006109202A1 (en) Method and entities for performing a push session in a communication system
CN101170602B (zh) 一种媒体信息处理方法及通讯系统以及用户终端
CN101459626A (zh) 用于ip多媒体子系统的消息传输控制方法
Cannell et al. Service control for next-generation applications in wireless IP multimedia networks
KR100757535B1 (ko) 어플리케이션 구분이 가능한 멀티미디어 서비스 방법 및장치
EP2130347B1 (en) System and method to provide combinational services to anonymous callers

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Open date: 20090128