CN101854440A - 一种多媒体铃音上传方法、多媒体铃音服务器及ue - Google Patents

Abstract

本发明是关于一种多媒体铃音上传方法、多媒体铃音服务器及UE，所述的方法包括：与用户设备UE协商建立消息会话中继协议MSRP会话；接收UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。本发明实施例的有益效果在于使用户可以通过UE上传及配置多媒体铃音。

Description

一种多媒体铃音上传方法、多媒体铃音服务器及UE

技术领域

本发明是关于通信领域，特别是一种多媒体铃音上传方法、多媒体铃音服务器及系统。

背景技术

多媒体铃音是一种被叫业务，当主叫发起呼叫到被叫时，如被叫开通该业务，则主叫等候被叫接听电话时的铃音将会被被叫定制的音乐、视频等媒体替代。现有运营商的多媒体铃音业务主要由其终端的功能来支撑。用户下载多媒体铃音并进行设置后，当他人给该用户拨打可视电话时，终端向主叫播放多媒体铃音。同语音彩铃业务与彩振，彩像一样。除了被叫定制，主叫拨打可视电话时收听到多媒体彩铃的多媒体彩铃业务形态，还存在相关的多媒体振铃音，多媒体背景音业务。多媒体铃音业务是多媒体彩铃业务，多媒体振铃音业务，多媒体背景音业务的总称。

目前铃音业务当中，主要规定如何在呼叫过程当中对铃音业务进行信令的接续，以便建立起正常的铃音通话的过程，尚未对铃音业务过程当中的内容管理和上传方式进行任何的规定。目前用户只能够通过WEB浏览器，或者客服电话的方式，对铃音资源进行设置。

然而上述两种方式存在以下问题：

通过WEB的方式进行铃音内容的设置，一般情况下只能够选择服务器所规定的铃音内容，虽然能够在设置之前进行试听，但是用户需要通过特定的浏览器，或者计算机才能够实现，不能够把内容和移动终端完美的结合起来。

通过客服电话的方式，这种方式需要人工的参与，用户可能很难准确的描述自己所期望的动作，在交互过程当中容易出现错误；同时，由于没有可视的界面，用户的直观感受不强烈。

发明内容

本发明实施例中提供一种多媒体铃音上传方法，所述的方法包括：与用户设备UE协商建立消息会话中继协议MSRP会话；接收UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。

本发明实施例中还提供一种多媒体铃音服务器，所述多媒体铃音服务器包括：MSRP会话建立单元，用于与UE协商建立MSRP会话；铃音文件处理单元，用于接收UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。

本发明实施例中还提供一种多媒体铃音上传方法，所述的方法包括：与多媒体铃音服务器协商建立MSRP会话；向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

本发明实施列中还提供一种UE，所述UE包括：MSRP会话建立单元，用于与多媒体铃音服务器协商建立MSRP会话；多媒体铃音文件发送单元，向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

本发明实施列中还提供一种多媒体铃音上传系统，所述系统包括：多媒体铃音服务器，用于接收UE通过MSRP消息发送的多媒体铃音文件，作为所述UE的可选多媒体铃音UE，向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

本发明实施例的有益效果在于使用户可以通过UE上传及配置多媒体铃音。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一的多媒体铃音上传方法流程图；

图2为本发明实施例二的多媒体铃音上传方法信令图；

图3为本发明实施例三的配置多媒体铃音的信令图；

图4为本发明实施例三的配置多媒体铃音的信令图；

图5为本发明实施例四下发多媒体铃音的流程图；

图6为本发明实施例四的多媒体铃音上传方法信令图；

图7为本发明实施例五的多媒体铃音服务器结构图；

图8为本发明实施例六的多媒体铃音服务器结构图；

图9本发明实施例七的多媒体铃音服务器结构图；

图10本发明实施例八的多媒体铃音服务器结构图；

图11本发明实施例九的多媒体铃音上传方法流程图；

图12本发明实施例十一的UE结构图；

图13本发明实施例十二的UE结构图；

图14本发明实施例十三的多媒体铃音上传系统结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

通过本发明的实施例可以解决如下的技术问题：

解决目前业务开展过程当中铃音业务上传和业务开展分离的问题；

解决目前业务开展过程当中，需要通过第三方进行内容上传，用户无法上传一些自定义的内容的方式。

解决目前业务开展过程当中，终端无法对铃音内容进行定位的问题。

解决目前业务开展过程当中，铃音服务器下发内容的方式只能够通过Http去主动获取的方式的问题。

本发明实施例所需要解决的问题主要集中在网络之间互连协议(InternetProtocol，IP)多媒体子系统(IP Multimedia Subsystem，IMS)的方式当中，并结合目前的实现方式进行详细的说明。

本发明实施例通过现有的网络实现多媒体铃音业务中业务内容的上传和分发的功能。所涉及的网络集中在IP多媒体子系统(IMS域)当中多媒体铃音业务的业务内容的上传和分发的方法。通过现有的SIP消息提供的内容传送的机制，设计相关的内容传送的铃音系统架构，实现IMS下多媒体铃音业务的业务内容上传功能；同时，利用上述技术，新增一种和HTTP AS模式相对应的铃音业务开展模式，MSRP模式。整个方法包括利用SIP技术实现多媒体铃音业务的内容上传和分发功能。

上述的过程和功能，都是在现有的IMS网络，以及开展IMS可视电话多媒体铃音业务过程当中实现的。在这个过程当中会涉及对目前现有的网络流程，信令的使用，信令消息的格式，用法等方面的修改，具体内容将在具体实施例当中详细说明。

消息会话中继协议(Message Session Relay Protocol，MSRP)是一个基于文本、面向连接的协议，该协议可以用于任何的多功能Internet邮件扩充服务(Multipurpose Internet Email Extension，MIME)内容交换，特别适合即时消息应用，当然，除了即时消息内容之外，MSRP还可以传输其他的一些内容，比如可以用于Video Sharing过程中除了实时多媒体内容外的其他内容的传输。MSRP协议提供的是一套即时通讯(Instant Messaging，IM)内容的传输机制，他并不提供上层的内容协商和控制机制，这部分的内容它需要依靠其他的协议来完成。比如说，会话初始协议(Session Initiation Protocol，SIP)和会话描述协议(Session Description Protocol，SDP)。MSRP通过利用SIP和SDP现有的机制，完成整个会话内容的协商，会话的建立过程。MSRP在会话完成后，通过会话阶段所写上的媒体参数，以及用户之间的参数，进行相应的通信联系。MSRP，主要是通过MSRP消息和MSRP应答响应来完成整个内容的传输过程的。在整个会话的过程当中，他会复用其他的协议。

实施例一：

本发明第一实施例提供一种多媒体铃音上传方法，如图1所示所述的方法包括：

步骤S101：与用户设备UE协商建立消息会话中继协议MSRP会话。

步骤S102：接收UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。

本实施例中涉及IMS子系统，IMS子系统主要功能实体包括：呼叫会话控制功能(Call Session Control Function，CSCF)，家庭用户服务(HomeSubscriber Server，HSS)，多媒体资源功能(Multimedia Resource Function，MRF)，IMS-媒体网关(IMS-Media Gateway，IMS-MGW)，媒体网关控制功能(Media Gateway Control Function，MGCF)，出口网关控制功能(BreakoutGateway Control Function，BGCF)。IMS子系统中的设备为本领域技术人员所公知，此处不做赘述，本实施例的方法应用于增设在IMS子系统的可定制多媒体回铃音(Customized Multimedia Ringback tone，CMR)MRF中。

步骤S102中将多媒体铃音文件与所述UE建立对应关系可以是存储在多媒体铃音配置文件中，所述多媒体铃音配置文件为多媒体铃音文件与所述UE的对应关系表，其中包括所述UE及所述多媒体铃音的唯一标识。

本实施例通过MSRP上传多媒体铃音业务内容：整个UE完成了IMS的注册之后，具有了和多媒体铃音服务器之间沟通的通道，在这个过程当中，可以利用SIP建立的通道通过MSRP的方式向多媒体铃音服务器上传UE所希望的多媒体铃音内容，同时，在完成上传的过程之后，多媒体铃音服务器为上传的内容分配一个唯一的ID或者URI。

本实施例的有益效果在于使多媒体铃音服务器可以接收通过UE上传多媒体铃音。

实施例二：

如实施例一所揭示的方法，其中步骤S101在本实施例中可细化为：接收UE通过会话初始协议SIP的INVITE消息发送的包含会话描述协议SDP信息的MSRP会话邀请，发送携带相应SDP信息的SIP的200ok响应。

本实施例中利用SIP来完成SDP的交换过程。SIP消息和SIP代理框架结构的具体细节信息为本领域技术人员所公知将由于简化起见被忽略。在本例当中，请求的发起者是SIP：UE@example.com，请求的接受者是SIP：MRF@example.com。

以下请参考图2，图2为本实施例方法的信令图，其中SIP/IP核心网(Core)主要包括一些SIP代理和SIP注册服务器(在IMS中既为CSCF)功能主要有：CMR客户端和服务器之间SIP信令的路由、提供地址解析和寻址功能、支持SIP压缩、根据用户的业务特征对用户进行认证和鉴权、保持登记状态、提供计费信息。

上述信令图中的具体步骤包括：

1.UE构造了一个本地的统一资源定位符(Uniform Resource Locator，URL)，其本地的URL地址为：msrp://UE.example.com:7777/iau39；tcp。此时，UE决定通过SIP协议向多媒体铃音服务器发起一个MSRP的邀请，多媒体铃音服务器的SIP的URI地址为：sip:MRF@example.com。UE通过SIP的INVITE请求向MRF发起邀请，并在INVITE请求当中包含如下的SDP信息，用于同多媒体铃音服务器协商MSRP会话的媒体参数与信息。

SDP如下所示：

v＝0

o＝UE 2890844557 2890844559 IN IP4 UE.example.com

s＝-

c＝IN IP4 UE.example.com

t＝0 0

m＝Video 7777 TCP/MSRP*

a＝accept-types:video/3gpp

a＝path:msrp://UE.example.com:7777/iau39；tcp

从SDP内容可以看出，UE在SDP当中提供了他所接收的媒体类型为video，可以包含任何的从属媒体类型，接收的内容格式是视频的，接收MSRP消息的主机为UE.example.com，端口号为7777，消息ID为iau39，所采用的网络连接类型为TCP。

2.多媒体铃音服务器在端8888上进行监听，并且发送SIP的200ok响应，并在200ok响应当中携带相应的SDP信息。其所携带的SDP如下所示：

v＝0

o＝MRF 2890844612 2890844616IN IP4MRF.example.com

s＝-

c＝IN IP4 MRF.example.com

t＝0 0

m＝video 8888 TCP/MSRP*

a＝accept-types:video/3gpp

a＝path:msrp://MRF.example.com:8888/9di4ea；tcp

从SDP内容可以看出，多媒体铃音服务器在SDP当中提供了他所接收的媒体类型为video，可以包含任何的从属媒体类型，接收的内容格式是视频的，接收MSRP消息的主机为MRF.example.com，端口号为8888，消息ID为9di4ea，所采用的网络连接类型为传输控制协议(Transmission ControlProtocol，TCP)。

3.UE向多媒体铃音服务器发送SIP的ACK应答，以确认二者所协商的MSRP会话的媒体参数的一致性，并决定根据协商的结果开展MSRP会话，完成内容的传输。

4.发起MSRP会话的UE负责打开一个TCP连接，并且通过这一连接首先向多媒体铃音服务器发送一个MSRP的SEND消息。其消息格式如下所示：

            MSRP d93 kswow SEND

            To-Path：msrp://MRF.example.com:8888/9di4ea；tcp

            From-Path：msrp://UE.example.com:7777/iau39；tcp

            Message-ID：12339sdqwer

            Content-Type：video/3gpp

“ljLJLJLJGLUIOWD080802jljlsdjflsdaglnlgnaslfslakh9287497ljlsdjf)808nljlnlnslf

hkj1408$％s0df80sdglasjgljslg07802ljlu90f8s0aj；ljsljglauf0sa08si0fssa”

            -------d93kswow$

消息体的内容表示，UE发送的是视频文件，采用的是BASE64的编码。通过在SDP当中进行协商，可以通过MSRP传送任何类型的消息，包括文本，图片，文件等等。由于文件的内容过大，那么这个文件是可以分割的。具体分割方法为本领域技术人员所公知，在这里就不做赘述。

5.多媒体铃音服务器在收到UE发送的消息之后，需要对UE发送的消息进行一个确认，因此他通过一个MSRP的应答响应来实现。

MSRP d93kswow 200 OK

To-Path：msrp://UE.example.com:7777/iau39；tcp

From-Path：msrp://MRF.example.com:8888/9di4ea；tcp

-------d93kswow$

6.与此同时，多媒体铃音服务器如果需要向UE发送消息的话，他会利用现有的tcp连接，通过MSRP会话的SEND消息向UE发送消息，其消息格式如下所示：

MSRP dkei38sd SEND

To-Path：msrp://UEpc.example.com:7777/iau39；tcp

From-Path：msrp://MRF.example.com:8888/9di4ea；tcp

Message-ID：456

Content-Type：text/plain

“Success！”

-------dkei38sd$

多媒体铃音服务器发送的消息内容是：“Success！”。

7.同样的，UE在接受到多媒体铃音服务器所发送的消息之后，会通过200ok的MSRP应答响应对其进行确认。

MSRP dkei38sd 200 OK

To-Path：msrp://UE.example.com:7777/iau39；tcp

From-Path：msrp://MRF.example.com:8888/9di4ea；tcp

-------dkei38sd$

8.在完成了所有的消息传送之后，如果需要结束整个MSRP会话的话，会话的参与的任何一方都可以通过一个SIP的BYE方法来结束整个MSRP会话。上图中，UE向多媒体铃音服务器发送了一个SIP的BYE请求，并最终结束了整个MSRP会话。在这个过程当中，UE上传的内容可以通过MSRP：//MRF.example.com:8888/9di4ea+d93kswow进行唯一的标识和确认。

9.多媒体铃音服务器将本地的事务状态完全实效之后，返回一个200 OK的消息到UE，从而完整的结束整个MSRP的会话事务。

上面的流程是在UE和多媒体铃音服务器之间通过SIP消息建立MSRP的会话关系，然后UE和多媒体铃音服务器通过MSRP消息进行内容的传输。这个传输可以是双方向的，也可以是单方向的，具体取决于在SDP协商过程所达成的一致。另外，由于MSRP是一个和SIP紧密结合的，可以通过SIP消息建立会话的协议，同时，它可以通过MSRP消息传送离散的媒体内容，并且提供断点续传的功能，这些功能和内容都是在MSRP当中实现的此处不做赘述。

本例是通过MSRP上传多媒体铃音业务内容的实施例，整个UE完成了IMS的注册之后，具有了和多媒体铃音服务器之间沟通的通道，在这个过程当中，可以利用SIP建立的通道通过MSRP的方式向多媒体铃音服务器上传UE所希望的多媒体铃音内容，同时，在完成上传的过程之后，多媒体铃音服务器为上传的内容分配一个唯一的ID或者URI。

本实施例的有益效果在于使多媒体铃音服务器接收UE上传多媒体铃音。

实施例三：

本实施例主要说明如何通过SIP信令的方式实现IMS域多媒体铃音内容的管理问题，通过UE将上传后的内容同本地的铃音播放规则进行一个映射，让终端用户能够通过UE对所需要播放的铃音的内容进行管理。具体实现方法包括使用PUBLISH和NOTIFY的方法。

对多媒体铃音内容的管理可包括：接收所述UE通过SIP的PUBLISH消息发送的多媒体铃音配置文件，根据所述多媒体铃音配置文件配置所述用户的多媒体铃音。

所述的配置文件如实施例一所述，用于记录所述UE当前设置的多媒体铃音。上述内容具体包括(请参照图3)：

1.UE在完成注册过程之后，通过PUBLISH的SIP方法将UE对于内容的配置文件发送上去。比如说，某个多媒体铃音文件针对某一个用户，完成这个配置之后，某个特定用户拨打UE的时候，将会播放UE所设定的多媒体铃音。这个PUBLISH消息被SIP/IP Core转发到多媒体铃音服务器。

2.多媒体铃音服务器在接收到这个消息之后，根据消息当中所携带的内容标识，以及规则，对内容的播放进行设定。在完成设定之后，多媒体铃音服务器向UE返回一个200 OK的应答响应。

3.UE在设置信息需要修改的时候，向服务器发送PUBLISH的消息，重复1、2的步骤。

多媒体铃音服务器还可以通过订阅UE的设定规则来对内容进行管理。UE可以在本地地址本上设定用户的多媒体铃音业务的规则。多媒体铃音服务器可以通过SIP消息对这些设定或者这些修改进行订阅，然后UE在这些信息进行修改的情况下，通过NOTIFY消息发送到多媒体铃音服务器，然后多媒体铃音服务器对这些规则进行保存，以便在后续的业务过程当中激活UE设定的铃音业务，即：向所述UE发送SUBSCRIBE消息，订阅UE对铃音播放规则的修改，接收所述UE通过NOTIFY消息发送多媒体铃音配置文件，根据多媒体铃音配置文件配置所述用户的多媒体铃音。

上述内容具体流程包括(如图4所示)：

1.多媒体铃音服务器向UE发送SUBSCRIBE消息，订阅UE对铃音播放规则的修改或者设定；

2.UE接收到这个订阅请求之后，向订阅者返回200OK的应答响应，确认订阅的过程；

3.UE在接收到订阅过程之后，需要将本地目前的设置情况通过NOTIFY消息通告给多媒体铃音服务器。

4.多媒体铃音服务器保存这个通告的信息，然后返回200 OK应答响应确认这个NOTIFY消息。

5.UE在本地的设置发生了变化的情况下，向多媒体铃音服务器发送NOTIFY消息，进行修改。

6.多媒体铃音服务器返回一个200 OK的应答。

在本实施例整个的过程当中，UE可以对资源如何使用进行一个配置，通过MSRP或者HTTP上传的铃音资源，多媒体铃音服务器会为之分配一个ID或者一个URI，并且将这个URI的信息通过MSRP或者SIP或者HTTP或者RTSP的消息返回给UE，UE能够维护一个本地的资源内容和URI的一个映射。如果本地没有删除这些资源，那么UE在设置用户的铃音的时候，可以通过预览或者选择文件的方式进行设定；同时，UE保存有先前的映射关系，这样的话，实际上设定的不是真实的文件和规则，而是将保存在服务器上的URI和规则进行了一个绑定和联系。之后，UE通过SIP消息将这样的规则和关系发送到多媒体铃音服务器，多媒体铃音服务器保存这些信息，对内容进行管理。

本实施例的有益效果在于通过PUBLISH和NOTIFY方法实现了对多媒体铃音服务器中的多媒体铃音的配置。

实施例四：

本例是通过现有的网络框架实现多媒体铃音业务内容的下发过程。这其中主要涉及的是一些大内容的离散媒体(非实时的语音和视频)，没有办法通过RTP和RTCP的方式进行，这种情况下，UE可以通过先前的信令和MRF之间建立一个MSRP的会话，MSRP通过MSRP的方法进行内容的传递。先前的离散内容的传递主要是通过在18X消息当中携带HTTP的URI的方式，终端接收到这个URI之后，会去HTTP Server去通过GET命令下载相关的离散媒体内容，但是由于终端能力的限制和HTTP的时间延迟，这种方法具有很低的时效性。

如图5所示，在前述实施例的上传、设置后，本实施例的方法还包括：

步骤S501：与主叫UE建立MSRP会话。

步骤S502：通过MSRP消息向主叫UE发送多媒体铃音文件。

上述步骤S501可进一步包括：接收主叫UE发送的携带主叫正常通话媒体的SDP offer的INVITE请求消息，并将该请求消息转发到被叫UE；接收被叫UE返回的空闲180响应，将该空闲响应转化为携带多媒体铃音服务器的SDP的183响应下发给主叫UE；接收主叫UE发送的PRACK应答反馈并返回200ok确认。

上述步骤具体实如图6所示：

1.主叫UE呼叫被叫UE，INVITE消息中携带主叫正常通话媒体的SDPoffer，SDP在这里是会话描述协议，也就是，凡是两个节点之间，存在媒体的发送关系，那么他们之间的这种关系，我们就称之为会话。这个会话到底是什么样一个状态，是什么类型，那么需要有一个协议进行描述，这个协议就是SDP，描述了媒体类型，编解码，带宽，端口号等。那么，这个会话会有一个发起者，和一个接收者。发送者发送一个SDP，接收者确认自己是否支持这个SDP，如果支持，那么会返回自己支持的SDP。在这里，发送者所发送的SDP叫做Offer，接收者发送的SDP叫做answer；当有用户签约了多媒体铃音业务，INVITE请求到达多媒体铃音服务器。多媒体铃音服务器将来自主叫的INVITE请求发送到被叫UE；

2.被叫处于空闲状态，返回180响应；

3.180响应到达多媒体铃音服务器，多媒体铃音服务器将该180响应转化为183响应，并在183响应当中携带多媒体铃音服务器的SDP，并下发给主叫UE。

4.多媒体铃音服务器收到180消息后，启动多媒体铃音业务逻辑，根据用户设置的多媒体铃音播放规则确定播放的铃音文件；同时，主叫UE在收到183响应之后，根据多媒体铃音服务器所携带的SDP进行协商，确定自己所能够接受的SDP，并通过PRACK的应答反馈给多媒体铃音服务器。

5.多媒体铃音服务器在接收到PRACK应答之后，向主叫UE返回一个200OK的确认。至此，在多媒体铃音服务器和主叫UE之间的MSRP会话关系已经建立。同理，通过4、5两步，可以在多媒体铃音服务器和被叫UE之间建立MSRP会话关系。

6.多媒体铃音服务器通过MSRP SEND的请求，向主叫UE发送铃音文件；

7.主叫UE在接收到多媒体铃音服务器通过MSRP所发送的铃音文件之后，向多媒体铃音服务器返回一个200OK的确认响应。同理，通过6、7两步，多媒体铃音服务器可以向被叫UE发送铃音文件。此时，主叫UE可以通过接收到的铃音文件播放铃音，彩振内容。

8.被叫UE摘机，向主叫发送200OK的应答响应，此时，被叫停止多媒体铃音的播放。

9.主叫接收到200OK应答响应的时候，停止多媒体铃音的播放，同时返回ACK确认消息。

10.主叫和被叫之间建立通话的媒体流。

本实施例的有益效果在于，利用18X消息的可靠临时应答响应机制替代MSRP常规流程当中的INVITE的会话建立机制，建立端到端的MSRP会话，实现了通过MSRP的SEND消息将离散媒体内容发送至UE。

实施例五：

如图7所示，本实施例提供一种多媒体铃音服务器700，所述多媒体铃音服务器700包括：

MSRP会话建立单元701，用于与UE协商建立MSRP会话；

铃音文件处理单元702，用于接收UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。

铃音文件处理单元702可将接收到的多媒体铃音文件存储，并建立所述多媒体铃音文件与所述UE的对应关系，该对应关系可以存储在多媒体铃音配置文件中，所述多媒体铃音配置文件为多媒体铃音文件与所述UE的对应关系表，其中包括所述UE及所述多媒体铃音的唯一标识。

本实施例的有益效果在于使多媒体铃音服务器可以接收通过UE上传多媒体铃音。

实施例六：

如图8所示，实施例五所揭示的多媒体铃音服务器700，在本实施例中MSRP会话建立单元701进一步包括：邀请接收子单元7011，用于接收UE通过SIP的INVITE消息发送的包含SDP信息的MSRP会话邀请；响应发送子单元7012，用于发送携带相应SDP信息的SIP的200ok响应。

本实施例中的邀请接收子单元7011、响应发送子单元7012实现了实施例二所述具体流程的步骤2，邀请接收子单元7011还可接收UE发送的ACK应答。

本实施例的有益效果在于使用户可以通过UE上传多媒体铃音。

实施例七：

如图9所示，实施例五所揭示的多媒体铃音服务器700，在本实施例中进一步包括：配置文件处理单元703，用于接收所述UE通过SIP的PUBLISH消息发送的多媒体铃音配置文件，根据所述多媒体铃音配置文件配置所述用户的多媒体铃音；订阅处理单元704，有用于向所述UE发送SUBSCRIBE消息，订阅UE对铃音播放规则的修改，接收所述UE通过NOTIFY消息发送多媒体铃音配置文件，根据多媒体铃音配置文件配置所述用户的多媒体铃音。

配置文件处理单元703及订阅处理单元704分别实现实施例三中的PUBLISH消息配置流程的第2步及SUBSCRIBE消息配置流程的第1、4、6步。

本实施例的有益效果在于通过PUBLISH和NOTIFY方法实现了对多媒体铃音服务器中的多媒体铃音的配置。

实施例八：

如图10所示，实施例七所揭示的多媒体铃音服务器700，在本实施例中进一步包括：呼叫MSRP会话建立单元705，用于与主叫UE建立MSRP会话；多媒体铃音文件发送单元706，用于通过MSRP消息向主叫UE发送多媒体铃音文件。其中所述呼叫MSRP会话建立单元705进一步包括：请求转发子单元7051，用于接收主叫UE发送的携带主叫正常通话媒体的SDP offer的INVITE请求消息，并将该请求消息转发到被叫UE；响应转发子单元7052，用于接收被叫UE返回的空闲180响应，将该空闲响应转化为携带多媒体铃音服务器的SDP的183响应下发给主叫UE；确认反馈子单元7053，用于接收主叫UE发送的PRACK应答反馈并返回200ok确认。

请求转发子单元7051实现实施例四具体实现步骤1中的将主叫UE发送的携带主叫正常通话媒体的SDP offer的INVITE请求消息转发到被叫UE；响应转发子单元7052实现了其中的步骤3、4；确认反馈子单元7053实现了其中的步骤5。

本实施例的有益效果在于，利用18X消息的可靠临时应答响应机制替代MSRP常规流程当中的INVITE的会话建立机制，建立端到端的MSRP会话，实现了通过MSRP的SEND消息将离散媒体内容发送至UE。

实施例九：

如图11所示，本实施例提供一种多媒体铃音上传方法，所述方法包括：

步骤S1101：与多媒体铃音服务器协商建立MSRP会话；

步骤S1102：向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

本实施例的有益效果在于使UE可以向多媒体铃音服务器上传多媒体铃音。

实施例十：

实施例九中其中所述步骤S1101进一步包括：通过SIP的INVITE消息发送包含会话描述协议SDP信息的MSRP会话邀请，接收所述多媒体铃音服务器发送的携带相应SDP信息的SIP的200ok响应。具体实施内容如实施例二中具体信令步骤1，3此处不再赘述。

向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息后还包括：通过SIP的PUBLISH消息发送的多媒体铃音配置文件；或接收所述多媒体铃音服务器发送的SUBSCRIBE消息，在对铃音播放规则进行修改时，通过NOTIFY消息发送多媒体铃音配置文件。具体实施内容如实施例三中的PUBLISH消息配置流程的第1、3步及SUBSCRIBE消息配置流程的第2、3、5步此处不再赘述。

发送多媒体铃音配置文件后还包括：发起呼叫时与所述多媒体铃音服务器建立MSRP会话；接收所述多媒体铃音服务器通过MSRP消息发送多媒体铃音文件。其中与所述多媒体铃音服务器建立MSRP会话进一步包括：向所述多媒体铃音服务器发送携带正常通话媒体的SDP offer的INVITE请求消息；接收携带多媒体铃音服务器的SDP的183响应向所述多媒体铃音服务器发送PRACK应答反馈。具体实施内容如实施例四具体实现步骤1，4此处不再赘述。

本实施例的有益效果在于，实现了UE上传、设置、接收多媒体铃音。

实施例十一：

如图12所示，本实施例提供一种UE 800，所述UE 800包括：MSRP会话建立单元801，用于与多媒体铃音服务器协商建立MSRP会话；多媒体铃音文件发送单元802，向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

本实施例的有益效果在于使UE可以向多媒体铃音服务器上传多媒体铃音。

实施例十二：

如图13所示，实施例九中的UE在本实施例中可扩展为：

所述MSRP会话建立单元801进一步包括：邀请发送子单元8011，用于通过SIP的INVITE消息请求发送包含SDP信息的MSRP会话邀请；响应接收子单元8012，用于接收所述多媒体铃音服务器发送的携带相应SDP信息的SIP的200ok响应。邀请发送子单元8011实现了实施例二中具体信令步骤1；响应接收子单元8012实现了步骤3，UE接收200ok响应后发送ACK应答。

所述UE还包括：配置文件发送单元803，用于通过SIP的PUBLISH消息发送的多媒体铃音配置文件。订阅配置文件发送单元804，用于接收所述多媒体铃音服务器发送的SUBSCRIBE消息，在对铃音播放规则进行修改时，通过NOTIFY消息发送多媒体铃音配置文件。配置文件发送单元803及订阅配置文件发送单元804分别实现实施例三中的PUBLISH消息配置流程的第1、3步及SUBSCRIBE消息配置流程的第2、3、5步。

所述UE还包括：呼叫MSRP会话建立单元805，用于发起呼叫时与所述多媒体铃音服务器建立MSRP会话；多媒体铃音文件接收单元806，用于接收所述多媒体铃音服务器通过MSRP消息发送多媒体铃音文件。呼叫MSRP会话建立单元805进一步包括：请求子单元8051，用于向所述多媒体铃音服务器发送携带正常通话媒体的SDP offer的INVITE请求消息；应答反馈子单元8052，用于接收携带多媒体铃音服务器的SDP的183响应，向所述多媒体铃音服务器发送PRACK应答反馈。请求子单元8051，实现实施例四具体实现步骤1；应答反馈子单元8052实现了步骤4中的应答反馈。

本实施例的有益效果在于，实现了UE上传、设置、接收多媒体铃音。

实施例十三：

如图14所示，本实施例提供一种多媒体铃音上传系统，所述系统包括：多媒体铃音服务器700，用于接收UE通过MSRP消息发送的多媒体铃音文件，作为所述UE的可选多媒体铃音；UE 800，向所述多媒体铃音服务器700发送的包含多媒体铃音文件的MSRP消息。其中SIP/IP核心网(Core)主要包括一些SIP代理和SIP注册服务器(在IMS中既为CSCF)。

本实施例中的多媒体铃音服务器700及UE 800如前述实施例五、六、七八、十一、十二所述，本实施例不再具体描述。

本实施例的有益效果在于，实现了UE上传、设置、接收多媒体铃音。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (25)

1.一种多媒体铃音上传方法，其特征在于，所述的方法包括：

与用户设备UE协商建立消息会话中继协议MSRP会话；

接收所述UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。

2.如权利要求1所述的方法，其特征在于，所述与UE协商建立MSRP会话进一步包括：

接收UE通过会话初始协议SIP发送的包含会话描述协议SDP信息的MSRP会话邀请，发送携带相应SDP信息的响应消息。

3.如权利要求1所述的方法，其特征在于，将所述的多媒体铃音文件与所述UE建立对应关系后还包括：

接收所述UE通过SIP发送的多媒体铃音配置文件，根据所述多媒体铃音配置文件配置所述用户的多媒体铃音。

4.如权利要求1所述的方法，其特征在于，将所述的多媒体铃音文件与所述UE建立对应关系后还包括：

向所述UE发送SIP订阅消息，订阅UE对铃音播放规则的修改；

接收所述UE通过SIP发送的多媒体铃音配置文件，根据多媒体铃音配置文件配置所述用户的多媒体铃音。

5.如权利要求3或4所述的方法，其特征在于，所述配置所述用户的多媒体铃音后还包括：

与主叫UE建立MSRP会话；

通过MSRP消息向主叫UE发送多媒体铃音文件。

6.如权利要求5所述的方法，其特征在于，与所述主叫UE建立MSRP会话进一步包括：

接收主叫UE发送的携带SDP offer的请求消息，并将所述请求消息转发到被叫UE；

接收被叫UE返回的空闲响应消息，将所述空闲响应消息转化为携带多媒体铃音服务器SDP的响应消息下发给主叫UE；

接收主叫UE发送的应答反馈消息，并返回确认消息。

7.一种多媒体铃音服务器，其特征在于，所述多媒体铃音服务器包括：

MSRP会话建立单元，用于与UE协商建立MSRP会话；

铃音文件处理单元，用于接收所述UE发送的包含多媒体铃音文件的MSRP消息，将所述的多媒体铃音文件与所述UE建立对应关系，作为所述UE的可选多媒体铃音。

8.如权利要求7所述的多媒体铃音服务器，其特征在于，所述MSRP会话建立单元进一步包括：

邀请接收子单元，用于接收UE通过SIP发送的包含SDP信息的MSRP会话邀请；

响应发送子单元，用于发送携带相应SDP信息的SIP的响应消息。

9.如权利要求7所述的多媒体铃音服务器，其特征在于，所述多媒体铃音服务器还包括：

配置文件处理单元，用于接收所述UE通过SIP发送的多媒体铃音配置文件，根据所述多媒体铃音配置文件配置所述用户的多媒体铃音。

10.如权利要求7所述的多媒体铃音服务器，其特征在于，所述多媒体铃音服务器还包括：

订阅处理单元，用于向所述UE发送SIP订阅消息，订阅UE对铃音播放规则的修改；接收所述UE通过SIP发送的多媒体铃音配置文件，根据多媒体铃音配置文件配置所述用户的多媒体铃音。

11.如权利要求8或9所述的多媒体铃音服务器，其特征在于，所述多媒体铃音服务器还包括：

呼叫MSRP会话建立单元，用于与主叫UE建立MSRP会话；

多媒体铃音文件发送单元，用于通过MSRP消息向主叫UE发送多媒体铃音文件。

12.如权利要求11所述的多媒体铃音服务器，其特征在于，所述呼叫MSRP会话建立单元进一步包括：

请求转发子单元，用于接收主叫UE发送的携带SDP offer的请求消息，并将所述请求消息转发到被叫UE；

响应转发子单元，用于接收被叫UE返回的空闲响应消息，将所述空闲响应消息转化为携带多媒体铃音服务器SDP的响应消息下发给主叫UE；

确认反馈子单元，用于接收主叫UE发送的应答反馈消息，并返回确认消息。

13.一种多媒体铃音上传方法，其特征在于，所述方法包括：

与多媒体铃音服务器协商建立MSRP会话；

向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

14.如权利要求13所述的方法，其特征在于，所述与多媒体铃音服务器协商建立MSRP会话进一步包括：

通过SIP发送包含会话描述协议SDP信息的MSRP会话邀请，接收所述多媒体铃音服务器发送的携带相应SDP信息的SIP的响应消息。

15.如权利要求13所述的方法，其特征在于，向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息后还包括：

通过SIP发送多媒体铃音配置文件。

16.如权利要求13所述的方法，其特征在于，向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息后还包括：

接收所述多媒体铃音服务器发送的SIP订阅消息，在对铃音播放规则进行修改时，通过SIP消息发送多媒体铃音配置文件。

17.如权利要求15或16所述的方法，其特征在于，所述发送多媒体铃音配置文件后还包括：

发起呼叫时与所述多媒体铃音服务器建立MSRP会话；

接收所述多媒体铃音服务器通过MSRP消息发送的多媒体铃音文件。

18.如权利要求17所述的方法，其特征在于，与所述多媒体铃音服务器建立MSRP会话进一步包括：

向所述多媒体铃音服务器发送携带SDP offer的请求消息；

接收携带多媒体铃音服务器SDP的响应消息，向所述多媒体铃音服务器发送应答反馈消息。

19.一种UE，其特征在于，所述UE包括：

MSRP会话建立单元，用于与多媒体铃音服务器协商建立MSRP会话；

多媒体铃音文件发送单元，向所述多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息。

20.如权利要求19所述的UE，其特征在于，所述MSRP会话建立单元进一步包括：

邀请发送子单元，用于通过SIP发送包含SDP信息的MSRP会话邀请；

响应接收子单元，用于接收所述多媒体铃音服务器发送的携带相应SDP信息的SIP的响应消息；

21.如权利要求19所述的UE，其特征在于，所述UE还包括：

配置文件发送单元，用于通过SIP发送多媒体铃音配置文件。

22.如权利要求19所述的UE，其特征在于，所述UE还包括：

订阅配置文件发送单元，用于接收所述多媒体铃音服务器发送的SIP订阅消息，在对铃音播放规则进行修改时，通过SIP消息发送多媒体铃音配置文件。

23.如权利要求21或22所述的UE，其特征在于，所述UE还包括：

呼叫MSRP会话建立单元，用于发起呼叫时与所述多媒体铃音服务器建立MSRP会话；

多媒体铃音文件接收单元，用于接收所述多媒体铃音服务器通过MSRP消息发送的多媒体铃音文件。

24.如权利要求23所述的UE，其特征在于，所述呼叫MSRP会话建立单元进一步包括：

请求子单元，用于向所述多媒体铃音服务器发送携带SDP offer的请求消息；

应答反馈子单元，用于接收携带多媒体铃音服务器的SDP的响应消息，向所述多媒体铃音服务器发送应答反馈消息。

25.一种多媒体铃音上传系统，其特征在于，所述系统包括：

UE，向多媒体铃音服务器发送的包含多媒体铃音文件的MSRP消息；

多媒体铃音服务器，用于接收所述UE通过MSRP消息发送的多媒体铃音文件，作为所述UE的可选多媒体铃音。

Images