CN101754181A - 铃音业务处理方法、应用服务器、处理装置和网络系统 - Google Patents
铃音业务处理方法、应用服务器、处理装置和网络系统 Download PDFInfo
- Publication number
- CN101754181A CN101754181A CN200810185720A CN200810185720A CN101754181A CN 101754181 A CN101754181 A CN 101754181A CN 200810185720 A CN200810185720 A CN 200810185720A CN 200810185720 A CN200810185720 A CN 200810185720A CN 101754181 A CN101754181 A CN 101754181A
- Authority
- CN
- China
- Prior art keywords
- request message
- application server
- login request
- user terminal
- message
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/02—Calling substations, e.g. by ringing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42136—Administration or customisation of services
- H04M3/42153—Administration or customisation of services by subscriber
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明实施例公开一种铃音业务处理方法、应用服务器、处理装置和网络系统。铃音业务处理方法，包括：应用服务器接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息。应用服务器，包括：第一接收单元，用于接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；第一发送单元，用于根据所述接收单元接收的注册请求消息，向发送所述注册请求消息的发送方返回注册响应消息。相应的，本发明实施还提供一种处理装置和网络系统。本发明实施例技术方案能够通过注册过程对铃音业务进行控制。
Description
技术领域
本发明涉及通信技术领域，具体涉及一种铃音业务处理方法、应用服务器、处理装置和网络系统。
背景技术
目前，铃音业务已经发展越来越广泛，包括出现了彩铃业务、彩振业务和彩像业务等。彩铃，也称为个性化回铃音业务，客户可以根据自身的喜好和要求定制自身终端的回铃音。彩振，也称个性化振铃音业务，客户可以根据自身的喜好和要求定制自身终端的振铃音。彩像，也称个性化背景音业务，客户可以根据通话双方的喜好和要求，对通话过程定制背景声音。而随着多媒体网络技术的发展，彩铃业务、彩振业务和彩像业务也演变为多媒体彩铃业务、多媒体彩振业务和多媒体彩像业务等多媒体铃音业务。
IP多媒体子系统(IMS，IPMultimedia Subsystem)是第三代合作项目(3GPP，3rd Generation Partnership Project)中定义的一个子系统，用于实现包括语音、视频、数据在内的新一代多媒体电信业务。
IMS中的主要功能实体包括：呼叫会话控制功能实体(CSCF，Call SessionControl Function)、媒体资源功能实体(MRF，Multimedia Resource Function)、应用服务器(AS，Application Server)。CSCF主要用于对会话进程的控制，又分为三个不同实体：代理呼叫会话控制功能实体P-CSCF(Proxy-CSCF)、询问呼叫会话控制功能实体I-CSCF(Interrogating-CSCF)、服务呼叫会话控制功能实体S-CSCF(Serving-CSCF)。P-CSCF主要负责验证请求，处理和转发响应；S-CSCF在IMS中处于核心控制地位，负责记录并控制用户进程状态，执行会话路由功能，并不断与应用服务器进行交互。
现有技术中，已经定义了铃音业务的信令流程：
当主叫用户终端呼叫被叫用户终端时，呼叫请求被路由到S-CSCF，S-CSCF根据iFC策略以及对终端是否开通了彩铃业务的查询结果进行处理，如果已开通彩铃业务，将呼叫请求路由到彩铃服务器，由彩铃服务器通过控制MRF向主叫用户终端播放个性化铃音。
在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：
目前铃音业务例如多媒体铃音业务中主要规定了如何在呼叫过程当中对铃音业务进行信令的接续，但尚未提供铃音业务过程的业务注册流程，从而使得铃音业务与呼叫业务一起被默认打开，造成无法对是否使用铃音业务进行控制。
发明内容
本发明实施例要解决的技术问题是提供一种铃音业务处理方法、应用服务器、处理装置和网络系统，能够通过注册过程对铃音业务进行控制。
为解决上述技术问题，本发明所提供的实施例是通过以下技术方案实现的：
本发明实施例提供一种铃音业务处理方法，包括：
应用服务器接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息。
本发明实施例提供一种应用服务器，包括：
第一接收单元，用于接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
第一发送单元，用于根据所述接收单元接收的注册请求消息，向发送所述注册请求消息的发送方返回注册响应消息。
本发明实施例提供一种处理装置，包括：
发送单元，用于向应用服务器发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
接收单元，用于接收所述应用服务器返回的注册响应消息。
本发明实施例提供一种网络系统，包括：
处理装置，用于发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息，接收应用服务器返回的注册响应消息；
应用服务器，用于接收所述处理装置发送的用户终端的注册请求消息，根据所述注册请求消息向所述处理装置返回注册响应消息。
上述技术方案可以看出，本发明实施例提供了用户终端的铃音业务注册过程，可以通过注册进行业务的激活，这样就可实现对铃音业务进行控制，并且后续可以进一步使得应用服务器根据用户终端的业务注册信息对业务进行决策，从而促进各种铃音业务的进一步发展。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例一铃音业务处理方法流程图；
图2是本发明实施例二直接进行注册的流程图；
图3是本发明实施例三通过第三方间接进行注册的流程图；
图4是本发明实施例四在注册完成后进行用户终端状态信息订阅的流程图；
图5是本发明实施例五在注册完成后进行业务参数配置的流程图；
图6是本发明实施例六在注册完成后进行去注册的流程图；
图7是本发明实施例应用服务器结构示意图；
图8是本发明实施例处理装置一结构示意图；
图9是本发明实施例处理装置二结构示意图；
图10是本发明实施例网络系统结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例提供一种铃音业务处理方法，能够通过注册过程对铃音业务进行控制。
请参阅图1，是本发明实施例一铃音业务处理方法流程图，包括步骤：
步骤101、应用服务器接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
步骤102、应用服务器向发送所述注册请求消息的发送方返回注册响应消息。
其中接收用户终端的注册请求消息包括：
接收用户终端通过呼叫会话控制功能实体直接转发的注册请求消息；或者，接收呼叫会话控制功能实体发送的注册请求消息，所述注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的注册请求消息的目的地址修改为应用服务器的地址并重新封装后，向所述应用服务器发送。
从实施例一可以看出，本发明实施例提供了用户终端的铃音业务注册过程，可以通过注册进行业务的激活，这样就可实现对铃音业务进行控制，并且后续可以进一步使得应用服务器根据用户终端的业务注册信息对业务进行决策，从而促进各种铃音业务的进一步发展。
请参阅图2，是本发明实施例二直接进行注册的流程图。图中以描述用户终端A的注册过程举例说明，用户终端B的注册过程是类似的。
如图2所示，包括：
步骤201、用户终端A向应用服务器发送注册请求消息；
用户终端A获取应用服务器的地址信息，生成注册请求消息，注册请求消息中携带需开通的铃音业务信息，所述铃音业务可以是彩铃业务、彩振业务、彩像业务或多媒体彩铃业务、多媒体彩振业务、多媒体彩像业务等。注册请求消息，可以是会话初始化协议(SIP，Session Initial Protocol)信令的注册消息(REGISTER消息)或者是可扩展标记语言配置访问协议(XCAP，XMLConfiguration Access Protocol)消息，本实施例中以REGISTER消息举例说明。注册请求消息的目的地址是应用服务器的地址。
应用服务器的地址信息，可以通过第三方的方式获知，例如通过客户端供应模块(Client Provision)输入、设备管理(DM，Device Management)方式输入或手工输入的方式配置给用户终端。
注册请求消息首先转发到P-CSCF，由P-CSCF发送到S-CSCF，最后由S-CSCF根据注册请求消息中的目的地址路由到应用服务器。
用户终端A发送的REGISTER消息如下所示：
REGISTER sip:cmr as.domain.com SIP/2.0；进行注册，协议版本类型
Via:SIP/2.0/UDP userpc.domain.com:5060；branch＝z9hG4bKnashds7；通过路径
Max-Forwards:70 ；转发次数
To:Bob<sip:user@domain.com> ；目的方
From:Bob<sip:user@domain.com>；tag＝456248 ；发起方
Call-ID:843817637684230@998sdasdh09 ；呼叫的唯一标识
CSeq:1826REGISTER ；命令的序列号
Require:pref
Supported:early-session，100rel
Contact:
<sip:user@192.0.2.4>；+sip.instance＝″<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>″+g.3gpp.icsi_ref＝″urn％3Aurn-xxx％3A3gpp-service.ims.icsi.cmr″
；铃音业务信息
Expires:7200 ；有效时间
Content-Length:0 ；消息体大小
其中，注册请求消息中的铃音业务信息主要是通过在Contact域中携带。其中的+g.3gpp.icsi_ref＝″urn％3Aurn-xxx％3A3gpp-service.ims.icsi.cmr″表示本次注册所希望完成的业务是可定制多媒体回铃音(CMR，CustomizedMultimedia Ringback tone)业务，也就是彩铃业务。同时，在一个Contact域中可以携带多个铃音业务信息，可以通过‘；’(分号)进行区分。
步骤202、用户终端A接收应用服务器返回的注册响应消息。
应用服务器接收注册请求消息后，获取其中的需开通的铃音业务信息，从而获知用户终端A希望启动铃音业务功能。应用服务器根据注册请求消息，向用户终端A返回一个200OK的成功应答响应消息(即注册响应消息)，表明接受注册过程。注册响应消息首先发到S-CSCF，由S-CSCF发送到P-CSCF，最后由P-CSCFF发送给用户终端A。
应用服务器响应的200OK消息如下所示：
SIP/2.0200OK ；成功应答
Via:SIP/2.0/UDP
userpc.domain.com:5060；branch＝z9hG4bKnashds7；received＝1.2.3.4；通过路径
To:Bob<sip:user@domain.com>；tag＝2493k59kd
From:Bob<sip:user@domain.com>；tag＝456248
Call-ID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Contact:
<sip:user@192.0.2.4>；+sip.instance＝″<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>″，+g.3gpp.icsi_ref＝″urn％3Aurn-xxx％3A3gpp-service.ims.icsi.cmr″
expires＝3600
Expires:7200
Content-Length:0
应用服务器在接收到注册请求消息之后，将用户终端A注册的数据和状态信息等进行缓存，以便后续业务开展的过程中使用。
需要说明的是，上述描述的是普通的注册方式，出于安全的考虑，可以增加鉴权机制。应用服务器在接收到没有包含鉴权信息的注册请求消息后，向用户终端A返回一个401未认证(Unauthorised)响应消息，要求用户终端A重新发起注册流程，并携带鉴权信息，则用户终端A接收到401未认证响应消息后，在注册请求消息中增加鉴权信息再发送给应用服务器。应用服务器接收注册请求消息并鉴权成功后，向用户终端A返回一个200OK的成功应答响应消息(即注册响应消息)，表明接受注册过程。另外，用户终端A也可以直接发送携带鉴权信息的注册请求消息。
通过上述过程，用户终端A成功向应用服务器进行了铃音业务的注册。对于用户终端B，其注册过程也是类似，不再另外描述。
那么，增加了用户终端的铃音业务的注册机制后，应用服务器在后续进行业务决策时就需要对用户终端的铃音业务是否注册进行判断，在判断出没有注册信息时，不会触发任何的铃音业务，在判断出有注册信息时，根据注册的具体业务类型触发相应业务，例如注册的是彩铃业务，则触发彩铃业务。因此，通过增加用户终端的铃音业务的注册过程，就实现了对铃音业务进行控制。
以下对注册过程完成后的流程作简单介绍：
(1)在用户终端的铃音业务的注册过程完成后，用户终端发起正常业务呼叫的流程。该流程属于现有的正常的呼叫流程，其目的在于建立两个用户终端之间端到端的通话连接。在呼叫建立过程当中，S-CSCF会在呼叫过程当中检查双方的业务签约关系，以触发相关的业务逻辑。
(2)在呼叫建立过程完成后，应用服务器根据用户终端注册信息进行业务决策。当S-CSCF根据业务签约关系，需要触发业务逻辑决策的时候，呼叫信令转发到应用服务器中。按现有的方式，应用服务器将直接呼叫用户终端B以及媒体资源功能实体(MRF)，但本发明实施例中引入了用户终端的铃音业务注册的机制，因此应用服务器需要对用户终端的铃音业务是否注册进行判断。应用服务器在判断出用户终端没有注册信息时，不会触发任何的铃音业务，在判断出在用户终端A和B都注册了铃音业务(例如彩铃业务)或只有一方注册了铃音业务的情况下，根据两方的业务签约信息情况，选择用户终端发送注册的铃音(例如彩铃)。
应用服务器决策后，确定如何进行下一阶段的呼叫，并确定如何告知用户终端需要触发注册的铃音业务。之后，整个过程将转入铃音业务呼叫的建立流程。
(3)用户终端之间铃音业务呼叫的建立流程。该过程主要根据应用服务器的决策来进行相应业务流程的触发。如果应用服务器决策需要建立多媒体回铃音，那么触发多媒体回铃音的建立过程；如果应用服务器决策建立多媒体振铃音，那么触发多媒体振铃音的建立过程；如果应用服务器决策需建立多媒体背景音，那么触发多媒体背景音的建立过程。
(4)用户终端之间铃音业务的进行过程。在用户终端之间铃音业务呼叫的建立流程完成后，MRF根据业务类型向对应的用户终端发送媒体流。假设是用户终端B向用户终端A发起呼叫，如果是单独存在向用户终端B发送媒体流，那么本次业务是多媒体振铃音业务，如果单独存在向用终端A发送媒体流，那么本次业务是多媒体回铃音业务，如果两者都存在，那么本次业务是多媒体背景音业务。
(5)用户终端之间进行正常通话。
从实施例二可以看出，实施例二是用户终端直接向应用服务器发起注册过程，通过注册进行业务的激活，这样就可实现对铃音业务进行控制，在后续就可以进一步使得应用服务器根据用户终端的业务注册信息对业务进行决策，从而促进各种铃音业务的进一步发展。
请参阅图3，是本发明实施例三通过第三方间接进行注册的流程图。与实施例二是用户终端直接进行注册相比，实施例三是通过第三方进行间接注册。图中从用户终端A的注册过程来举例说明，用户终端B的注册过程是类似的。
如图3所示，包括：
步骤301、用户终端A向呼叫会话控制功能实体发送注册请求消息；
用户终端A不需要知道应用服务器的地址信息，只需要获知S-CSCF的地址信息，生成注册请求消息发送给S-CSCF。注册请求消息中携带需开通的铃音业务信息，所述铃音业务可以是彩铃业务、彩振业务、彩像业务或多媒体彩铃业务、多媒体彩振业务、多媒体彩像业务等。注册请求消息，可以是SIP信令的REGISTER消息或者是XCAP消息，本实施例中以REGISTER消息举例说明。注册请求消息的目的地址是S-CSCF的地址。
该步骤的注册过程可以复用IMS业务中已有的注册的过程。注册请求消息首先转发到P-CSCF，由P-CSCF发送到S-CSCF。
用户终端A发送的SIP信令的REGISTER消息与例二中用户终端A发送给应用服务器的REGISTER消息基本相同，主要是目的地址不同，此处不再描述。
步骤302、呼叫会话控制功能实体将接收的注册请求消息的目的地址修改为应用服务器的地址并重新封装后，向应用服务器发送；
S-CSCF接收到用户终端A发送的注册请求消息后，向用户终端A返回一个200OK的成功应答响应消息(即注册响应消息)。该响应的200OK消息与例二中应用服务器返回给用户终端A的200OK消息基本相同，此处不再描述。
与此同时，S-CSCF解析注册请求消息中的头域信息，获知该注册请求消息是一个第三方注册请求消息，需要将这个注册请求消息转发到铃音业务所对应的服务器。S-CSCF选择应用服务器器，获取该应用服务器的地址信息。S-CSCF预先配置有各应用服务器的地址信息，或者S-CSCF可以通过域名服务器(DNS，Domain Name Server)查找应用服务器的地址信息。S-CSCF将接收的注册请求消息的目的地址修改为该应用服务器的地址，将用户终端的信息设置到To域，并将注册请求消息重新封装后向该应用服务器发送，从而相当于代表用户终端A发起第三方注册过程。
S-CSCF重新封装的REGISTER消息如下所示：
REGISTER sip:cmr_as.domain.com SIP/2.0
Via:SIP/2.0/UDPs_cscf.domain.com；branch＝z9hG4bK123dsghds
Max-Forwards:70
To:Bob<sip:user@domain.com>；tag＝456248
From:<sip:s_cscf.domain.com> ；To和From域的内容发生变化
Call-ID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Contact:<sip:s_cscf.domain.com>
Expires:7200
Content-Length:0
步骤303、呼叫会话控制功能实体接收应用服务器返回的注册响应消息。
应用服务器接收注册请求消息后，获取其中的需开通的铃音业务信息，从而获知用户终端希望启动铃音业务功能。应用服务器根据注册请求消息，向S-CSCF返回一个200OK的成功应答响应消息(即注册响应消息)，表明接受注册过程。
应用服务器在接收到注册请求消息之后，将用户终端注册的数据和状态信息等进行缓存，以便后续业务开展的过程中使用。
S-CSCF接收应用服务器返回的200OK的成功应答响应消息。
S-CSCF接收的200OK消息如下所示：
SIP/2.0200OK
Via:SIP/2.0/UDP
s_cscf.domain.com；branch＝z9hG4bK123dsghds；received＝1.2.3.4
To:Bob<sip:user@domain.com>；tag＝456248
From:<sip:s_cscf.domain.com>
Call-ID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Contact:<sip:s_cscf.domain.com>
Expires:7200
Content-Length:0
需要说明的是，上述描述的是普通的注册方式，出于安全的考虑，可以增加鉴权机制。应用服务器在接收到没有包含鉴权信息的注册请求消息后，向S-CSCF返回一个401未认证(Unauthorised)响应消息，要求用户终端A重新发起注册流程，并携带鉴权信息。S-CSCF将401未认证(Unauthorised)响应消息转发给用户终端A，由用户终端A接收到401未认证响应消息后，在注册请求消息中增加鉴权信息后再由S-CSCF发送给应用服务器。应用服务器接收注册请求消息并鉴权成功后，向S-CSCF返回一个200OK的成功应答响应消息(即注册响应消息)，表明接受注册过程。另外，用户终端A也可以直接发送携带鉴权信息的注册请求消息到S-CSCF。
通过上述过程，用户终端A通过呼叫会话控制功能实体成功向应用服务器进行了铃音业务的注册。对于用户终端B，其注册过程也是类似，不再另外描述。
那么，增加了用户终端的铃音业务的注册机制后，应用服务器在后续进行业务决策时就需要对用户终端的铃音业务是否注册进行判断，在判断出没有注册信息时，不会触发任何的铃音业务，在判断出有注册信息时，根据注册的具体业务类型触发相应业务，例如注册的是彩铃业务，则触发彩铃业务。因此，通过增加用户终端的铃音业务的注册过程，就实现了对铃音业务进行控制。
对于注册过程完成后的流程，在实施例二中已经详细介绍，此处不再另外叙述。
从实施例三可以看出，实施例三是用户终端通过呼叫会话控制功能实体间接向应用服务器发起第三方注册过程，通过注册进行业务的激活，这样就可实现对铃音业务进行控制，在后续就可以进一步使得应用服务器根据用户终端的业务注册信息对业务进行决策，从而促进各种铃音业务的进一步发展。
上述实施例二和实施例三分别介绍了用户终端直接进行注册和通过呼叫会话控制功能实体间接进行第三方注册的过程，以下分别介绍在注册完成后进行用户终端状态信息订阅的过程、进行业务参数配置的过程和进行去注册的过程，各过程分别对应实施例四、五、六。
以下各过程都以注册过程为用户终端通过呼叫会话控制功能实体间接进行第三方注册的过程为例但不局限于此，注册过程也可以是用户终端直接进行注册的情况。
请参阅图4，是本发明实施例四在注册完成后进行用户终端状态信息订阅的流程图。
用户终端通过S-CSCF进行第三方注册后，S-CSCF在之后的刷新注册的过程中，可能不会继续转发相关的注册信息到应用服务器中，所以可以通过应用服务器的订阅过程以让应用服务器周期性获取于用户终端的相关信息；同时，用户终端所关联的其他业务信息，如呈现业务(Presence业务)信息，也可以通过订阅过程以让应用服务器获得，从而使得应用服务器可以根据这些信息更好的提供业务，比如说，根据Presence业务信息中的心情状态信息，应用服务器可以更好地选择媒体内容等。
应用服务器的订阅过程可以采用订阅(SUBSCRIBE)/通知(NOTIFY)的机制实现。
如图4所示，包括步骤：
步骤401、呼叫会话控制功能实体接收应用服务器发送的用于订阅用户终端的状态信息的请求消息；
应用服务器在接收到注册请求消息例如通过S-CSCF发送的注册请求消息后，缓存相关的注册信息。另外，应用服务器向S-CSCF发送一个订阅请求消息(SUBSCRIBE请求消息)，订阅S-CSCF能够获取的关于用户终端的相关信息，包括与用户终端关联的其他业务所提供的信息，如Presence业务信息，以及用户终端在重新注册之后携带的信息等。
应用服务器发送的SUBSCRIBE请求消息如下所示：
SUBSCRIBE sip:user@domain.com SIP/2.0 ；订阅
Via:SIP/2.0/UDP cmr_as.domain.com；branch＝z9hG4bKnashds7
P-Asserted-Identity:sip:cmr_as.domain.com ；通过路径
To:<sip:s_cscf.domain.com>
From:<sip:cmr_as.domain.com；tag＝27182>
Call-ID:gbjg0b@cmr_as.domain.com
CSeq:9887SUBSCRIBE
Contact:<sip:cmr_as.domain.com>
Event:reg
Max-Forwards:70
Accept:application/reginfo+xml ；可接受类型
步骤402、呼叫会话控制功能实体向应用服务器返回含有所述用户终端的状态信息的响应消息。
S-CSCF在收到应用服务器发送的第一个SUBSCRIBE请求消息之后，会发送一个200OK的成功应答响应消息，标识本次请求成功。在发送完第一个200OK成功应答响应消息之后，S-CSCF发送一个NOTIFY消息，将目前S-CSCF所获知的并且应用服务器需要订阅的关于用户终端的相关状态信息发送给应用服务器。S-CSCF可以将用户终端的相关状态信息携带在NOTIFY消息的消息体中，并且可以是通过可扩展标记语言(XML，EXtensible Markup Language)的方式携带。
向应用服务器发送的NOTIFY消息如下所示：
NOTIFY sip:cmr_as.domain.com SIP/2.0 ；通知
Via:SIP/2.0/UDP s_cscf.domain.com；branch＝z9hG4bKnashds7
To:<sip:cmr_as.domain.com；tag＝262281>
From:<sip:s_cscf.domain.com；tag＝27182>
Call-Id:gbjg0b@cmr_as.domain.com
CSeq:633NOTIFY
Subscription-State:active；expires＝3600
Event:reg
Max-Forwards:70
Content-Type:application/reginfo+xml
Contact:<sip:s_cscf.domain.com>
Content-Length:...
<？xml version＝″1.0″？>
<reginfo xmlns＝″urn:ietf:params:xml:ns:reginfo″
xmlns:gr＝″urn:ietf:params:xml:ns:gruuinfo″
version＝″1″state＝″full″>
<registration aor＝″sip:user@domain.com″id＝″a7″state＝″active″>
<contact id＝″92″state＝″active″event＝″registered″
duration-registered＝″1″expires＝″3599″
callid＝″843817637684230@998sdasdh09″cseq＝″1826″>
<uri>sip:user@domain.com</uri>
<unknown-param name＝″+sip.instance″>
″<；urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>；″
</unknown-param> ；上述为用户终端相关信息
</contact>
</registration>
应用服务器在接收到这个NOTIFY消息之后，发送200OK成功应答响应消息进行确认。
之后，S-CSCF可以根据一定的设置规则，例如隔一段时间，或者在用户终端的相关信息发生变化时，向应用服务器发送NOTIFY消息，以使应用服务器获知用户终端的相关信息的变化。
在订阅过程完成后，将进行后续处理的过程，如实施例二中(1)-(5)中的过程所描述，此处不再另外叙述，所不同的是，应用服务器的决策过程中还需要进一步参考通过订阅过程获得的用户终端的相关信息。
从实施例四可以看出，在完成注册的过程之后，应用服务器通过向S-CSCF发送SUBSCRIBE请求消息，用于订阅关于用户终端的变化的信息，从而可以使得应用服务器上配置有用户终端的相关信息，就可以在参考注册信息的基础上进一步参考用户终端的变化信息对业务进行决策，促进各种铃音业务的进一步发展，并减少在呼叫过程中对用户终端信息的依赖。
请参阅图5，是本发明实施例五在注册完成后进行业务参数配置的流程图。
用户终端通过S-CSCF进行第三方注册后，用户终端可以向S-CSCF发起信息的发布过程，通过发布消息(PUBLISH消息)携带业务参数，例如用户的喜好，以及用户终端的业务参数等，S-CSCF将该PUBLISH消息转发到相应的应用服务器，用于对用户终端所所关联的业务进行配置。
如图5所示，包括步骤：
步骤501、用户终端A向呼叫会话控制功能实体发送用于铃音业务的业务参数；
用户终端可以将自身业务相关的业务参数设置到PUBLISH消息中，发送给应用服务器。用户终端可以设置的业务参数信息包括：是否激活彩铃业务，是否去激活彩铃业务，彩铃业务针对每个用户的配置，包括媒体类型、振铃方式等；彩铃业务的优先级设置；彩铃业务的管理列表；彩铃业务的播放时间；彩铃业务的过滤规则等。
上述业务参数具体是设置在PUBLISH消息的消息体中，并且可以采用XML的方式。所以，在PUBLISH消息的content-Type字段中，需要通过application/cmr-settings+xml对消息体内容进行标识，同时还需要通过将Event字段设置为cmr-settings，说明该PUBLISH消息中所携带信息的主要目的。在本实施例中，只是通过PUBLISH消息的部分的设置功能来说明设置的过程但不局限于此。
用户终端A先将PUBLISH消息发送给P-CSCF，由P-CSCF转发给S-CSCF。
假设需要进行的配置是可定制振铃音(CAT)业务的激活过程以及一个对1380001380000的号码的可定制振铃音(CAT，Customized Alerting Tones)业务的阻止过程，具体业务参数是通过XML方式进行携带，则PUBLISH消息可以如下所示：
PUBLISH sip:user@domain.com SIP/2.0 ；发布
Via:SIP/2.0/UDP userpc.domain.com:5060；branch＝z9hG4bKnashds7
P-Preferred-Identity:″Bob″<sip:user@domain.com>
Max-Forwards:70
To:Bob<sip:user@domain.com>
From:Bob<sip:user@domain.com>；tag＝456248
Call-ID:843817637684230@998sdasdh09
CSeq:1846PUBLISH
Accept-Contact:*；require；explicit
Contact:
<sip:user@192.0.2.4>；+sip.instance＝″<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>″+g.3gpp.icsi ref＝″urn％3Aurn-xxx％3A3gpp-service.ims.icsi.cmr″
Event:cmr-settings ；目的是业务参数设置
Content-Type:application/cmr-settings+xml
Content-Length:0
<？xml version＝″1.0″encoding＝″UTF-8″？>
<cmr-settings xmlns＝″urn:ietf:params:xml:ns:cmr-settings″
xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″
version＝″1″state＝″full″>
<entity id＝″do39s8zksn2d98x″>
<cat-settings>
<cat-service-enable active＝″true″/>
<cat-block-enable active＝”true”>
<cat-block-list user＝”1380001380000”/>
</cat-block-enable>
</cat-settings>
<crs-settings>
</crs-settings>
<cbt-settings>
<cbt-settings>
</entity> ；上述内容为业务参数配置
</cmr-settings>
需要说明的是，这里只是以CAT业务举例说明，其他例如可定制铃声信号(CRS，Cusomized Ringing Signal)等业务功能实现的方式类似。
步骤502、呼叫会话控制功能实体向应用服务器转发用于铃音业务的业务参数。
S-CSCF在接收到这个PUBLISH消息之后，向用户终端A返回一个200OK的成功应答响应消息。
同时，S-CSCF根据PUBLISH消息的Contact域中的业务信息，定位应用服务器，将PUBLISH消息发送到相关的应用服务器。
S-CSCF向应用服务器发送的PUBLISH消息与用户终端发送的PUBLISH消息基本相同，只是有些设置发生变化，主要是以下几个域的变化：
PUBLISH sip:user@domain.com SIP/2.0
To:<sip:cmr_as.domain.com>；
From:<sip:s_cscf.domain.com>；tag＝27182
Contact:<sip:s_cscf.domain.com>
应用服务器接收到PUBLISH消息之后，将PUBLISH消息当中携带的业务参数信息进行缓存，并根据业务参数信息开展相关的业务。
在进行业务参数配置过程完成后，将进行后续处理的过程，如实施例二中(1)-(5)中的过程所描述，此处不再另外叙述，所不同的是，应用服务器在触发业务过程中还需要进一步参考通过业务参数配置过程所配置的业务参数。
从实施例五可以看出，在注册过程完成后，用户终端可以将铃音业务的相关参数在启动业务的过程中传递到应用服务器，从而完善了业务流程。
请参阅图6，是本发明实施例六在注册完成后去注册的流程图。
在用户终端完成了铃音业务的注册流程之后，由于业务的需要，可能需要进行去注册，因此本发明实施例还提供铃音业务的去注册流程。去注册流程也可以分为由用户终端直接向应用服务器进行去注册和用户终端通过呼叫会话控制功能实体间接向应用服务器进行第三方去注册。
本实施例六以用户终端通过呼叫会话控制功能实体间接向应用服务器进行第三方去注册举例说明。用户终端向S-CSCF发送去注册请求消息，发起去注册流程，用来对业务进行去激活，S-CSCF接收到去注册请求消息后，代替用户终端向多媒体彩铃服务器进行第三方去注册。在此之后，应用服务器就可以根据用户终端的去激活操作，取消彩铃音业务例如彩铃业务与呼叫业务的关联关系，在之后的呼叫过程中，根据这个取消关系决策出不触发铃音业务例如多媒体彩铃业务。
如图6所示，包括步骤：
步骤601、用户终端A向呼叫会话控制功能实体发送去注册请求消息；
用户终端A不需要知道应用服务器的地址信息，只需要获知S-CSCF的地址信息，生成去注册请求消息发送给S-CSCF。去注册请求消息中携带需去注册的铃音业务信息。
将注册请求消息(REGISTER消息)中的Expires域中携带有效时间设置为0，就可以表明这是一个业务的去注册请求消息。去注册请求消息的目的地址是S-CSCF的地址。
应用服务器发送的去注册请求消息与实施例三中应用服务器发送的注册请求消息的格式基本相同，所不同的是Expires域改为设置为0。
去注册请求消息首先转发到P-CSCF，由P-CSCF发送到S-CSCF。
步骤602、呼叫会话控制功能实体将接收的去注册请求消息的目的地址修改为应用服务器的地址并重新封装后，向应用服务器发送；
S-CSCF接收到用户终端A发送的去注册请求消息后，向用户终端A返回一个200OK的成功应答响应消息(即注册响应消息)。
S-CSCF发送的200OK消息与实施例三中S-CSCF发送的200OK消息格式基本相同，所不同的是Expires域改为设置为0。
与此同时，S-CSCF解析去注册请求消息中的头域信息，获知该注册请求消息是一个第三方去注册请求消息，需要取消相关业务的注册关联关系，并需要将这个去注册请求消息转发到铃音业务所对应的服务器。
S-CSCF将接收的去注册请求消息的目的地址修改为该应用服务器的地址，将用户终端的信息设置到To域，并将去注册请求消息重新封装后向该应用服务器发送，从而相当于代表用户终端A发起第三方去注册过程。
S-CSCF发送的去注册请求消息与实施例三中S-CSCF发送的注册请求消息的格式基本相同，所不同的是Expires域改为设置为0。
步骤603、呼叫会话控制功能实体接收应用服务器返回的去注册响应消息。
应用服务器在接收到去注册请求消息之后，缓存去注册请求消息所携带的信息，并返回一个200OK的成功应答响应消息到S-CSCF，表明去注册过程已成功。
在此后，用户终端建立相关的呼叫会话的过程当中，将不会激活相关的铃音业务例如彩铃业务。如果需要激活铃音业务，需要重新启动注册。
应用服务器发送的200OK消息与实施例三中应用服务器发送的200OK消息格式基本相同，所不同的是Expires域改为设置为0。
需要说明的是，本实施例中，可以把各种不同的铃音业务作为一个整体业务进行考虑和标识，例如分别标识彩振业务、彩铃业务、背景音业务等，就可以实现不同子业务的激活和去激活。
还需要说明的是，如果是用户终端直接向应用服务器发送去注册请求消息，其流程与实施例一中的直接注册流程类似，只是将原注册请求消息中的Expires头域中携带有效时间设置为0，以表明这是一个业务的去注册请求消息。去注册请求消息的目的地址是应用服务器的地址。
从实施例六可以看出，本发明实施例技术方案在提供了注册过程后，进一步提供了一种根据业务需要进行去注册的过程，从而使得业务流程更加完善。
上述内容详细介绍了本发明实施例铃音业务处理方法，相应的，本发明实施例提供一种应用服务器、处理装置和网络系统。
请参阅图7，是本发明实施例应用服务器结构示意图。
如图7所示，应用服务器包括：第一接收单元71、第一发送单元72。
第一接收单元71，用于接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
第一发送单元72，用于根据所述接收单元接收的注册请求消息，向发送所述注册请求消息的发送方返回注册响应消息。
应用服务器还包括：第二接收单元73，用于接收所述用户终端通过所述呼叫会话控制功能实体发送的用于铃音业务的业务配置参数，所述业务配置参数由所述用户终端接收到所述第一发送单元72返回的注册响应消息后发送。
所述第一接收单元71具体用于接收用户终端通过呼叫会话控制功能实体直接转发的注册请求消息；或者，接收呼叫会话控制功能实体发送的注册请求消息，所述注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的注册请求消息的目的地址修改为应用服务器的地址并重新封装后向所述应用服务器发送的消息。
应用服务器还包括：第二发送单元74、第三接收单元75。
第二发送单元74，用于在所述第一发送单元72发送注册响应消息后，向所述呼叫会话控制功能实体发送订阅用户终端的状态信息的请求消息；
第三接收单元75，用于接收所述呼叫会话控制功能实体返回的含有所述用户终端的状态信息的响应消息。
应用服务器还包括：第四接收单元76，用于接收用户终端通过呼叫会话控制功能实体直接转发的去注册请求消息，所述去注册请求消息由所述用户终端接收到所述第一发送单元72返回的注册响应消息后发送；或者，接收呼叫会话控制功能实体发送的去注册请求消息，所述去注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的去注册请求消息的目的地址修改为应用服务器的地址并重新封装后向所述应用服务器发送的消息，其中所述用户终端是在接收到所述第一发送单元72返回的注册响应消息后向呼叫会话控制功能实体发送去注册请求消息。
请参阅图8，是本发明实施例处理装置一结构示意图。
如图8所示，所述处理装置为用户终端，包括：
发送单元702，用于向应用服务器发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；所说的铃音业务，可以是彩铃业务、彩振业务和彩像业务，或者是多媒体彩铃业务、多媒体彩振业务和多媒体彩像业务等。
接收单元703，用于接收所述应用服务器返回的注册响应消息。
所述用户终端还包括：业务参数单元704。
业务参数单元704，用于在接收单元703接收所述应用服务器返回的注册响应消息后，通过所述呼叫会话控制功能实体向所述应用服务器发送用户终端用于铃音业务的业务配置参数。
所述用户终端还包括：去注册单元705。
去注册单元705，用于在接收单元703接收所述应用服务器返回的注册响应消息后，向所述应用服务器发送去注册请求消息，所述去注册请求消息中携带需去注册的铃音业务信息。
请参阅图9，是本发明实施例处理装置二结构示意图。
如图9所示，所述处理装置为呼叫会话控制功能实体，包括：
发送单元802，用于向应用服务器发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
接收单元803，用于接收所述应用服务器返回的注册响应消息。
所述呼叫会话控制功能实体还包括：
处理单元804，用于接收用户终端发送的目的地址为呼叫会话控制功能实体的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息，将接收的所述注册请求消息的目的地址修改为应用服务器的地址并重新封装后，传递给所述发送单元802。
所述呼叫会话控制功能实体还包括：
订阅处理单元805，用于在接收单元803接收所述应用服务器返回的注册响应消息后，接收所述应用服务器发送的订阅用户终端的状态信息的请求消息，向所述应用服务器返回含有所述用户终端的状态信息的响应消息。
所述呼叫会话控制功能实体还包括：
去注册单元806，用于在接收单元803接收所述应用服务器返回的注册响应消息后，向所述应用服务器发送去注册请求消息，所述去注册请求消息中携带需去注册的铃音业务信息。
请参阅图10，是本发明实施例网络系统结构示意图。
如图10所示，网络系统包括：
处理装置901，用于向应用服务器902发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息，接收所述应用服务器902返回的注册响应消息；
应用服务器902，用于接收所述处理装置901发送的注册请求消息后，根据所述注册请求消息向所述处理装置901发送注册响应消息。
所述处理装置901在接收所述应用服务器902返回的注册响应消息后，向所述应用服务器902发送去注册请求消息，所述去注册请求消息中携带需去注册的铃音业务信息。
所述处理装置901可以是用户终端，具有图8所示结构，可以参见图8所描述；所述处理装置901还可以是呼叫会话控制功能实体，具有图9所示结构，可以参见图9所描述。
综上所述，本发明实施例提供了用户终端的铃音业务注册过程，可以通过注册进行业务的激活，这样就可实现对铃音业务进行控制，并且后续可以进一步使得应用服务器根据用户终端的业务注册信息对业务进行决策，从而促进各种铃音业务的进一步发展。
以上对本发明实施例所提供的铃音业务处理方法、应用服务器、处理装置和网络系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
Claims (19)
1.一种铃音业务处理方法，其特征在于，包括：
应用服务器接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息。
2.根据权利要求1所述的铃音业务处理方法，其特征在于：
所述接收的注册请求消息中进一步包括鉴权信息；
所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息具体为：
所述应用服务器根据所述鉴权信息进行鉴权并确定鉴权通过后，向发送所述注册请求消息的发送方返回注册响应消息。
3.根据权利要求1所述的铃音业务处理方法，其特征在于：
所述应用服务器接收用户终端的注册请求消息具体为：
应用服务器接收用户终端通过呼叫会话控制功能实体直接转发的注册请求消息。
4.根据权利要求1所述的铃音业务处理方法，其特征在于：
所述应用服务器接收用户终端的注册请求消息具体为：
应用服务器接收呼叫会话控制功能实体发送的注册请求消息，所述注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的注册请求消息的目的地址修改为应用服务器的地址并重新封装后向所述应用服务器发送的消息。
5.根据权利要求3或4所述的铃音业务处理方法，其特征在于：
所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息之后进一步包括：
应用服务器向所述呼叫会话控制功能实体发送订阅用户终端的状态信息的请求消息；
接收所述呼叫会话控制功能实体返回的含有所述用户终端的状态信息的响应消息。
6.根据权利要求3或4所述的铃音业务处理方法，其特征在于：
所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息之后进一步包括：
应用服务器接收所述用户终端通过所述呼叫会话控制功能实体发送的用于铃音业务的业务配置参数。
7.根据权利要求3或4所述的铃音业务处理方法，其特征在于：
所述应用服务器向发送所述注册请求消息的发送方返回注册响应消息之后进一步包括：
应用服务器接收用户终端通过呼叫会话控制功能实体直接转发的去注册请求消息；或者，
应用服务器接收呼叫会话控制功能实体发送的去注册请求消息，所述去注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的去注册请求消息的目的地址修改为应用服务器的地址并重新封装后向所述应用服务器发送的消息；
其中所述去注册请求消息中携带需去注册的铃音业务信息。
8.一种应用服务器，其特征在于，包括：
第一接收单元，用于接收用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
第一发送单元，用于根据所述接收单元接收的注册请求消息，向发送所述注册请求消息的发送方返回注册响应消息。
9.根据权利要求8所述的应用服务器，其特征在于，还包括：
第二接收单元，用于接收所述用户终端通过所述呼叫会话控制功能实体发送的用于铃音业务的业务配置参数，所述业务配置参数由所述用户终端接收到所述第一发送单元返回的注册响应消息后发送。
10.根据权利要求8所述的应用服务器，其特征在于：
所述第一接收单元具体用于接收用户终端通过呼叫会话控制功能实体直接转发的注册请求消息；或者，
接收呼叫会话控制功能实体发送的注册请求消息，所述注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的注册请求消息的目的地址修改为应用服务器的地址并重新封装后向所述应用服务器发送的消息。
11.根据权利要求8所述的应用服务器，其特征在于，还包括：
第二发送单元，用于在所述第一发送单元发送注册响应消息后，向所述呼叫会话控制功能实体发送订阅用户终端的状态信息的请求消息；
第三接收单元，用于接收所述呼叫会话控制功能实体返回的含有所述用户终端的状态信息的响应消息。
12.根据权利要求8至11任一项所述的应用服务器，其特征在于，还包括：
第四接收单元，用于接收用户终端通过呼叫会话控制功能实体直接转发的去注册请求消息，所述去注册请求消息由所述用户终端接收到所述第一发送单元返回的注册响应消息后发送；或者，
接收呼叫会话控制功能实体发送的去注册请求消息，所述去注册请求消息是所述呼叫会话控制功能实体将所述用户终端发送的去注册请求消息的目的地址修改为应用服务器的地址并重新封装后向所述应用服务器发送的消息，其中所述用户终端是在接收到所述第一发送单元返回的注册响应消息后向呼叫会话控制功能实体发送去注册请求消息。
13.一种处理装置，其特征在于，包括：
发送单元，用于向应用服务器发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息；
接收单元，用于接收所述应用服务器返回的注册响应消息。
14.根据权利要求13所述的处理装置，其特征在于：
所述处理装置为用户终端，所述用户终端还包括：
业务参数单元，用于在接收单元接收所述应用服务器返回的注册响应消息后，通过呼叫会话控制功能实体向所述应用服务器发送用户终端用于铃音业务的业务配置参数。
15.根据权利要求13所述的处理装置，其特征在于：
所述处理装置为呼叫会话控制功能实体，所述呼叫会话控制功能实体还包括：
处理单元，用于接收用户终端发送的目的地址为呼叫会话控制功能实体的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息，将接收的所述注册请求消息的目的地址修改为应用服务器的地址并重新封装后，传递给所述发送单元。
16.根据权利要求15所述的处理装置，其特征在于：
所述处理装置为呼叫会话控制功能实体时，所述呼叫会话控制功能实体还包括：
订阅处理单元，用于在接收单元接收所述应用服务器返回的注册响应消息后，接收所述应用服务器发送的订阅用户终端的状态信息的请求消息，向所述应用服务器返回含有所述用户终端的状态信息的响应消息。
17.根据权利要求13至16任一项所述的处理装置，其特征在于，所述处理装置还包括：
去注册单元，用于在接收单元接收所述应用服务器返回的注册响应消息后，向所述应用服务器发送去注册请求消息，所述去注册请求消息中携带需去注册的铃音业务信息。
18.一种网络系统，其特征在于，包括：
处理装置，用于发送用户终端的注册请求消息，所述注册请求消息中携带需开通的铃音业务信息，接收应用服务器返回的注册响应消息；
应用服务器，用于接收所述处理装置发送的用户终端的注册请求消息，根据所述注册请求消息向所述处理装置返回注册响应消息。
19.根据权利要求18所述的网络系统，其特征在于：
所述处理装置在接收所述应用服务器返回的注册响应消息后，向所述应用服务器发送去注册请求消息，所述去注册请求消息中携带需去注册的铃音业务信息。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810185720A CN101754181A (zh) | 2008-12-08 | 2008-12-08 | 铃音业务处理方法、应用服务器、处理装置和网络系统 |
| PCT/CN2009/075238 WO2010066167A1 (zh) | 2008-12-08 | 2009-12-01 | 铃音业务处理方法、应用服务器、处理装置和网络系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810185720A CN101754181A (zh) | 2008-12-08 | 2008-12-08 | 铃音业务处理方法、应用服务器、处理装置和网络系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101754181A true CN101754181A (zh) | 2010-06-23 |
Family
ID=42242345
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200810185720A Pending CN101754181A (zh) | 2008-12-08 | 2008-12-08 | 铃音业务处理方法、应用服务器、处理装置和网络系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101754181A (zh) |
| WO (1) | WO2010066167A1 (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101969617A (zh) * | 2010-10-13 | 2011-02-09 | 中兴通讯股份有限公司 | 一种java应用的方法及系统 |
| CN104427484A (zh) * | 2013-09-02 | 2015-03-18 | 阿尔卡特朗讯 | 一种用于向应用服务器传送应用数据的方法与设备 |
| WO2019095379A1 (zh) * | 2017-11-20 | 2019-05-23 | Oppo广东移动通信有限公司 | 一种业务激活及去激活的方法、装置、计算机存储介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100394809C (zh) * | 2002-12-09 | 2008-06-11 | 北京凯华网联技术有限公司 | 移动电话智能网上实现电话呼叫回铃音替换的方法 |
| CN100411391C (zh) * | 2006-06-02 | 2008-08-13 | 中国移动通信集团公司 | 基于ip多媒体子系统实现个性化回铃音的系统及方法 |
| CN101304324B (zh) * | 2007-05-11 | 2011-04-06 | 朱波 | 视频彩铃的实现方法及系统 |
| CN101141692A (zh) * | 2007-10-11 | 2008-03-12 | 中兴通讯股份有限公司 | 多媒体彩铃业务的实现方法 |
-
2008
- 2008-12-08 CN CN200810185720A patent/CN101754181A/zh active Pending
-
2009
- 2009-12-01 WO PCT/CN2009/075238 patent/WO2010066167A1/zh active Application Filing
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101969617A (zh) * | 2010-10-13 | 2011-02-09 | 中兴通讯股份有限公司 | 一种java应用的方法及系统 |
| CN104427484A (zh) * | 2013-09-02 | 2015-03-18 | 阿尔卡特朗讯 | 一种用于向应用服务器传送应用数据的方法与设备 |
| CN104427484B (zh) * | 2013-09-02 | 2019-03-29 | 阿尔卡特朗讯 | 一种用于向应用服务器传送应用数据的方法与设备 |
| WO2019095379A1 (zh) * | 2017-11-20 | 2019-05-23 | Oppo广东移动通信有限公司 | 一种业务激活及去激活的方法、装置、计算机存储介质 |
| US11051268B2 (en) | 2017-11-20 | 2021-06-29 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Service activation and deactivation method, device and computer storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010066167A1 (zh) | 2010-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10609099B2 (en) | System and method for implementing media and media control transfer between devices | |
| CN101682617B (zh) | 确定多媒体能力的方法、多媒体应用服务器及系统 | |
| CN101401384B (zh) | 用于将用户注册到ip多媒体子系统或从ip多媒体子系统取消用户注册的方法和装置 | |
| US20100312832A1 (en) | System and method for implementing media and media control transfer between devices | |
| US20110040836A1 (en) | System and method for implementing media and media control transfer between devices | |
| CN101313553B (zh) | Ip多媒体子系统中的消息处理 | |
| US8423652B2 (en) | Service templates for an IP multimedia subsystem | |
| US8363560B2 (en) | System and method for enhanced proxy component | |
| CN102726023B (zh) | 在基于sip的通信网络中向接收订户转发具有相关联的提醒信息的sip请求消息的方法和设备 | |
| US20090122794A1 (en) | Packet network and method implementing the same | |
| US10027724B2 (en) | Methods and apparatus for implementing a conference call | |
| EP1875714A2 (en) | Session initiation from application servers in an ip multimedia subsystem | |
| CN100446587C (zh) | 一种实现多媒体彩铃音业务的系统及方法 | |
| CN101529883B (zh) | 向匿名呼叫者提供组合服务的系统和方法 | |
| CN101459735B (zh) | 一种彩铃、彩像业务的实现方法及系统 | |
| CN1921482B (zh) | 一种基于会话发起协议的业务处理方法和装置 | |
| CN101754181A (zh) | 铃音业务处理方法、应用服务器、处理装置和网络系统 | |
| KR101177601B1 (ko) | 패킷 교환 통신 세션을 설정하는 방법 및 장치 | |
| US20130148652A1 (en) | Method, Computer-Readable Medium, and Apparatus for Providing Different Services to Different Users of an Aggregate Endpoint in an Internet Protocol Multimedia Subsystem (IMS) Network | |
| CN101511127A (zh) | 一种实现多媒体彩铃音业务的系统及方法 | |
| CN101222540B (zh) | 用于ip多媒体子系统的多媒体业务实现方法 | |
| CN104053121A (zh) | 彩铃业务实现系统、装置及方法 | |
| CN101742448B (zh) | 实现呼叫转向业务的方法、装置和系统 | |
| CN101448011A (zh) | 早媒体信息播放选择方法 | |
| CN103181139A (zh) | 指示ims网络中的转移 |
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: 20100623 |