一种多媒体铃音上传方法、 多媒体铃音服务器及 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)808nl jlnlnslf
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 ； tcpMessage-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 上传、 设置、 接收多媒体铃音。
以上所述的具体实施方式， 对本发明的目的、 技术方案和有益效果进行了进一步 详细说明， 所应理解的是， 以上所述仅为本发明的具体实施方式而已， 并不用于限定本发明 的保护范围， 凡在本发明的精神和原则之内， 所做的任何修改、 等同替换、 改进等， 均应包含 在本发明的保护范围之内。