CN103781030B - 基于ip的彩铃业务实现方法和彩铃媒体服务器 - Google Patents

Abstract

本发明提供一种基于IP的彩铃业务实现方法和彩铃媒体服务器，其中方法包括：与信令服务器进行第一媒体协商，获取媒体网关的信息；记录所述媒体网关的信息；根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；在所述第二媒体协商完成后，接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带铃音文件路径信息；记录所述铃音文件路径信息；根据记录的所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。本发明能够提高彩铃媒体服务器性能、减少系统复杂性，提高内存使用率，减少内存拷贝，减少声音抖动。

Description

基于IP的彩铃业务实现方法和彩铃媒体服务器

技术领域

本发明涉及移动通信技术，尤其涉及一种基于IP的彩铃业务实现方法和彩铃媒体服务器。

背景技术

彩铃是在呼叫建立过程中，由被叫用户为主叫用户提供的一段定制的音频/视频来代替普通的回铃音业务。在基于网络之间互连的协议（InternetProtocol，简称IP）的核心网中，彩铃媒体服务器配合信令设备、业务处理设备完成彩铃业务。

现有技术中，基于IP的彩铃媒体服务器主要是通过实时铃音编码实现的。当彩铃媒体服务器向媒体网关（核心网的设备）发送语音包时，首先读取对数脉冲编码调制抽样标准G711格式语音包，将G711格式语音包实时编码成IP彩铃所需的媒体格式，然后发送给媒体网关。由于每次发送语音包时都要进行实时编码操作，而且每次发送语音包时，当有多个呼叫并发，需要进行多次实时编解码操作，因此实时编码占用较高系统资源。

发明内容

本发明提供一种基于IP的彩铃业务实现方法和彩铃媒体服务器，以解决彩铃媒体服务器采用实时编码方式占用较高系统资源的问题。

一方面提供了一种基于IP的彩铃业务实现方法，包括：

与信令服务器进行第一媒体协商，获取媒体网关的信息；

记录所述媒体网关的信息；

根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；

在所述第二媒体协商完成后，接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带铃音文件路径信息；

记录所述铃音文件路径信息；

根据记录的所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；

将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。

另一方面提供了一种彩铃媒体服务器，包括：

内部接口模块，用于与信令服务器进行第一媒体协商，获取媒体网关的信息；

逻辑控制模块，用于记录所述媒体网关的信息；

外部接口模块，用于根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；

所述内部接口模块还用于在所述第二媒体协商完成后，接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带铃音文件路径信息；所述逻辑控制模块还用于记录所述铃音文件路径信息；

铃音管理模块，用于根据记录的所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；

所述外部接口模块还用于将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。

由上述技术方案可知，本发明实施例通过预先将铃音文件编码为基于IP彩铃所需的媒体格式，在彩铃呼叫过程中，读取对应的已编码铃音文件，发送给媒体网关，再由媒体网关发送到主叫终端，能够解决现有技术中实时编码占用较高系统资源的问题。

附图说明

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

图1为本发明基于IP的彩铃业务实现方法一实施例的流程图；

图2为本发明应用的系统结构示意图；

图3为本发明基于IP的彩铃业务实现方法另一实施例的流程图；

图4为本发明彩铃媒体服务器里铃音管理模块中内存结构图；

图5为本发明提供的彩铃媒体服务器实施例的结构示意图。

具体实施方式

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

图1为本发明基于IP的彩铃业务实现方法一实施例的流程图。如图1所示，本实施例的方法包括以下步骤：

步骤101：彩铃媒体服务器与信令服务器进行第一媒体协商，获取媒体网关的信息；

其中，所述彩铃媒体服务器与信令服务器进行第一媒体协商，获取媒体网关的信息，具体为：与所述媒体网关进行编解码列表和优选的编解码的协商；

其中，所述获取媒体网关的信息，包括：媒体网关的编解码列表和优选的编解码；

其中，所述彩铃媒体服务器与信令服务器进行第一媒体协商，获取媒体网关的信息，还包括：

所述彩铃媒体服务器接收到所述媒体网关的信息后，将所述彩铃媒体服务器中的编解码列表与本次呼叫选择的编解码发送给媒体网关，完成第一媒体协商。

步骤102：彩铃媒体服务器记录所述媒体网关的信息；

步骤103：彩铃媒体服务器根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；

其中，所述与所述媒体网关进行第二媒体协商，具体为：所述彩铃媒体服务器获取所述媒体网关的地址和端口信息，与所述媒体网关进行地址与端口信息的协商；

其中，所述与所述媒体网关进行第二媒体协商，还包括：

所述彩铃媒体服务器接收到所述媒体网关的地址和端口信息后，将所述彩铃媒体服务器使用的地址和本次呼叫使用的端口发送给媒体网关，完成第二媒体协商。

步骤104：在所述第二媒体协商完成后，彩铃媒体服务器接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带了铃音文件路径信息；

其中，业务逻辑服务器向彩铃媒体服务器发送初始化请求的同时，业务逻辑服务器向彩铃平台发送获取铃音文件路径信息的请求，并得到响应，该响应中携带了铃音文件路径信息，业务逻辑服务器从该响应中获取铃音文件路径信息。当业务逻辑服务器向彩铃媒体服务器发送铃音播放消息时，所述铃音播放消息中携带了所述铃音文件路径信息。

步骤105：彩铃媒体服务器记录所述铃音文件路径信息；

步骤106：彩铃媒体服务器根据所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；

可选的，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式，是将所述铃音文件由G711格式编码为自适应多速率编码（AdaptiveMulti-Rate，简称为AMR2）格式。

可选的，所述铃音文件可以存储在彩铃平台。

可选的，所述获取所述铃音文件可以包括：

根据所述铃音文件路径信息，从彩铃平台将所述铃音文件按帧读入内存，且读入时去掉每帧的帧头，并在每帧前面预留4字节的空间。

步骤107：彩铃媒体服务器将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。

可选的，所述将所述铃音文件发送给所述媒体网关之前，还包括：在呼叫空闲时，根据所述第二媒体协商的协商结果生成Nb接口用户面协议（Nb Interface User PlaneProtocol，简称NBUP）包头，且将NBUP包头存入所述的每帧前面预留4字节的空间，形成媒体包；

所述将所述铃音文件发送给所述媒体网关，包括：从所述内存中读取所述媒体包，并将所述媒体包发送给媒体网关。

在IP彩铃呼叫开始前，就预先将铃音文件由G711格式编码为AMR2格式，并由彩铃平台同时存储由G711格式编码为AMR2格式的铃音文件以及初始为G711格式的铃音文件。彩铃媒体服务器向媒体网关发送的铃音文件格式为AMR2格式。将铃音文件由G711格式编码为AMR2格式时，G711格式一帧为160字节，编码为AMR2格式后一帧为32字节，AMR2格式的铃音文件为G711格式铃音文件的1/5，因此，彩铃平台只需增加20％的存储空间即可同时存储G711和AMR2两种格式的铃音文件。当IP彩铃呼叫开始，只需要读取一次内存中的铃音文件。而且内存扩张收缩大小为128K字节，每次读取铃音申请内存的大小为128K字节的倍数，当每次呼叫结束，释放系统资源后，内存会自动收缩。在一次呼叫中，彩铃媒体服务器与信令服务器、业务逻辑服务器间进行基于IP网络协议控制信令的交互，进行媒体协商，来完成彩铃的承载控制功能。

本实施例中，通过预先将铃音文件编码为基于IP的彩铃所需的媒体格式，并存储于彩铃平台，在彩铃呼叫过程中，彩铃媒体服务器与信令服务器、业务逻辑服务器间执行彩铃媒体协商过程，并读取对应的已编码铃音文件，由彩铃媒体服务器将铃音文件发送给媒体网关，再由媒体网关发送到主叫终端，能够解决现有技术中实时编码占用较高系统资源；G711编码格式文件相对于编码后文件大的多，每次呼叫读取G711编码格式文件，输入输出（Input/Output，简称IO）读取较大，高并发时，IO性能影响整个系统的并发数量的问题。

图2为本发明应用的系统结构示意图，包括彩铃平台和彩铃媒体服务器。彩铃媒体服务器包括：内部接口模块21、逻辑控制模块22、铃音管理模块23、NBUP模块24、外部接口模块25和编码模块26。

下面对彩铃媒体服务器各个模块的功能作详细描述：

（1）内部接口模块21：该模块主要负责与基于IP的彩铃呼叫系统内部其他服务器通信，这些服务器包括：IP/M3UA/BICC信令服务器、业务逻辑服务器。

（a）与IP/M3UA/BICC信令服务器接口：接收信令服务器发来的编解码列表消息，回复本端编解码选择响应消息；接收信令服务器发来的地址选择消息，回复本端地址响应消息；接收信令服务器发来的NBUP初始化请求消息，回复NBUP初始化开始响应消息和NBUP初始化完成消息。

（b）与业务逻辑服务器接口：接收业务逻辑服务器发来的初始化消息，回复初始化响应消息；接收业务逻辑服务器发来的铃音播放消息，回复铃音播放响应消息；接收业务逻辑服务器发来的释放消息，回复释放完成响应消息。

（2）逻辑控制模块22：该模块负责处理内部接口模块接收的内部消息，根据消息控制铃音管理模块、NBUP模块、外部接口模块完成呼叫建立、NBUP初始化、铃音播放、呼叫释放等功能。

（3）铃音管理模块23：该模块主要负责根据铃音文件路径信息将铃音文件读入内存，并根据逻辑控制模块的要求提供相应的语音包。

（4）NBUP模块24：该模块负责封装、解析NBUP控制命令，记录NBUP控制信息，并根据控制信息生成媒体包NBUP包头。解析媒体网关发来的基于NBUP协议的初始化消息，记录媒体网关的编解码列表和无线接入承载子流组合（Radio Access Bearer Sub-flowCombination，简称RFC）指示值，即（RFC Indicator，简称RFCI）值，记录已协商好的编解码RFCI值，并用该值构造本次呼叫媒体包NBUP包头。

（5）外部接口模块25：接收媒体网关发来的实时传输协议（Real-time TransportProtocol，简称RTP）消息，并交由逻辑控制模块处理；按照逻辑控制模块的控制向媒体网关发送控制消息或媒体流。

（6）编码模块26：将铃音文件预先编码为基于IP的彩铃呼叫所需的媒体格式。

在彩铃呼叫开始前，由彩铃平台的铃音分发模块27采集铃音文件，采集的铃音文件为G711格式，彩铃平台同时存储由铃音分发模块采集的G711格式铃音文件和经过彩铃媒体服务器的编码模块将铃音分发模块采集的G711格式铃音文件编码后的铃音文件，可选的，可编码为AMR2格式。彩铃媒体服务器可以通过铃音管理模块从彩铃平台中读出已编码的铃音文件。

图3为本发明基于IP的彩铃业务实现方法另一实施例的流程图，如图3所示。在IP彩铃呼叫中，需要彩铃媒体服务器与信令服务器、业务逻辑服务器进行基于IP网络协议控制信令的交互，进行媒体协商，当协商成功，彩铃媒体服务器读取媒体包发送给媒体网关，并由所述媒体网关发送给主叫终端。本实施例的方法包括：

步骤301：彩铃媒体服务器接收业务逻辑服务器发送来的初始化请求，回复初始化响应；

其中，彩铃媒体服务器接收到业务逻辑服务器发送来的初始化请求后，判断电路是否被占用，如果电路被占用，则拆除该呼叫，回复初始化响应失败消息；如果电路空闲，就对电路进行初始化，回复初始化成功响应消息。

具体的，可以是内部接口模块接收上述的初始化请求，并回复响应。

步骤302：彩铃媒体服务器接收到信令服务器发送的编解码列表消息，并记录，彩铃媒体服务器向信令服务器回复响应消息；

其中，信令服务器发送的编解码列表消息包括媒体网关的编解码列表和优选的编解码。彩铃媒体服务器向信令服务器回复的响应消息中包括彩铃媒体服务器的编解码列表和本次呼叫选择的编解码。

具体的，可以是内部接口模块接收上述的编解码列表消息，并回复响应。

步骤303：彩铃媒体服务器接收到信令服务器发送的请求地址消息，并记录，彩铃媒体服务器向信令服务器回复地址响应消息；

其中，彩铃媒体服务器接收到信令服务器发送的请求地址消息中携带有媒体网关地址和本次呼叫使用的端口。彩铃媒体服务器向信令服务器回复的地址响应消息中携带有彩铃媒体服务器使用的地址和本次呼叫使用的端口。

具体的，可以是内部接口模块接收上述的请求地址消息，并回复响应。

步骤304：彩铃媒体服务器接收到信令服务器发送的NBUP初始化请求，彩铃媒体服务器准备接收，并向信令服务器回复彩铃媒体服务器准备好接收NBUP初始化消息响应；

其中，彩铃媒体服务器准备接收的为核心网发送的基于NBUP协议的初始化消息。

具体的，可以是内部接口模块接收上述的NBUP初始化请求，并回复响应。

步骤305：彩铃媒体服务器接收到核心网设备发送的NBUP初始化消息，解析NBUP初始化消息，并记录，回复媒体网关NBUP初始化响应消息，回复信令服务器NBUP初始化完成响应；

其中，彩铃媒体服务器接收到核心网设备发送的NBUP初始化消息，解析NBUP初始化消息，并记录，所述记录的内容为媒体网关的编解码列表和RFCI值，以及协商好的编解码RFCI值。

具体的，可以是内部接口模块接收上述的NBUP初始化消息，并回复NBUP初始化完成消息。

步骤306：彩铃媒体服务器接收到业务逻辑服务器发送的铃音播放消息，获取铃音文件路径，根据铃音文件路径找到相应的铃音文件，回复铃音播放响应消息；

其中，所述铃音播放消息中携带了铃音文件路径信息，彩铃媒体服务器根据所述铃音文件路径信息获取铃音文件。

具体的，可以是内部接口模块接收上述的铃音播放消息，并回复铃音播放响应消息。

下面将结合图4彩铃媒体服务器里铃音管理模块中存储的铃音文件的帧结构图，对彩铃媒体服务器根据所述铃音文件路径信息获取铃音文件后，将所述铃音文件读入内存及处理过程做详细描述：

彩铃媒体服务器根据所述的铃音文件路径信息，从彩铃平台读取已编码的铃音文件，将所述铃音文件按帧读入内存，在读入时去掉每帧的帧头，并在每帧前面预留4字节的空间。例如，图4中，读取铃音文件数据时，从地址为00000000h文件中“1E”开始读入帧1，则在帧1前面预留4字节的空间，从预留4字节的空间后依次读入“1E 3C 38 40 4B 88 66 684A C4 CB 2442 44 72 40 00 41 63 50 30 34 A0 00 00 66 80 45 42 0B 20”，共35个字节构成一帧。

在呼叫空闲时，生成NBUP包头，且将NBUP包头存入所述的每帧前面预留4字节的空间，形成媒体包，每次直接从内存读取35个字节的媒体包进行发送，不需要在发送时处理NBUP包头，减少内存拷贝，减少声音抖动。

步骤307：彩铃媒体服务器在每次发送语音包时，将铃音文件发送给媒体网关；

其中，所述将铃音文件发送给媒体网关，包括：从所述内存中读取所述媒体包，并将所述媒体包发送给媒体网关。

具体的，可以是外部接口模块按照逻辑控制模块的控制，将上述的铃音文件发送给媒体网关。

步骤308：彩铃媒体服务器接收到业务逻辑服务器发送的呼叫释放消息，彩铃媒体服务器停止向媒体网关发送铃音文件，释放电路占用资源，改为空闲状态，回复呼叫释放完成消息。

具体的，可以是逻辑控制模块完成上述呼叫释放。

本实施例中，从彩铃媒体服务器与信令服务器、业务逻辑服务器间执行媒体协商的过程，说明了彩铃业务的实现方法，通过彩铃媒体服务器执行彩铃媒体协商过程，与信令服务器、业务逻辑服务器间完成基于IP的网络协议控制信令的交互，并读取对应的已编码铃音文件，由彩铃媒体服务器将铃音文件发送给媒体网关，再由媒体网关发送到主叫终端，能够提高彩铃媒体服务器性能、减少系统复杂性，提高内存使用率，减少内存拷贝，减少声音抖动。

图5为本发明提供的彩铃媒体服务器实施例的结构示意图，该彩铃媒体服务器可以执行本发明任意实施例的基于IP的彩铃业务实现方法。如图5所示，本实施例的彩铃媒体服务器可以包括内部接口模块51、逻辑控制模块52和外部接口模块53、铃音管理模块54。

其中，内部接口模块51用于与信令服务器进行第一媒体协商，获取媒体网关的信息；逻辑控制模块52用于记录所述媒体网关的信息；外部接口模块53用于根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；所述内部接口模块51还用于在所述第二媒体协商完成后，接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带铃音文件路径信息；所述逻辑控制模块52还用于记录所述铃音文件路径信息；铃音管理模块54用于根据记录的所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；所述外部接口模块53还用于将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。

其中，所述彩铃媒体服务器还包括：

编码模块，用于将所述铃音文件预先编码为基于IP的彩铃呼叫所需的媒体格式；

其中，所述将所述铃音文件预先编码为基于IP的彩铃呼叫所需的媒体格式，包括：

将所述铃音文件由G711格式编码为AMR2格式。

其中，所述铃音管理模块54具体用于：根据所述铃音文件路径信息，从彩铃平台将所述铃音文件按帧读入所述内存，且读入时去掉每帧的帧头，并在每帧前面预留4字节的空间；

在呼叫空闲时，根据所述第二媒体协商的协商结果生成NBUP包头，且将所述NBUP包头存入所述每帧前面预留4字节的空间，形成媒体包。

在空闲时生成媒体包，不需要在发送时再处理NBUP包头，减少了内存拷贝，减少声音抖动。

其中，所述外部接口模块具体用于从所述内存中读取所述媒体包，并将所述媒体包发送给媒体网关。

其中，所述内存扩张收缩大小为128K字节。由于彩铃业务中有多个呼叫并发的情况，此时，当彩铃媒体服务器同时播放多路铃音时，则要频繁进行内存申请、释放的操作，会导致内存容易产生碎片，导致系统占用内存持续增长，最终达到系统内存限制，导致系统崩溃。基于上述情况，将所述存储模块内存扩张收缩大小为128K字节。每次读取铃音文件申请的内存大小为128K字节的倍数，这样当每次呼叫结束时，释放系统资源后，内存会自动收缩，不会产生内存碎片，提高内存使用率。

本实施例的彩铃媒体服务器，通过设置内部接口模块、逻辑控制模块和外部接口模块、铃音管理模块、编码模块等，实现与信令服务器与业务逻辑服务器间基于IP网络协议控制信令的交互。该彩铃媒体服务器能够完成彩铃业务。而且在呼叫开始前，铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式，呼叫建立直接读取已编码铃音文件，由彩铃媒体服务器将铃音文件发送给媒体网关，再由媒体网关发送到主叫终端，能够提高彩铃媒体服务器性能、减少系统复杂性，提高内存使用率，减少内存拷贝，减少声音抖动。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (10)

1.一种基于IP的彩铃业务实现方法，其特征在于，包括：

与信令服务器进行第一媒体协商，获取媒体网关的信息；

记录所述媒体网关的信息；

根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；

在所述第二媒体协商完成后，接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带铃音文件路径信息；

记录所述铃音文件路径信息；

根据记录的所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；

将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。

2.根据权利要求1所述的方法，其特征在于，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式，包括：

将所述铃音文件由G711格式编码为AMR2格式。

3.根据权利要求1或2所述的方法，其特征在于，所述根据记录的所述铃音文件路径信息获取铃音文件，包括：

根据所述铃音文件路径信息，从彩铃平台将所述铃音文件按帧读入内存，且读入时去掉每帧的帧头，并在每帧前面预留4字节的空间；

在呼叫空闲时，根据所述第二媒体协商的协商结果生成NBUP包头，且将所述NBUP包头存入所述每帧前面预留4字节的空间，形成媒体包；

所述将所述铃音文件发送给所述媒体网关，包括：

从所述内存中读取所述媒体包，并将所述媒体包发送给所述媒体网关。

4.根据权利要求3所述的方法，其特征在于，

所述内存扩张收缩大小为128K字节。

5.根据权利要求3所述的方法，其特征在于，所述彩铃平台同时存储由G711格式编码为AMR2格式的铃音文件以及初始为G711格式的铃音文件。

6.一种彩铃媒体服务器，其特征在于，包括：内部接口模块，用于与信令服务器进行第一媒体协商，获取媒体网关的信息；

逻辑控制模块，用于记录所述媒体网关的信息；

外部接口模块，用于根据记录的所述媒体网关的信息，与所述媒体网关进行第二媒体协商；

所述内部接口模块还用于在所述第二媒体协商完成后，接收业务逻辑服务器发送的铃音播放消息，所述铃音播放消息中携带铃音文件路径信息；所述逻辑控制模块还用于记录所述铃音文件路径信息；

铃音管理模块，用于根据记录的所述铃音文件路径信息获取铃音文件，所述铃音文件预先被编码为基于IP的彩铃呼叫所需的媒体格式；

所述外部接口模块还用于将所述铃音文件发送给所述媒体网关，并由所述媒体网关发送给主叫终端。

7.根据权利要求6所述的彩铃媒体服务器，其特征在于，还包括：

编码模块，用于将所述铃音文件预先编码为基于IP的彩铃呼叫所需的媒体格式；

其中，所述将所述铃音文件预先编码为基于IP的彩铃呼叫所需的媒体格式，包括：

将所述铃音文件由G711格式编码为AMR2格式。

8.根据权利要求6或7所述的彩铃媒体服务器，其特征在于，所述铃音管理模块具体用于：

根据所述铃音文件路径信息，从彩铃平台将所述铃音文件按帧读入内存，且读入时去掉每帧的帧头，并在每帧前面预留4字节的空间；

在呼叫空闲时，根据所述第二媒体协商的协商结果生成NBUP包头，且将所述NBUP包头存入所述每帧前面预留4字节的空间，形成媒体包。

9.根据权利要求8所述的彩铃媒体服务器，其特征在于，所述外部接口模块具体用于：

从所述内存中读取所述媒体包，并将所述媒体包发送给所述媒体网关。

10.根据权利要求8所述的彩铃媒体服务器，其特征在于，所述内存扩张收缩大小为128K字节。