CN101426260A - 基于sip的用户注册事件的通知方法、服务器、代理和系统 - Google Patents
基于sip的用户注册事件的通知方法、服务器、代理和系统 Download PDFInfo
- Publication number
- CN101426260A CN101426260A CNA2008101858207A CN200810185820A CN101426260A CN 101426260 A CN101426260 A CN 101426260A CN A2008101858207 A CNA2008101858207 A CN A2008101858207A CN 200810185820 A CN200810185820 A CN 200810185820A CN 101426260 A CN101426260 A CN 101426260A
- Authority
- CN
- China
- Prior art keywords
- user
- message
- notification message
- proxy
- network element
- 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
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种基于会话发起协议SIP用户注册事件的通知方法、服务器、代理和系统，属于通讯技术领域。所述方法包括：感知到用户注册信息的变化；查询期望获得所述用户注册事件的网元；发送第一通知消息给所述网元，所述第一通知消息中携带所述用户变化后的注册信息。所述服务器包括：感知模块、查询模块和发送模块。所述代理包括：接收模块和发送模块。所述系统包括：服务器、代理和期望获得用户注册事件的网元。通过服务器在感知用户注册状态发生变化时，直接发送第一通知消息通知期望获得用户注册事件的网元这样的事件型对话，完成用户的注册事件的通知功能，很大程度上降低了期望获得用户注册事件的网元的开销、降低了网络带宽的占用。
Description
技术领域
本发明涉及通讯技术领域，特别涉及一种基于SIP的用户注册事件的通知方法、服务器、代理和系统。
背景技术
SIP(Session Initial Protocol，会话发起协议)被广泛应用到Internet网络、IMS(IP Multimedia Subsystem，IP多媒体系统)网络等分组网络中。
获得用户的注册事件，可以通过SIP中的订阅机制：由应用服务器向注册服务器发起订阅某一用户的注册事件，注册服务器建立订阅会话并通知应用服务器。在订阅会话有效时，如果用户向注册服务器发起注册，注册服务器便发送消息通知应用服务器该用户的注册事件。以IMS网络为例，可以订阅用户注册事件的网元包括用户终端、P-CSCF(Proxy-Call Session Control Function，代理服务器)和第三方注册的AS(Application Server，应用服务器)。相关网元通过订阅用户的注册事件可以获得用户的隐式注册集、用户标识的注册状态等信息。网络可以通过订阅用户的注册事件，在需要的时候，强制用户鉴权、注销用户或者让用户发起重注册。
在实现本发明的过程中，发明人发现上述现有技术至少具有以下缺点：
由于订阅网元在用户的注册生命周期中，需要周期性的发送订阅请求来保持订阅的有效性，这对于订阅网元的内存和性能均有着非常高的要求，增加了订阅网元的开销；
同时，由于订阅机制通过周期性的重订阅来维持订阅对话的有效性，而SIP是文本协议，这将很大程度地占用网络的传输带宽，增加网络的流量。
发明内容
为了降低订阅网元的开销，减小网络的流量，本发明实施例提供了一种基于SIP的用户注册事件的通知方法、服务器、代理和系统。所述技术方案如下：
一种基于会话发起协议SIP的用户注册事件的通知方法，包括：
感知到用户注册信息的变化；
查询期望获得所述用户注册事件的网元；
发送第一通知消息给所述网元，所述第一通知消息中携带所述用户变化后的注册信息。
一种基于会话发起协议SIP的服务器，包括：
感知模块，用于感知到用户注册信息的变化；
查询模块，用于查询期望获得所述用户注册事件的网元；
发送模块，用于发送第一通知消息给所述网元，所述第一通知消息中携带所述用户变化后的注册信息。
一种基于会话发起协议SIP的代理Proxy，其特征在于，包括：
接收模块，用于接收服务器发送的第一通知消息，所述第一通知消息中携带用户变化后的注册信息；
发送模块，用于将所述接收模块接收到的所述第一通知消息发送给期望获得所述用户注册事件的网元。
一种基于会话发起协议SIP的用户注册事件的通知系统，包括：服务器、代理Proxy和期望获得用户的注册事件的网元；
所述服务器用于感知到用户注册信息的变化，查询所述期望获得所述用户注册事件的网元，发送第一通知消息给所述期望获得用户的注册事件的网元，所述第一通知消息中携带所述用户变化后的注册信息；
所述Proxy用于转发所述服务器与所述期望获得用户的注册事件的网元之间的消息；
所述期望获得用户的注册事件的网元用于根据接收到的所述第一通知消息更新所述用户的注册信息。
本发明实施例的提供的技术方案的有益效果是：
通过服务器在感知用户注册状态发生变化的时候，直接发送第一通知消息通知期望获得用户注册事件的网元这样的事件型对话，完成用户的注册事件的通知功能，不仅很大程度上降低了期望获得用户注册事件的网元的开销、同时降低了网络带宽的占用。
附图说明
图1是本发明实施例一中提供的基于会话发起协议SIP的用户注册事件的通知方法流程图；
图2是本发明实施例二中提供的基于会话发起协议SIP的用户注册事件的通知方法信息交互图；
图3是本发明实施例三中提供的基于会话发起协议SIP的用户注册事件的通知方法信息交互图；
图4是本发明实施例四中提供的基于会话发起协议SIP的用户注册事件的通知系统结构示意图；
图5是本发明实施例四中提供的基于会话发起协议SIP的服务器的结构示意图；
图6是本发明实施例四中提供的基于会话发起协议SIP的Proxy的一种结构示意图；
图7是本发明实施例四中提供的基于会话发起协议SIP的Proxy的另一种结构示意图；
图8是本发明实施例四中提供的基于会话发起协议SIP的Proxy的另一种结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
实施例一
参见图1，本发明实施例提供了一种基于会话发起协议SIP的用户注册事件的通知方法，包括：
101：感知到用户注册信息的变化；
102：查询期望获得该用户注册事件的网元；
103：发送第一通知消息给网元，该第一通知消息中携带用户变化后的注册信息。
其中，101具体可以包括：
感知到用户初始注册成功；
或，感知到用户被注销；
或，感知到用户的签约数据被更改；
或，感知到用户发生漫游。
102具体可以包括：
根据用户的签约数据或者静态配置数据，获得期望获得用户注册事件的网元地址。
103具体可以包括：
103A：将第一通知消息路由至用户的代理Proxy；
103B：Proxy根据网元的地址，将第一通知消息发送给网元。
进一步地，在103A之后该方法还可以包括：
103A1：第一通知消息中还携带校验标识；
103A2：Proxy根据校验标识对第一通知消息的发送方进行校验。
进一步地，103A2之后该方法还可以包括：
当校验结果为校验成功时，根据第一通知消息中携带的用户变化后的注册信息，更新Proxy保存的用户的注册信息。
进一步地，该方法还可以包括：
104：发送第二通知消息给Proxy，第二通知消息中携带用户变化后的注册信息。
进一步地，104还可以包括：
104A：第二通知消息中还携带第二校验标识；
104B：Proxy根据第二校验标识对第二通知消息的发送方进行第二校验。
进一步地，104B之后方法还可以包括：
当第二校验结果为校验成功时，根据第二通知消息中携带的用户变化后的注册信息，更新Proxy保存的用户的注册信息。
本发明实施例通过服务器在感知用户注册状态发生变化的时候，直接使用第一通知消息通知期望获得用户注册事件的网元、以及第二通知消息通知用户的代理，在第一通知消息和第二通知消息中携带用户的注册状态、隐式注册集、鉴权信息等内容，通过这样的事件型对话，完成用户注册事件的通知功能，不仅很大程度上降低了期望获得用户注册事件的网元的开销、同时降低了网络带宽的占用。
实施例二
在用户进行注册时，用户向注册服务器发送注册请求消息，SIP通过注册服务将注册请求消息的Contact头域中UE(User Equipment，用户设备)的联系地址与用户的AOR(Address Of Record，记录地址)绑定起来。这样，当网络侧发送SIP请求给用户时，SIP请求经过Proxy(代理)，Proxy将该SIP请求中的Request-URI(Universal Resource Identity，通用资源标识)与用户的AOR进行匹配，从而通过用户AOR找到用户注册的联系地址，然后将SIP请求转发到这个联系地址上去。
参见图2，本发明实施例提供了一种基于会话发起协议SIP的用户注册事件的通知方法，在注册服务器和注册时间订阅服务器合一的情况下，该方法包括：
201：用户(Joe)向注册服务器(Registrar)发起注册请求(Register)；
其中，注册请求通过代理Proxy发向注册服务器；在注册请求经过Proxy时，Proxy在注册请求的Path头域中携带自己的地址。
202：注册服务器接收到注册请求后，保存相关信息，并发送应答注册消息给用户(Joe)；
其中，相关信息包括：Path头域中的Proxy地址、Contact头域中的联系地址等。
203：注册服务器根据保存的相关信息、用户的签约数据或者注册服务器本地存储的静态配置等信息，查询得到期望获得用户注册事件的网元的地址。
这里需要说明的是，注册服务器可以只需要根据上述信息中的一个，便可以查询得到期望获得用户注册事件的网元的地址。
本实施例中假设期望获得用户注册事件的网元为用户(Joe)的UE。
204：注册服务器主动向期望获得用户注册事件的网元用户UE发送Notify消息；
其中，注册服务器主动发出Notify消息的场景包括但不限于：
(1)用户初始注册成功之后；
(2)网络侧注销用户；
(3)网络侧更改用户的签约数据；
(4)用户发生漫游，注册服务器要通知漫游前的Proxy注销其本地用户数据。
注册服务器可以通过发送Notify消息主动通知期望获得用户注册事件的网元该用户注册信息的变化。
注册服务器主动通知两种实施方式。
一种是注册服务器只通知作为注册路径终结点的期望获得用户注册事件的网元(UE)，而通知路径中的Proxy在前传Notify请求的同时，实施与终结点类似的操作，即按照Notify消息的内容刷新本地用户的注册信息。
另一种是注册服务器同时通知注册路径的终结点和Proxy，当Proxy识别自身为该通知路径的终结点时，直接刷新本地用户的注册状态，当Proxy识别自身为该通知路径的前传代理时，直接前传消息至终结点。
在本实施例中，以前一种主动通知的方式为例。
Notify消息具体包括：
(1)用户(Joe)的注册信息；
(2)Route头域，该头域中具体为注册服务器保存的Path头域中的Proxy地址，用于将Notify消息路由到Proxy；
(3)Request-URI头域，该头域中具体为注册服务器保存的Contact头域中的联系地址，用于将Notify消息发送到UE；
(4)P-Asserted-Identity头域，该头域中具体为注册服务器注册时添加的Service-Route头域，用于Proxy对Notify消息的发送方进行校验。
205：根据Route头域中Proxy的地址，Notify消息被路由到Proxy；
Proxy首先获取Notify消息中P-Asserted-Identity头域中的服务器主机名，用获取到的服务器主机名与其本地用户数据中保存的服务器主机名比较，对发送Notify消息的服务器进行校验；
如果校验的结果是这两个主机名相同，则表示该Notify消息是可信的；Proxy根据Notify消息体中的文本解析文件中的信息刷新本地的用户注册状态，并删除Notify消息中的P-Asserted-Identity头域，执行步骤206；
如果校验的结果是这两个主机名不同，则表示该Notify消息是不可信的；Proxy发送失败响应给所述Notify消息的发送方，且不执行任何其他操作。
206：Proxy根据Notify消息中Request-URI头域中的联系地址，将Notify消息转发给期望获得用户(Joe)注册事件的网元UE；
207：UE接收到Notify消息，根据Notify消息体中的信息，寻找本地保存的用户，并更新本地用户的注册信息。
具体的，Notify消息可以如下所示：
NOTIFY sip:Joe@app.example.com:5064 SIP/2.0
Via：SIP/2.0/UDP registar.example.com；branch＝z9hG4bKnasaij
From:sip:registar.example.com；tag＝xyzygg
To:sip:Joe@app.example.com；tag＝123aa9
Route:<sip:term@pcscf1.example.com:5060；1r>
P-Asserted-Identity:<sip:orig@scscf1.example.com>
Call-ID:9987@app.example.com
CSeq:1289 NOTIFY
Contact:sip:registar.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＂
version＝＂1＂state＝＂partial＂>
<registration aor＝＂sip:joe@app.example.com＂id＝＂a7＂state＝＂active＂>
<contact id＝＂76＂state＝＂active＂event＝＂registered＂
duration-registered＝＂0＂>
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
本发明实施例通过服务器在感知用户注册状态发生变化的时候，直接使用通知消息通知期望获得用户注册事件的网元，通知消息中携带用户的注册状态、隐式注册集、鉴权信息等内容，通过这样的事件型对话，完成用户注册事件的通知功能，不仅很大程度上降低了期望获得用户注册事件的网元的开销、同时降低了网络带宽的占用。
实施例三
本发明实施例提供了一种基于会话发起协议SIP的用户注册事件的通知方法，该方法与实施例二中提供的方法不同之处在于：实施例二中，服务器只通知作为注册路径终结点的期望获得用户注册事件的网元(如IMS网络中的UE等)，而通知路径中的Proxy在前传Notify请求的同时，实施与终结点类似的操作，即按照Notify请求的消息内容刷新本地用户的注册状态；而本实施例三中，服务器同时发送Notify请求给终结点和Proxy，当Proxy识别自己为终结点时，直接刷新本地用户的注册状态；当Proxy识别自己为前传代理时，直接前传Notify消息至终结点。
参见图3，该方法包括：
301：用户(Joe)向注册服务器(Registrar)发起注册请求(Register)；
其中，注册请求通过Proxy发向注册服务器；在注册请求经过Proxy时，Proxy在注册请求的Path头域中携带自己的地址。
302：注册服务器接收到注册请求后，保存相关信息，并发送应答注册消息给用户(Joe)；
其中，相关信息包括：Path头域中的Proxy地址、Contact头域中的联系地址等。
303：注册服务器根据保存的相关信息、用户的签约数据或者注册服务器本地存储的静态配置等信息，得到期望获得用户注册事件的网元的地址。
这里需要说明的是，注册服务器可以只需要根据上述信息中的一个，便可以查询得到期望获得用户注册事件的网元的地址。
本实施例中假设期望获得用户注册事件的网元为用户(Joe)的UE。
304：注册服务器主动发送第一Notify消息；
其中，注册服务器主动发送第一Notify消息的场景包括但不限于：
(1)用户初始注册成功之后；
(2)网络侧注销用户；
(3)网络侧更改用户的签约数据；
(4)用户发生漫游，注册服务器要通知漫游前的Proxy注销其本地用户数据。
其中，第一Notfiy消息为注册服务器将Proxy作为前传代理时发送的，具体包括：
(1)用户(Joe)的注册信息；
(2)Route头域，该头域中具体为注册服务器保存的Path头域中的Proxy地址，用于将Notify消息路由到Proxy；
(3)Request-URI头域，该头域中具体为注册服务器保存的Contact头域中的联系地址，用于将Notify消息发送到UE；
(4)P-Asserted-Identity头域，该头域中具体为注册服务器的注册时添加的Service-Route头域，用于Proxy对Notify消息的发送方进行校验。
305：第一Notify消息被路由到Proxy；
Proxy首先获取第一Notify消息中P-Asserted-Identity头域中的服务器主机名，用获取到的服务器主机名与其本地用户数据中保存的服务器主机名比较，对发送Notify消息的服务器进行校验；
如果校验的结果是这两个主机名相同，则表示该第一Notify消息是可信的，执行步骤306；
如果校验的结果是这两个主机名不同，则表示该第一Notify消息是不可信的；Proxy发送失败响应给该第一Notify消息的发送方，且不执行任何其他操作。
306：Proxy根据第一Notify消息内容，识别自身为路由的前传代理，删除Notify消息中的P-Asserted-Identity头域后，将Notify消息转发到UE，执行步骤307；
307：UE接收到第一Notify消息，根据第一Notify消息体中的信息刷新用户(Joe)的注册信息。
进行304至307的同时，还可以进行如下步骤：
304’：注册服务器主动发送第二Notify消息；
其中，注册服务器主动发送第二Notify消息的场景包括但不限于：
(1)用户初始注册成功之后；
(2)网络侧注销用户；
(3)网络侧更改用户的签约数据；
(4)用户发生漫游，注册服务器要通知漫游前的Proxy注销其本地用户数据。
其中，第二Notfiy消息为注册服务器将Proxy作为终结点时发送的，具体包括：
(1)用户(Joe)的注册信息；
(2)Request-URI头域；
如果注册请求中的Path头域只有一条记录，则该Request-URI头域中具体为：注册服务器保存的注册请求中的Path头域中的记录；
如果注册请求中的Path头域有多条记录，则该Request-URI头域中具体为：注册服务器保存的注册请求中的Path头域中的最后一条记录。
(3)Route头域；
如果注册请求中的Path头域只有一条记录，则Notify消息中不包括该Route头域；
如果注册请求中的Path头域有多条记录，则Notify消息中包括该Route头域，且该Route头域中具体为：注册服务器保存的注册请求中的Path头域中去除最后一条记录的其他全部记录，这些其他全部记录仍然需要保持之前的顺序。
(4)P-Asserted-Identity头域，该头域中具体为注册服务器注册时添加的Service-Route头域，用于Proxy对Notify消息的发送方进行校验。
305’：第二Notify消息被路由到Proxy；
Proxy首先获取第二Notify消息中P-Asserted-Identity头域中的服务器主机名，用获取到的服务器主机名与其本地用户数据中保存的服务器主机名比较，对发送Notify消息的服务器进行校验；
如果校验的结果是这两个主机名相同，则表示该第二Notify消息是可信的，执行步骤306’；
如果校验的结果是这两个主机名不同，则表示该第二Notify消息是不可信的；Proxy发送失败响应给该第二Notify消息的发送方，且不执行任何其他操作。
306’：Proxy根据第二Notify消息内容，识别出自己为路由的终结点时，Proxy根据Notify消息体中的信息刷新本地用户(Joe)的注册信息，并直接向注册服务器返回应答。
其中，将Proxy作为前传代理的第一Notify消息可以如下所示：
NOTIFY sip:Joe@app.example.com：5064 SIP/2.0
Via：SIP/2.0/UDP registar.example.com；branch＝z9hG4bKnasaij
From:sip:registar.example.com；tag＝xyzygg
To:sip:app.example.com；tag＝123aa9
Route:<sip:term@pcscf1.example.com:5060；lr>
P-Asserted-Identity:<sip:orig@scscf1.example.com>
Call-ID：9987@app.example.com
CSeq：1289 NOTIFY
Contact:sip:registar.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＂
version＝＂1＂state＝＂partial＂>
<registration aor＝＂sip:joe@app.example.com＂id＝＂a7＂state＝＂active＂>
<contact id＝＂76＂state＝＂active＂event＝＂registered＂
duration-registered＝＂0＂>
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
将Proxy作为终结点的第二Notify消息可以如下所示：
NOTIFY sip:term@pcscfl.example.com：5060SIP/2.0
Via：SIP/2.0/UDP registar.example.com；branch＝z9hG4bKnasaij
From:sip:registar.example.com；tag＝xyzygg
To:sip:term@pcscfl.example.com；tag＝123aa9
P-Asserted-Identity:<sip:orig@scscfl.example.com>
Call-ID：9987@app.example.com
CSeq：1289 NOTIFY
Contact:sip:registar.example.com
Event:reg
Max-Forwards：70
Content-Type：application/reginfo+xml
Content-Length：...
<？xml version＝＂1.0＂？>
<reginfoxmlns＝＂urn:ietf:params:xml:ns:reginfo＂
version＝＂1＂state＝＂partial＂>
<registration aor＝＂sip:joe@app.example.com＂id＝＂a7＂state＝＂active＂>
<contact id＝＂76＂state＝＂active＂event＝＂registered＂
duration-registered＝＂0＂>
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
本发明实施例通过服务器在感知用户注册状态发生变化的时候，直接使用第一通知消息通知期望获得用户注册事件的网元和第二通知消息通知代理Proxy，第一通知消息和第二通知消息中携带用户的注册状态、隐式注册集、鉴权信息等内容，通过这样的事件型对话，完成用户注册事件的通知功能，不仅很大程度上降低了期望获得用户注册事件的网元的开销、同时降低了网络带宽的占用。
实施例四
参见图4，本发明实施例提供了一种用户注册事件的通知系统，包括：服务器401、代理Proxy402和期望获得用户的注册事件的网元403；
服务器401用于感知到用户注册信息的变化，查询期望获得用户注册事件的网元403，发送第一通知消息给期望获得用户的注册事件的网元403，第一通知消息中携带用户变化后的注册信息；
Proxy402用于转发服务器401与期望获得用户的注册事件的网元403之间的消息；
期望获得用户的注册事件的网元403用于根据接收到的第一通知消息更新用户的注册信息。
参见图5，服务器401，包括：
感知模块401A，用于感知到用户注册信息的变化；
查询模块401B，用于查询期望获得用户注册事件的网元403；
发送模块401C，用于发送第一通知消息给网元403，第一通知消息中携带用户变化后的注册信息。
其中，感知模块401A具体用于：
感知到用户初始注册成功；
或，感知到用户被注销；
或，感知到用户的签约数据被更改；
或，感知到用户发生漫游。
其中，查询模块401B具体用于：
根据用户的签约数据或者静态配置数据，获得期望获得用户注册事件的网元地址。
其中，发送模块401C具体用于：
将第一通知消息路由至用户的Proxy402；
Proxy402根据查询模块查询得到的网元403地址，将第一通知消息发送给网元403。
进一步地，发送模块401C还用于：
发送第二通知消息给Proxy402，第二通知消息中携带用户变化后的注册信息。
参见图6，代理Proxy402具体包括：
接收模块402A，用于接收服务器401发送的第一通知消息，第一通知消息中携带用户变化后的注册信息；
发送模块402B，用于将接收模块402A接收到的第一通知消息发送给期望获得用户注册事件的网元403。
进一步地，接收模块402A接收到第一通知消息中还携带校验标识；
相应的，参见图7，Proxy402还包括：
校验模块402C，用于根据校验标识对第一通知消息的发送方进行校验。
进一步地，当校验模块402C的校验结果为校验成功时，参见图8，Proxy402还包括：
更新模块402D，用于根据第一通知消息中携带的用户变化后的注册信息，更新保存的用户的注册信息。
本发明实施例利用用户注册事件的通知系统，通过服务器在感知用户注册状态发生变化的时候，直接使用通知消息通知期望获得用户注册事件的网元(和代理Proxy)，通知消息中携带用户的注册状态、隐式注册集、鉴权信息等内容，通过这样的事件型对话，完成用户注册事件的通知功能，不仅很大程度上降低了期望获得用户注册事件的网元的开销、同时降低了网络带宽的占用。
本发明实施例可以利用软件实现，相应的软件程序可以存储在可读取的存储介质中，例如，路由器的硬盘、缓存或光盘中。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (18)
1、一种基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，包括：
感知到用户注册信息的变化；
查询期望获得所述用户注册事件的网元；
发送第一通知消息给所述网元，所述第一通知消息中携带所述用户变化后的注册信息。
2、如权利要求1所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述感知到用户注册信息的变化，具体包括：
感知到用户初始注册成功；
或，感知到用户被注销；
或，感知到用户的签约数据被更改；
或，感知到用户发生漫游。
3、如权利要求1所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述查询期望获得所述用户注册事件的网元，具体包括：
根据所述用户的签约数据或者静态配置数据，获得期望获得所述用户注册事件的网元地址。
4、如权利要求3所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述发送第一通知消息给所述网元，具体包括：
将所述第一通知消息路由至所述用户的代理Proxy；
所述Proxy根据所述网元的地址，将所述第一通知消息发送给所述网元。
5、如权利要求4所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述将所述第一通知消息路由至所述用户的代理Proxy之后，所述方法还包括：
所述第一通知消息中还携带校验标识；
所述Proxy根据所述校验标识对所述第一通知消息的发送方进行校验。
6、如权利要求5所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述Proxy根据所述校验标识对所述第一通知消息的发送方进行校验之后，所述方法还包括：
当校验结果为校验成功时，根据所述第一通知消息中携带的所述用户变化后的注册信息，更新所述Proxy保存的所述用户的注册信息。
7、如权利要求1至6中任一权利要求所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述方法还包括：
发送第二通知消息给所述Proxy，所述第二通知消息中携带所述用户变化后的注册信息。
8、如权利要求7所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述方法还包括：
所述第二通知消息中还携带第二校验标识；
所述Proxy根据所述第二校验标识对所述第二通知消息的发送方进行校验。
9、如权利要求8所述的基于会话发起协议SIP的用户注册事件的通知方法，其特征在于，所述Proxy根据所述第二校验标识对所述第二通知消息的发送方进行校验之后，所述方法还包括：
当校验结果为校验成功时，根据所述第二通知消息中携带的所述用户变化后的注册信息，更新所述Proxy保存的所述用户的注册信息。
10、一种基于会话发起协议SIP的服务器，其特征在于，包括：
感知模块，用于感知到用户注册信息的变化；
查询模块，用于查询期望获得所述用户注册事件的网元；
发送模块，用于发送第一通知消息给所述网元，所述第一通知消息中携带所述用户变化后的注册信息。
11、如权利要求10所述的基于会话发起协议SIP的服务器，其特征在于，所述感知模块具体用于：
感知到用户初始注册成功；
或，感知到用户被注销；
或，感知到用户的签约数据被更改；
或，感知到用户发生漫游。
12、如权利要求10所述的基于会话发起协议SIP的服务器，其特征在于，所述查询模块具体用于：
根据所述用户的签约数据或者静态配置数据，获得期望获得所述用户注册事件的网元地址。
13、如权利要求12所述的基于会话发起协议SIP的服务器，其特征在于，所述发送模块具体用于：
将所述第一通知消息路由至所述用户的代理Proxy；
所述Proxy根据所述查询模块查询得到的所述网元地址，将所述第一通知消息发送给所述网元。
14、如权利要求10至13中任一权利要求所述的基于会话发起协议SIP的服务器，其特征在于，所述发送模块还用于：
发送第二通知消息给所述Proxy，所述第二通知消息中携带所述用户变化后的注册信息。
15、一种基于会话发起协议SIP的代理Proxy，其特征在于，包括：
接收模块，用于接收服务器发送的第一通知消息，所述第一通知消息中携带用户变化后的注册信息；
发送模块，用于将所述接收模块接收到的所述第一通知消息发送给期望获得所述用户注册事件的网元。
16、如权利要求15所述的基于会话发起协议SIP的Proxy，其特征在于，所述接收模块接收到所述第一通知消息中还携带校验标识；
相应的，所述Proxy还包括：
校验模块，用于根据所述校验标识对所述第一通知消息的发送方进行校验。
17、如权利要求16所述的基于会话发起协议SIP的Proxy，其特征在于，当所述校验模块的校验结果为校验成功时，所述Proxy还包括：
更新模块，用于根据所述第一通知消息中携带的所述用户变化后的注册信息，更新保存的所述用户的注册信息。
18、一种基于会话发起协议SIP的用户注册事件的通知系统，其特征在于，包括：服务器、代理Proxy和期望获得用户的注册事件的网元；
所述服务器用于感知到用户注册信息的变化，查询所述期望获得所述用户注册事件的网元，发送第一通知消息给所述期望获得用户的注册事件的网元，所述第一通知消息中携带所述用户变化后的注册信息；
所述Proxy用于转发所述服务器与所述期望获得用户的注册事件的网元之间的消息；
所述期望获得用户的注册事件的网元用于根据接收到的所述第一通知消息更新所述用户的注册信息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008101858207A CN101426260A (zh) | 2008-12-15 | 2008-12-15 | 基于sip的用户注册事件的通知方法、服务器、代理和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008101858207A CN101426260A (zh) | 2008-12-15 | 2008-12-15 | 基于sip的用户注册事件的通知方法、服务器、代理和系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101426260A true CN101426260A (zh) | 2009-05-06 |
Family
ID=40616542
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2008101858207A Pending CN101426260A (zh) | 2008-12-15 | 2008-12-15 | 基于sip的用户注册事件的通知方法、服务器、代理和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101426260A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010139264A1 (zh) * | 2009-06-02 | 2010-12-09 | 中兴通讯股份有限公司 | 网元注册子系统、电信增值业务系统及网元注册方法 |
| CN102045694A (zh) * | 2009-10-26 | 2011-05-04 | 中兴通讯股份有限公司 | 用户业务信息的传输方法和网元设备 |
| CN109871220A (zh) * | 2019-01-21 | 2019-06-11 | 珠海奔图电子有限公司 | 电子装置注册状态更新方法及系统 |
-
2008
- 2008-12-15 CN CNA2008101858207A patent/CN101426260A/zh active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010139264A1 (zh) * | 2009-06-02 | 2010-12-09 | 中兴通讯股份有限公司 | 网元注册子系统、电信增值业务系统及网元注册方法 |
| CN102045694A (zh) * | 2009-10-26 | 2011-05-04 | 中兴通讯股份有限公司 | 用户业务信息的传输方法和网元设备 |
| CN102045694B (zh) * | 2009-10-26 | 2015-08-12 | 中兴通讯股份有限公司 | 用户业务信息的传输方法和网元设备 |
| CN109871220A (zh) * | 2019-01-21 | 2019-06-11 | 珠海奔图电子有限公司 | 电子装置注册状态更新方法及系统 |
| CN109871220B (zh) * | 2019-01-21 | 2022-03-01 | 珠海奔图电子有限公司 | 电子装置注册状态更新方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1695521B1 (en) | Application server adressing | |
| US7890101B2 (en) | Call controlling apparatus, call controlling method, and computer program | |
| US8311037B2 (en) | Method, apparatus and system for transmitting user equipment information in a multimedia subsystem | |
| CN101345748B (zh) | 将用户状态通知应用服务器的方法、系统及装置 | |
| CN101682617B (zh) | 确定多媒体能力的方法、多媒体应用服务器及系统 | |
| US8363643B2 (en) | Method for delivering device and server capabilities | |
| EP2052523B1 (en) | Method and user equipment for providing updates on access network capabilities in an ip multimedia system method | |
| US7885191B2 (en) | Load balance server and method for balancing load of presence information | |
| CN100471150C (zh) | 建立订阅对话的方法及订阅用户事件的方法 | |
| US20110314140A1 (en) | Capability Query Handling in a Communication Network | |
| US20050249152A1 (en) | Method for processing messages | |
| JP2009542106A (ja) | ローミング・ネットワークにおけるクライアントの登録をネットワーク・アプリケーションに通知する方法 | |
| US20090204715A1 (en) | Method and system for acquiring a transmission path of an sip message | |
| CN101426261B (zh) | 多媒体子系统业务处理的方法、p-cscf、i-cscf和多媒体子系统 | |
| US20080003957A1 (en) | Message generation with identification group information | |
| CN101115309B (zh) | 拜访地网络、归属地网络、拜访地业务使用系统、方法及终端 | |
| CN101127769A (zh) | 基于会话发起协议的用户注册的方法、系统及终端、服务器 | |
| CN101056304B (zh) | 通过sip注册请求创建隐式订阅的方法 | |
| KR20080008422A (ko) | 서비스 제어를 위한 방법 및 요소 | |
| CN101426260A (zh) | 基于sip的用户注册事件的通知方法、服务器、代理和系统 | |
| US20100011004A1 (en) | Service Identification Optimization | |
| CN101854332B (zh) | 流媒体业务的处理方法、装置及系统 | |
| CN101155336B (zh) | 实现消息系统用户漫游的方法及其系统 | |
| US9762621B2 (en) | Call routing for IP multimedia subsystem users | |
| US9332055B2 (en) | Method and apparatus for routing XCAP requests |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20090506 |