专利名称：Ip多媒体子系统异常提示音媒体播放方法及系统的制作方法
技术领域：
本发明涉及通信领域，具体涉及一种IP(Internet Protocol,网络互联协 议)多媒体子系统解决多次放异常音的实现方法。
背景技术：
IP多媒体子系统(IP Multimedia Core Network Subsystem,简称IMS) 是由第三代合作伙伴计划(3rd Generation Partnership Project,简称3GPP) 组织提出的一种基于IP的网络架构，IMS的呼叫、业务与控制业务实现分 离，并外置数据库(HSS)，采用会话初始协议，构建了一个开放而灵活的 业务环境，支持多媒体应用，并为用户提供丰富的多媒体业务。
IMS是基于IP的电信网络架构，与接入技术无关，除了可以为GPRS (General Packet Radio Service,通用分组无线业务)、WLAN( Wireless Local Area Network,无线局域网)等分组接入网络提供业务外，还可以为GSM (Global System for Mobile communications,全球移动通讯系统)、UMTS (Universal Mobile Telecommunications System,统一移动通讯系统)等移 动蜂窝网络提供业务。
异常放音一般用于呼叫发生异常的情况下，给主叫播放一定的提示音， 提示呼叫异常的原因。
图1是IMS系统参考框架简单示意图。图1中设备包括用户设备(User Equipment,简称UE)、代理呼叫会话控制功能(Proxy Call Session Control Function,简称P-CSCF)、服务呼叫会话控制功能(Serving Call Session Control Function,简称S-CSCF)、应用服务器(application server,简称 AS)等。
其中，P-CSCF用于作为代理转发UE与S-CSCF之间的请求与响应。 S-CSCF是UE的归属服务实体，用于为UE提供业务逻辑和权限控制等功 能。HSS用于保存用户的登记信息以及定制的业务等信息。
图1中存在3个AS服务器，只是示例作用，实际组网则没有个数的限制。
图2是IMS域内两终端从呼叫到应答的流程图，简单起见，假定两终
端之间只有2个AS，分别实现主叫业务和被叫业务，并且都具有放音功
能。基本呼叫步骤如下
步骤201: UE1发起初始会话请求INVITE到S-CSCF;
步骤202: S-CSCF根据用户的签约信息将初始请求转发到SIP-AS1;
步骤203: SIP-AS1处理完用户的业务，转发用户的请求到I/S-CSCF;
步骤204: 1/S-CSCF根据配置的路由信息以及签约关系，将初始会话 请求INVITE转发到被叫用户业务实现服务器SIP-AS2;
本步骤中，从UE1的SIP-AS1到SIP-AS2的寻路由以及组网不限制， 可能多变，简化为I/S-CSCF;
步骤205: SIP-AS2实现用户UE2的业务，然后转发呼叫请求给 S-CSCF2;
步骤206: S-CSCF2转发初始呼叫请求INVITE给UE2;
步骤207-步骤212:被叫UE2回180振铃消息，发送到主叫终端UE1;
步骤213-歩骤218:被叫UE2应答，并发送到UE1;
步骤219-步骤224:主叫UE1回ACK给被叫UE2;
UE1和UE2进入通话态。
图2中的任何一步都会发生异常，从而导致业务服务器AS进行放音 提示操作。假定图1的步骤206发出之后，等待步骤207超时，由应用服 务器根据异常进行放音，步骤如下
步骤301: UE1发起初始会话请求INVITE到S-CSCF;
步骤302: S-CSCF根据用户的签约信息将初始请求转发到SIP-AS1;
步骤303: SIP-AS1处理完用户的业务，转发用户的请求到I/S-CSCF;
步骤304: 1/S-CSCF根据配置的路由信息以及签约关系，将初始会话 请求INVITE转发到被叫用户业务实现服务器SIP-AS2;
本步骤中，从UE1的SIP-AS1到SIP-AS2的寻路由以及组网不限制， 可能多变，简化为I/S-CSCF;
步骤305: SIP-AS2实现用户UE2的业务，然后转发呼叫请求给 S-CSCF2;
步骤306: S-CSCF2转发初始呼叫请求INVITE给UE2; 此后SIP-AS2设置定时器等待UE2回的响应，但定时器超时也没有等 到被叫UE2的响应；步骤307-310: SIP-AS2取消到UE2的试呼；
步骤311: SIP-AS2判断发生异常进行放音，并将音资源通过183携
带；
步骤312-步骤314:放音媒体发送到UE1;
步骤315-步骤322: UE1和SIP-AS2之间完成媒体和信令的交互，然 后UE1开始听SIP-AS2的语音；
步骤323-步骤326: SIP-AS2放音完毕，则发送480通知释放呼叫； 步骤327: SIP-AS1判断后向发生异常，则准备媒体开始放音； 步骤328-步骤331: SIP-AS1与UE1完成放音媒体的协商，并开始放音.
步骤332-步骤335: SIP-AS1放音完毕，则发送480释放呼叫。 图3中，仅以最简单的SIP呼叫为例介绍，复杂的呼叫场景问题同样 存在。
图3中，承载媒体的信令可以根据具体场景的不同变更。 从图3的举例可以看出，对于多AS并存的IMS组网中，若多个AS
均具有放音功能，对主叫终端而言，将会陆续听到多个放音网元的放音，
影响用户的体验。
发明内容
本发明的主要目的是克服现有技术的不足，提供一种IP多媒体子系 统中，主叫终端发起的会话请求在呼叫建立过程中发生异常时，解决多次 放音问题的方法和系统，保证用户在呼叫发生异常的场景下，只会听到一 次失败提示音，从而改善主叫用户的体验。
本发明的技术问题是通过以下技术方案予以解决的 一种IP多媒体子 系统异常提示音媒体播放方法，具体包括以下步骤在IP多媒体子系统的 组网中设置若干业务服务器以及与业务服务器对应的媒体服务器，所述业 务服务器包括具备放音功能的业务服务器和不具备放音功能的业务服务 器；主叫终端发起的会话请求在呼叫建立过程中发生异常；在从主叫终端 到被叫终端建立呼叫的路径上，最后一个具备放音功能的业务服务器就发 生的异常向其对应的媒体服务器请求播放唯一的提示音媒体。
其中，非最后一个具备放音功能的业务服务器在发生内部异常的情况 下，向与其对应的媒体服务器申请播放内部异常提示音媒体。更具体的方案为所述非最后一个具备放音功能的业务服务器在发生
的异常不属于内部异常，同时主叫终端发出的初始会话请求(INVITE)没 有正常响应的情况下，亦即没有SIP消息的通知性应答(lxx)或者成功应 答(2xx)响应的情况下，向与其对应的媒体服务器申请播放异常提示音媒 体。
所述主叫终端发出的初始会话请求(INVITE)没有通知性应答(lxx) 或者成功应答(2xx)响应的情况不包括临时响应100trying。
为了保证不具备放音功能的业务服务器因为超时导致多次放音的问题 或者避免放音过程被中断，相对于具备放音功能的业务服务器，所述不具 备放音功能的业务服务器设置较长时间的定时器。
同时，为了保证最后一个具备放音功能的业务服务器的放音的完整性， 非最后一个具备放音功能的业务服务器的定时器长于最后一个具备放音功 能的业务服务器的定时器。
本发明还涉及一种IP多媒体子系统异常提示音媒体播放系统，包括主 叫终端、被叫终端、IP多媒体子系统组网中设置的若干业务服务器以及若 干媒体服务器，所述业务服务器建立主叫终端和被叫终端之间的呼叫业务， 并控制对应的媒体服务器提供多媒体业务，所述业务服务器包括具备放音 功能的业务服务器和不具备放音功能的业务服务器。主叫终端发起的会话 请求在呼叫建立过程中发生异常的情况下，在从主叫终端到被叫终端建立 呼叫的路径上，最后一个具备放音功能的业务服务器用于针对发生的异常 向对应的媒体服务器请求播放提示音媒体。
相应的，非最后一个具备放音功能的业务服务器在发生内部异常的情 况下，向与其对应的媒体服务器申请播放内部异常提示音媒体。
同时，所述非最后一个具备放音功能的业务服务器在发生的异常不属 于内部异常，同时主叫终端发出的初始会话请求(INVITE)没有正常响应 的情况下，亦即没有SIP消息的通知性应答(lxx)或者成功应答(2xx) 响应的情况下，向与其对应的媒体服务器申请播放异常提示音媒体。
所述主叫终端发出的初始会话请求(INVITE)没有通知性应答(lxx) 或者成功应答(2xx)响应的情况不包括临时响应100trying。
本发明与现有技术相比的有益效果是1)本发明的IP多媒体子系统 异常提示音媒体播放方法，在呼叫建立过程中发生异常时，由与主叫终端 建立SIP最后一个具备放音功能的业务服务器就发生的异常向其对应的媒体服务器请求播放唯一的提示音媒体，从而保证主叫终端只会听到一次异
常提示音媒体，改善用户的体验；2)本发明的IP多媒体子系统异常提示 音媒体播放系统，所述与业务服务器对应的媒体服务器提供丰富的多媒体 流的唯一提示音。
图1是现有IP多媒体子系统参考框架简单示意图； 图2是现有IP多媒体子系统域的基本呼叫流程图； 图3是现有IP多媒体子系统的多个业务服务器(AS)发生异常均需 要放音的流程图4是本发明实施例中，在从主叫终端到被叫终端建立呼叫的路径上，
最后一个具备放音功能的业务服务器的逻辑处理图5是本发明实施例中，在从主叫终端到被叫终端建立呼叫的路径上， 非最后一个具备放音功能的业务服务器的逻辑处理图。
具体实施例方式
下面通过具体的实施方式并结合附图对本发明做进一步详细说明。
本例涉及的IP多媒体子系统解决多次放异常音的实现系统，主要包括 主叫终端(UE1)、被叫终端(UE2)、 IP多媒体子系统组网中设置的若干业 务服务器(AS)以及与业务服务器对应的媒体服务器(MS)。所述主叫终端和 被叫终端在IP多媒体子系统域中注册。
所述业务服务器建立主叫终端和被叫终端之间的呼叫业务，并控制对 应的媒体服务器提供多媒体业务，所述业务服务器包括具备放音功能的业 务服务器和不具备放音功能的业务服务器。
在所述主叫终端发起的会话请求在呼叫建立过程中发生异常的情况 下，在从主叫终端到被叫终端建立呼叫的路径上，最后一个具备放音功能 的业务服务器就发生的异常向其对应的媒体服务器请求播放唯一的提示音 媒体。
相应的，非最后一个具备放音功能的业务服务器在发生内部异常的情 况下，向与其对应的媒体服务器申请播放内部异常提示音媒体。
同时，所述非最后一个具备放音功能的业务服务器在发生的异常不属 于内部异常，同时主叫终端发出的初始会话请求(INVITE)没有响应的情况下，向与其对应的媒体服务器申请播放异常提示音媒体。
所述主叫终端发出的初始会话请求(INVITE)没有正常响应，亦即没 有SIP消息的通知性应答(lxx)或者成功应答(2xx)相应的情况不包括 临时响应100trying。
本例中还涉及一种IP多媒体子系统异常提示音媒体播放方法，具体包 括以下步骤
在IP多媒体子系统的组网中设置若干业务服务器以及与业务服务器
对应的媒体服务器，所述业务服务器包括具备放音功能的业务服务器和不
具备放音功能的业务服务器；
主叫终端发起的会话请求在呼叫建立过程中发生异常； 在从主叫终端到被叫终端建立呼叫的路径上，最后一个具备放音功能
的业务服务器就发生的异常向其对应的媒体服务器请求播放唯一的提示音媒体。
为了保证不具备放音功能的业务服务器因为超时导致多次放音的问题 或者避免放音过程被中断，相对于具备放音功能的业务服务器，所述不具 备放音功能的业务服务器设置较长时间的定时器。
同时，为了保证与主叫终端建立SIP最后一个具备放音功能的业务服 务器的放音的完整性，非最后一个具备放音功能的业务服务器的定时器长 于最后一个具备放音功能的业务服务器的定时器。
请参考图4，其为本实施例中在从主叫终端到被叫终端建立呼叫的路 径上，最后一个具备放音功能的业务服务器的逻辑处理图。
其异常提示音媒体的逻辑说明如下
步骤401:判断AS是否检测到发生异常，如果是，则进入步骤402， 否则进入步骤403;
步骤402:判断配置放音，如果是，则进入步骤404，否则进入步骤
405;
步骤403:正常处理流程；
步骤404:申请放音媒体并进入放音流程；
步骤405:直接进入释放逻辑；
最后一个具备放音功能的AS失败提示音处理逻辑完毕。
请参考图5,其为本实施例中，在从主叫终端到被叫终端建立呼叫的
路径上，非最后一个具备放音功能的业务服务器的逻辑处理图。 所述非最后一个具备放音功能的业务服务器对主叫终端的会话请求在呼叫建立过程中发生的异常不播放提示音媒体，仅对内部异常或者不属于
内部异常，但主叫终端发出的初始会话请求(INVITE)没有响应的状况请 求播放对应的提示音媒体。该非最后一个具备放音功能的业务服务器的提 示音媒体的逻辑说明如下
步骤501: AS检测到发生异常，如果否，进入步骤502，如果是，进 入步骤503;
步骤502:继续正常处理流程；
步骤503:判断异常是否由AS内部原因引起，如定时器超时以及内 部逻辑错误，如果是，进入步骤504，否则，进入步骤506;
步骤504:是否配置放音逻辑，如果是，进入步骤505，如果否，进入 步骤508;
步骤505:进行申请媒体以及放音逻辑；
步骤506:判断初始的INVITE发出之后是否没有SIP消息的lxx-2xx 响应(IOO trying除外)，如果没有，则进入步骤507，否则，进入步骤508; 步骤507:进入申请媒体以及放音逻辑；
步骤508:进入释放逻辑；
最后处理完毕，以上就是非最后一个具备放音功能的AS的处理逻辑。
根据本发明的基本原理，上述实施例还有多种变换方式。
比如，提示音媒体的类型不作限制，可采用early-session,也可采用 session播放提示音媒体，携带p-early-media,或者两者都有的场景。
又如，提示音媒体播放承载的信令不作限制，例如播放承载的信令可 以采用update,也可以采用183或者200 OK等等。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说 明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术 领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若 干简单推演或替换，都应当视为属于本发明的保护范围。
10
权利要求
1.一种IP多媒体子系统异常提示音媒体播放方法，具体包括以下步骤在IP多媒体子系统的组网中设置若干业务服务器以及与业务服务器对应的媒体服务器，所述业务服务器包括具备放音功能的业务服务器和不具备放音功能的业务服务器；主叫终端发起的会话请求在呼叫建立过程中发生异常；在从主叫终端到被叫终端建立呼叫的路径上，最后一个具备放音功能的业务服务器就发生的异常向其对应的媒体服务器请求播放提示音媒体。
2. 根据权利要求1所述的IP多媒体子系统异常提示音媒体播放方法，其特征在于在从主叫终端到被叫终端建立呼叫的路径上，非最后 一个具备放音功能的业务服务器在发生内部异常的情况下，向与其 对应的媒体服务器申请播放内部异常提示音媒体。
3. 根据权利要求2所述的IP多媒体子系统异常提示音媒体播放方法，其特征在于所述非最后一个具备放音功能的业务服务器在发生的 异常不属于内部异常，同时主叫终端发出的初始会话请求 (INVITE)没有通知性应答(lxx)或者成功应答(2xx)响应的 情况下，向与其对应的媒体服务器申请播放异常提示音媒体。
4. 根据权利要求3所述的IP多媒体子系统异常提示音媒体播放方法，其特征在于所述主叫终端发出的初始会话请求(INVITE)没有 通知性应答(lxx)或者成功应答(2xx)响应的情况不包括临时响 应100 trying 。
5. 根据权利要求1-4任意一项所述的IP多媒体子系统异常提示音媒体播放方法，其特征在于相对于具备放音功能的业务服务器，所述不具备放音功能的业务服务器设置较长时间的定时器。
6. 根据权利要求4所述的IP多媒体子系统异常提示音媒体播放方法，其特征在于非最后一个具备放音功能的业务服务器的定时器长于最后 一个的具备放音功能的业务服务器的定时器。
7. —种IP多媒体子系统异常提示音媒体播放系统，包括主叫终端、被叫终端、IP多媒体子系统组网中设置的若干业务服务器以及若干媒 体服务器，所述业务服务器建立主叫终端和被叫终端之间的呼叫业 务，并控制对应的媒体服务器提供多媒体业务，所述业务服务器包 括具备放音功能的业务服务器和不具备放音功能的业务服务器，其特征在于主叫终端发起的会话请求在呼叫建立过程中发生异常的 情况下，在从主叫终端到被叫终端建立呼叫的路径上，最后一个具 备放音功能的业务服务器用于针对发生的异常向对应的媒体服务 器请求播放提示音媒体。
8. 根据权利要求7所述的IP多媒体子系统异常提示音媒体播放系统， 其特征在于非最后一个具备放音功能的业务服务器在发生内部异 常的情况下，用于向与其对应的媒体服务器申请播放内部异常提示 音媒体。
9. 根据权利要求8所述的IP多媒体子系统异常提示音媒体播放系统，其特征在于所述非最后一个具备放音功能的业务服务器在发生的 异常不属于内部异常，同时主叫终端发出的初始会话请求(INVITE)没有通知性应答(lxx)或者成功应答(2xx)响应的 情况下，向与其对应的媒体服务器申请播放异常提示音媒体。
10. 根据权利要求7-9任意一项所述的IP多媒体子系统异常提示音媒 体播放系统，其特征在于所述主叫终端发出的初始会话请求(INVITE) 有通知性应答(lxx)或者成功应答(2xx)响应的 情况不包括临时响应100 trying。
全文摘要
本发明公开了一种IP多媒体子系统异常提示音媒体播放方法，具体包括以下步骤在IP多媒体子系统的组网中设置若干业务服务器以及与业务服务器对应的媒体服务器，所述业务服务器包括具备放音功能的业务服务器和不具备放音功能的业务服务器；主叫终端发起的会话请求在呼叫建立过程中发生异常；在从主叫终端到被叫终端建立呼叫的路径上，最后一个具备放音功能的业务服务器就发生的异常向对应的媒体服务器请求播放提示音媒体。本发明中，在发生异常时仅有一个业务服务器就发生的异常控制播放提示音媒体，从而保证主叫终端只会听到一次异常提示音媒体，改善用户的体验，并且所述媒体服务器可播放多种提示音媒体，提供丰富的多媒体流的提示音。
文档编号H04W76/02GK101631389SQ20091010911
公开日2010年1月20日 申请日期2009年7月28日 优先权日2009年7月28日
发明者飞 唐, 王立波 申请人:中兴通讯股份有限公司