WO2017107750A1 - 呼叫放音控制方法及装置 - Google Patents

呼叫放音控制方法及装置 Download PDF

Info

Publication number
WO2017107750A1
WO2017107750A1 PCT/CN2016/108113 CN2016108113W WO2017107750A1 WO 2017107750 A1 WO2017107750 A1 WO 2017107750A1 CN 2016108113 W CN2016108113 W CN 2016108113W WO 2017107750 A1 WO2017107750 A1 WO 2017107750A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
playback
call
phoneme
codec
Prior art date
Application number
PCT/CN2016/108113
Other languages
English (en)
French (fr)
Inventor
常诚
吴亮
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2017107750A1 publication Critical patent/WO2017107750A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation

Definitions

  • the present disclosure relates to the field of mobile communication technologies, and, for example, to a call playback control method and apparatus.
  • the code pattern of the interaction of the media stream has the codec conversion function of the codec (Transcoder, TC), including adopting the G.711 single decoding format file.
  • the management calls the playback of the audio file, and directly uses the real-time transport protocol-Real-time Transport Protocol (RTP-TC-TONE) connection method in the virtual machine to perform call playback.
  • RTP-TC-TONE real-time transport protocol-Real-time Transport Protocol
  • the TC processing of the phonetic file can be directly performed in the virtual machine, and the virtual machine's ability to process the speech codec is relatively poor, and a virtual machine can only handle limited TC conversion, so the playback is performed.
  • a large number of virtual machines may be required in the service, and the codec conversion is very large for the virtual machine CPU and memory resources. Therefore, there is a limitation in performing call playback after completing the voice codec processing in the virtual machine, which will result in high configuration cost of the playback, which will waste the hardware resources of the cloud platform and also transmit the media stream.
  • the performance of the business has a large impact.
  • the present disclosure provides a call playback control method and apparatus, which can solve the problem that a voice codec process needs to be performed in a virtual machine in a current call playback process.
  • a call playback control method provided by an embodiment of the present disclosure includes the following steps:
  • the media gateway receives a call playback request carrying the voice packet information
  • the step of acquiring the sound cell list information, the codec information, and the phone number information associated with the sound packet information according to the call playback request includes:
  • the step of selecting a corresponding phoneme file according to the phoneme list information, the codec information, and the phoneme number information includes:
  • the phoneme file is determined based on the phoneme address.
  • the method before the step of the media gateway receiving the call playback request carrying the voice packet information, the method further includes:
  • the sound element file corresponding to the phoneme list information, the codec information selection, and the phoneme number information is used by the media gateway to perform playback after performing call TC resource analysis and connection processing.
  • the method further includes:
  • the media gateway After the media gateway performs playback, if it is detected that the parameter of the current session description request SDP is changed, the phoneme file corresponding to the change of the parameter of the session description request SDP is acquired.
  • the sound element file corresponding to the phoneme list information, the codec information selection, and the phoneme number information is used by the media gateway to perform playback after performing call TC resource analysis and connection processing.
  • the method further includes:
  • the media gateway After the media gateway performs playback, if the AMR rate of the playback listening end is changed, the phoneme file corresponding to the AMR rate change is acquired.
  • an embodiment of the present disclosure further provides a call play control device, where the call play control device includes:
  • a receiving module configured to receive a call playback request carrying the voice packet information
  • a first acquiring module configured to acquire, according to the call play request, the sound element list information, the codec information, and the phone number information associated with the sound package information
  • a selection module configured to select a corresponding phoneme file according to the phoneme list information, the codec information, and the phone number information, so that the media gateway performs the call TC resource analysis and the connection process
  • the sound listening end plays the sound element file.
  • the first obtaining module includes:
  • a querying unit configured to query, according to the call playback request, the playback identification information, the language type, and the codec information associated with the audio package information;
  • an acquiring unit configured to acquire the sound element list information and the sound element number information according to the playback identification information and the language type.
  • the selecting module includes:
  • a first determining unit configured to set the sound element list information, the codec information, and the sound
  • the meta number information determines the phone address
  • the second determining unit is configured to determine the phoneme file according to the phoneme address.
  • the call playback control device further includes:
  • a loading module configured to: before the media gateway receives a call playback request that carries the audio package information, loading the phoneme list information, the codec information, and the corresponding to the phoneme file that has been subjected to the codec process The phone number information.
  • the call playback control device further includes:
  • a second acquiring module configured to: in the sound element list information, the codec information selection, and the phoneme file corresponding to the phone number information, for the media gateway to perform call TC resource analysis and connection processing After playing the phoneme file on the backward playback side, and
  • the media gateway After the media gateway performs playback, if it is detected that the parameter of the current session description request SDP is changed, the phoneme file corresponding to the change of the parameter of the session description request SDP is acquired.
  • the call playback control device further includes:
  • a third acquiring module configured to: in the sound element list information, the codec information selection, and the phoneme file corresponding to the phone number information, for the media gateway to perform call TC resource analysis and connection processing After playing the phoneme file on the backward playback side, and
  • the media gateway After the media gateway performs playback, if the AMR rate of the playback listening end is changed, the phoneme file corresponding to the AMR rate change is acquired.
  • embodiments of the present disclosure also provide a non-transitory computer readable storage medium storing computer executable instructions for performing the above described call playback control method.
  • embodiments of the present disclosure also provide an electronic device including one or more processors, a memory, and one or more programs, the one or more programs being stored in the memory when being one or more When the processor executes, the above call playback control method is executed.
  • the embodiment of the present disclosure receives a call play request carrying the sound package information through the media gateway, and acquires the sound element list information, the codec information, and the phone number information associated with the sound package information according to the call play request, and according to the Selecting, according to the phoneme list information, the codec information, and the phone number information, a corresponding phoneme file, for the media gateway to play the call to the playback listener after performing call TC resource analysis and connection processing. Phone file.
  • the media gateway directly outputs the pattern data stream required for playback to the RTP, and does not perform the pattern conversion processing in the virtual machine.
  • the media gateway directly obtains the corresponding sound element file through the sound element addressing, and plays the sound element file, thereby saving the codec conversion resource, speeding up the sound reproduction efficiency, reducing the virtual machine's occupation of the hardware resources such as the CPU, and improving The number of virtual machines running on the physical machine, which improves the resource utilization of the physical hardware platform.
  • FIG. 1 is a schematic flow chart of a first embodiment of a call playback control method according to the present disclosure
  • FIG. 2 is a schematic structural diagram of a call play mode in the related art
  • FIG. 3 is a schematic structural diagram of a call play mode according to an embodiment of the present disclosure.
  • FIG. 4 is a schematic diagram of making and loading a phonetic file according to an embodiment of the present disclosure
  • FIG. 5 is a schematic diagram of user plane audio element addressing according to an embodiment of the present disclosure
  • FIG. 6 is a schematic diagram showing a refinement process of acquiring sequence information, codec information, and phone number information associated with the packet information according to a call play request in a second embodiment of the call play control method of the present disclosure
  • FIG. 7 is a schematic flowchart of selecting a corresponding sound element file according to the sound element list information, the codec information, and the sound element number information in the third embodiment of the call play control method according to the present disclosure
  • FIG. 8 is a schematic flow chart of a fourth embodiment of a call playback control method according to the present disclosure.
  • FIG. 9 is a schematic flow chart of a fifth embodiment of a call playback control method according to the present disclosure.
  • FIG. 10 is a schematic flowchart diagram of a sixth embodiment of a call playback control method according to the present disclosure.
  • FIG. 11 is a schematic diagram of functional modules of a first embodiment of a call play control apparatus according to the present disclosure
  • FIG. 12 is a schematic diagram of functional modules of a first acquisition module in a second embodiment of the call playback control apparatus of the present disclosure
  • FIG. 13 is a schematic diagram of functional modules of a selection module in a third embodiment of the call play control apparatus of the present disclosure.
  • FIG. 14 is a schematic diagram of functional modules of a fourth embodiment of the call play control apparatus of the present disclosure.
  • 15 is a schematic diagram of functional modules of a fifth embodiment of the call play control apparatus of the present disclosure.
  • Figure 16 is a schematic diagram of functional blocks of a sixth embodiment of the call play control apparatus of the present disclosure.
  • FIG. 17 is a schematic structural diagram of hardware of an electronic device according to the present disclosure.
  • FIG. 1 is a schematic flowchart diagram of a first embodiment of a call playback control method according to the present disclosure.
  • the call play control method includes S10-S30.
  • the media gateway receives a call play request that carries the voice packet information
  • the media gateway receives a call playback request sent by the server and carries the sound packet information, so as to request the media gateway to play the sound to the playback end.
  • the packet information includes a playback service parameter, such as a Uniform Resource Locator (URL) address.
  • URL Uniform Resource Locator
  • the media gateway acquires the sound element list information, the codec information, and the phone number information associated with the sound package information;
  • the media gateway After receiving the call playback request, according to the H.248 protocol, according to the call playback request, the media gateway acquires the sequence information and codec information associated with the audio package information that has been created and loaded. And the phone number information, and obtain the user face voice resource.
  • the TC resource analysis and the connection process are performed based on the H.248 protocol in the media gateway, so that the circuit of the user plane voice module in the media gateway is obtained. Turn on. After the circuit of the user plane voice module is turned on, the user plane voice module selects a corresponding sound element file to play according to the sound element list information, the codec information, and the phone number information.
  • the modification of the G.711 pattern playback link includes: playback process modification; multiple parking tone process transformation; number recovery process transformation; multiple stop number process transformation; context
  • Scene 1 The playback process of the G.711 pattern is: the pattern of the RTP is G.711, and the TONE uses the G.711 pattern of the elements, which is consistent with the internal A/U law of the gateway;
  • Scene 2 The G.711 playback + TC mode is modified to: the RTP code is G.711, and the TONE uses the G.711 pattern of the phone, which is consistent with the internal AU law of the gateway;
  • Scene 3 The compressed code playback process is modified as follows: the RTP pattern is a compressed pattern, and the TONE uses a G.711 pattern of sound elements, which is consistent with the gateway internal A/U law;
  • Scene 4 The compressed code type playback + TC mode is modified to: the RTP pattern is a compressed pattern, and the TONE uses a G.711 pattern of sound elements, which is consistent with the gateway internal A/U law.
  • the modification of the playback mode of other compressed patterns includes: modification of the playback process; transformation of various parking sound processes; transformation of the collection process; various process of the stop number process; Analysis process and subsequent detachment analysis and process transformation to support the following scenarios of continuation and TC resource analysis:
  • Scenario 1 The compressed code playback process is: a scenario in which the RTP pattern is consistent with the TONE pattern;
  • Scene 2 The process of receiving the sound + TC mode is: RTP code type is arbitrary, TONE adopts the G.711 code type of sound, which is consistent with the internal A/U law of the gateway; wherein, if the RTP code is not G.711 , do not receive the number.
  • the default G.711 pattern type sound element can be uniformly used for playback.
  • the call play mode is to decode and decode the sound data to be played into a pattern recognized by the playback terminal during playback, thereby achieving call placement.
  • the purpose of the sound is to decode and decode the sound data to be played into a pattern recognized by the playback terminal during playback, thereby achieving call placement. The purpose of the sound.
  • FIG. 3 is a schematic structural diagram of a call play mode according to an embodiment of the present disclosure, and the call of the embodiment of the present disclosure
  • the playback mode is that when the sound is played, the codec is not needed, and the sound element file to be played can be queried by means of the voice element addressing, thereby achieving the purpose of calling and playing.
  • FIG. 4 is a schematic diagram of the creation and loading of a phonetic file. After inputting a standard phone file in .wav format, the phoneme file is converted into codec information supported by the media gateway (such as a compressed code type payload file), and the The codec information is loaded and stored in the media gateway to provide a phonetic file for the call playback.
  • codec information supported by the media gateway (such as a compressed code type payload file)
  • FIG. 5 is a schematic diagram of user plane phoneme addressing.
  • Different types of phonetic files correspond to different types of codec information, so user plane playback can be based on codec parameters and phone identity (Identification) included in different types of codec information.
  • ID to index the phone address.
  • a two-level index can be established to create an array of phonetic indexes for each codec type (eg, the rate of Adaptive Multi-Rate Codec (AMR)). Indexing the phone address of the pattern according to the pattern information.
  • AMR Adaptive Multi-Rate Codec
  • the media gateway receives the call playback request carrying the audio package information, and acquires the sound element list information, the codec information, and the phone number information associated with the sound package information according to the call play request, and according to the Selecting a phoneme list information, the codec information, and the phone number information to select a corresponding phoneme file, so that the media gateway plays the tone to the playback listener after performing call TC resource analysis and connection processing. Metafile.
  • the media gateway In the use of the media gateway playback service of the cloud computing platform, according to the received call playback request, the media gateway directly outputs the pattern data stream required for playback to the RTP processing module, and does not perform pattern conversion in the virtual machine.
  • the processing enables the media gateway to directly obtain the corresponding sound element file through the sound element addressing, and play the sound element file, thereby saving the codec conversion resource, the method can speed up the sound reproduction efficiency, and reduce the virtual machine to the CPU and other hardware resources. Occupancy, increase the number of virtual machines running on the physical machine, thereby improving the resource utilization of the physical hardware platform.
  • the present disclosure also includes a second embodiment of the call play control method.
  • the above S20 may include S21-S22.
  • the playback identification information, the language type, and the codec information associated with the audio package information carried by the call playback request are queried and acquired.
  • the playback identification information may include a call playback configuration parameter, and the decoded information may include a codec parameter, a phoneme ID, and the like.
  • the phoneme list information and the phoneme number information are acquired according to the playback identification information and the language type.
  • the meta list information is applied to the user plane voice resource, and the sound element list information stores a plurality of codec sound element index addresses.
  • the playback identification information, the language type, and the codec information associated with the audio package information are queried according to the call playback request, and the sound is obtained according to the playback identification information and the language type.
  • Meta list information and the phone number information Since the sound element list information is a search form, the sound element address of each sound element file is recorded, and the sound element number information is a storage order for recording each sound element address of the sound element list information, thereby enabling the media gateway It can quickly obtain the phone address of the call playback, which can speed up the playback.
  • the above S30 includes S31-S32.
  • the phone address of the call play and the acquired sound element file is determined.
  • the phonetic file is determined according to the phoneme address.
  • Different types of phonetic files correspond to different types of codec information, so the user plane playback needs to index the phoneme addresses according to the codec parameters and the phoneme IDs contained in the different types of codec information.
  • a two-level index can be established, and a corresponding index array of sound elements needs to be established for each codec (eg, AMR rate), and the phone address of the code type is indexed according to the pattern information, and the index table needs to occupy the user.
  • AMR rate e.g., AMR rate
  • the phone file addressing process is performed when the user plane plays, that is, after the phone address is obtained, the phone file is determined according to the phone address, so that the media gateway plays the phone file to the playback end.
  • the phoneme address is determined according to the phoneme list information, the codec information, and the phoneme number information
  • the phoneme file is determined according to the phoneme address, so that the media gateway directly searches through the phoneme.
  • the call play control method may further include S40.
  • the phoneme list information, the codec information, and the phoneme number information corresponding to the phoneme file that has been subjected to the codec process are loaded.
  • a sound element file such as a G.711 codec (A/U law) type is converted into a binary file format and output according to different codecs.
  • Voice payload information files of different compressed patterns the conversion organizes the phonetic files of different codecs (such as G.729//EVRC/GSM_FR/..., etc.) generated according to certain rules.
  • the codec file is loaded into the media gateway tone management task/process.
  • the phoneme needs to be loaded (you can specify whether to filter the loaded phonemes); initiate the request from the network management->voice task (main), the voice task (main) enters the loading state; the voice task (main) passes the file transfer protocol (File Transfer Protocol, FTP) connects to the network management server, obtains the size of the file to be loaded, and obtains the file to be loaded to the local voice process (main); the voice task (main) updates the local phone configuration information, and does Persistence saving; the voice task (main) reports the progress of the download to the batch saved phonetic file; when all the codec to be loaded is processed, the response of the processing completion is reported.
  • FTP File Transfer Protocol
  • voice process (main) and the user plane voice process/voice process (standby) check and synchronization may include the following processing steps:
  • User-side voice process/voice process (standby) power-on processing user-side voice process/voice process (standby) reads the voice configuration information and phone number information and loads when power-on; user-side voice task/voice task Regularly comparing the loaded configuration information with the phone number information (including whether it exists, and the size, time, CRC information, etc.
  • voice process/voice process (standby) tone element initiates verification: the voice process (main) periodically sends the module information with normal communication status to the voice task (main); the data area used by the voice task (main) to open the sound element check
  • the voice task (main) performs local save and receives the voice verification request after the user plane voice process/voice process (standby) is powered on; the voice task (main) initiates voice check in the idle state; when a certain module After the completion of the voice verification, it is determined whether there is still a module to be verified, and if present, the voice task (main) initiates a voice round-robin check actively or periodically.
  • User plane voice process/voice process (standby) voice element verification process voice task (master) initiates voice verification; enters voice element synchronization state; user plane voice task/voice task (standby) saves voice after receiving voice verification
  • the task (main) information is obtained by comparing the phone configuration information with the local phone configuration information; after the inconsistent information is found, the voice metafile is reacquired from the voice process (main) through FTP, and the local voice configuration information is modified and persisted; After batch processing of the inconsistent data, the progress is reported to the voice task (main); when all the phonetic check requests are completed, the voice task (main) enters the idle state.
  • the user plane increases the organization of the sound memory management, that is, organizes the phonetic files of different codecs (such as G.729//EVRC/GSM_FR/8) generated.
  • First use two queues (both node mode dynamic application and release), for example, a file file queue and a free block queue.
  • the phone file queue is set to manage the inserted phone file;
  • the free block queue is set to manage the free memory block.
  • a target memory block slightly larger than the free memory block of the required size condition can be found, and the target memory block is split into the first sub-target memory block and the second sub-target memory block, and the first sub-target memory
  • the size of the block is the required size
  • the size of the second sub-target memory block is the remaining size of the size of the target memory block after removing the size of the first sub-target memory block.
  • a new file queue node is generated, pointing to the memory of the first sub-target memory block, and linking the file node to the file queue. Point the free node to the memory of the second sub-target memory block.
  • the file node When the user plane memory is released, you can find the file node corresponding to the memory that needs to be released, and check the memory pointed to by the file node. If the memory on the adjacent side of the memory pointed to by the file node is free memory, the adjacent sides will be adjacent. The free memory is merged with the memory pointed to by the file node. And a new idle node points to the merged memory, that is, the new idle node is linked into the idle node queue, and the idle nodes pointing to the adjacent sides are respectively released, and at the same time, the file node is released.
  • the memory is merged with the free memory on the side; if the memory on the adjacent side of the memory pointed to by the file node is not idle, a new one is generated.
  • the idle node manages the memory pointed to by the file node.
  • the memory compaction is actually a memory shift, that is, the memory of the file is copied forward, and the free memory is merged together.
  • the media gateway directly obtains the corresponding address through the phoneme addressing.
  • the audio file, and play the audio file without the need for pattern conversion processing during call playback, saving code conversion resources, which speeds up the playback efficiency and reduces the virtual machine's hardware resources such as CPU. Occupy, increase the number of virtual machines running on the physical machine, thereby improving the resource utilization of the physical hardware platform.
  • the call play control method further includes S50.
  • the SDP is a session description format, and can provide a multimedia session description for the purpose of session notification, session invitation, and other forms of multimedia session initialization.
  • the playback parameters can be modified correspondingly to reach the voice file of the playback terminal. You can continue playing.
  • SDP codec is required before and after SDP parameter switching.
  • the new SDP codec parameter is used to re-analyze whether the TC is needed. If the analysis result is that the new SDP requires TC, and the TC is currently being used, the original TC and the audio element resources are used to continue playing, and the playback metafile is not modified.
  • the new SDP codec parameter is used to re-analyze whether the TC is needed. If the analysis result is that the new SDP requires the TC, and the TC is not currently used, the TC resource can be applied first, and the connection between the RTP and the TONE is removed (when the playback channel of the user plane remains unreleased), and the RTP and the TC are connected.
  • the new SDP codec parameter is used to re-analyze whether the TC is needed. If the analysis result is that the new SDP does not require the TC, and the TC is currently being used, the connection between the RTP and the TC can be removed, the connection between the TC and the TONE is removed (the playback channel of the user plane remains unreleased), and the TC is released.
  • the media gateway performs playback, if it is detected that the current SDP parameter changes, the phone file corresponding to the change of the parameter of the SDP is acquired, so that the embodiment of the present disclosure is in a call.
  • the codec information of the call playback can be modified in time, so that the phonetic file of the call playback terminal can continue to play.
  • the call play control method further includes S60.
  • the multimedia network management can automatically recognize the AMR rate adjustment of the listening end, and can immediately switch to the new AMR rate to continue playing.
  • the voice resource module can identify the rate adjustment message sent by the listening end RTP, and perform analysis processing.
  • the user plane voice playback channel automatically switches to the new AMR rate, and the time before the switching pattern is played can be recalculated, and the new pattern is played from the switching pattern.
  • the AMR rate of the control process of the user plane is notified, and the control process of the user plane modifies the playback statistics. If the adjusted corresponding AMR rate is not loaded, the voice playback channel automatically plays the G.711 pattern of the voice element for playback.
  • the AMR codec playback can be requested to reduce the playback rate, thereby ensuring the quality of playback.
  • FIG. 11 is a schematic diagram of functional modules of a first embodiment of a call playback control apparatus according to the present disclosure.
  • the call play control device includes: a receiving module 10, a first obtaining module 20, and a selecting module 30.
  • the receiving module 10 is configured to receive a call play request that carries the voice packet information
  • the receiving module 10 in the media gateway receives the call playback request sent by the server and carries the sound packet information, and requests the media gateway to play the sound to the playback end.
  • the package information may include playback service parameters such as a URL address.
  • the first obtaining module 20 is configured to acquire, according to the call play request, the sound element list information, the codec information, and the phone number information associated with the sound package information;
  • the first obtaining module 20 in the media gateway After receiving the call play request, according to the H.248 protocol, according to the call play request, the first obtaining module 20 in the media gateway acquires the phonemes associated with the sound package information that have been created and loaded. List information, codec information, and phone number information, and obtain user-side voice resources.
  • the selecting module 30 is configured to select a corresponding phoneme file according to the phoneme list information, the codec information, and the phoneme number information, so that the media gateway performs call TC resource analysis and connection. After processing, the phonetic file is played to the playback listening end.
  • the TC resource analysis and the connection process are performed based on the H.248 protocol in the media gateway, so that the circuit of the user plane voice module in the media gateway is connected. through.
  • the user plane voice module selects a corresponding sound element file to play according to the sound element list information, the codec information, and the phone number information.
  • the modification of the G.711 pattern playback link may include: playback process modification; multiple parking tone process transformation; number recovery process transformation; multiple stop number process transformation; Context resource analysis process and subsequent detachment analysis and process transformation to support the following scenario connection and TC resource analysis:
  • Scene 1 The playback process of the G.711 pattern is: the pattern of the RTP is G.711, and the TONE uses the G.711 pattern of the elements, which is consistent with the internal A/U law of the gateway;
  • Scene 3 The compressed code playback process is modified as follows: the RTP pattern is a compressed pattern, and the TONE uses a G.711 pattern of sound elements, which is consistent with the gateway internal A/U law;
  • Scene 4 Compressed pattern playback + TC mode collection process is modified to: RTP code is compression, TONE
  • RTP code is compression
  • TONE The G.711 pattern is used in the same way as the internal A/U law of the gateway.
  • the modification of the playback mode of other compressed patterns may include: playback process modification; multiple parking tone process transformation; collection process modification; multiple stop number process transformation; context
  • playback process modification may include: playback process modification; multiple parking tone process transformation; collection process modification; multiple stop number process transformation; context
  • the resource analysis process and the subsequent analysis and processing process transformation to support the following scenarios of connection and TC resource analysis:
  • Scenario 1 The compressed code playback process is: a scenario in which the RTP pattern is consistent with the TONE pattern;
  • Scene 2 The process of receiving the sound + TC mode is: RTP code type is arbitrary, TONE adopts the G.711 code type of sound, which is consistent with the internal A/U law of the gateway; wherein, if the RTP code is not G.711 , do not receive the number.
  • the default G.711 pattern type sound element can be uniformly used for playback.
  • the receiving module 10 receives the call playback request carrying the sound packet information
  • the first obtaining module 20 acquires the sound element list information, the codec information, and the sound element associated with the sound package information according to the call playback request.
  • the numbering information, the selection module 30 selects a corresponding phoneme file according to the phoneme list information, the codec information, and the phoneme number information, for the media gateway to perform call TC resource analysis and connection processing.
  • the sound file is played on the playback end.
  • the media gateway plays the voice service in the cloud computing platform, according to the received call playback request, the media gateway can directly output the code data stream required for playback to the RTP processing module, and does not perform the pattern in the virtual machine.
  • the conversion process enables the media gateway to directly obtain the corresponding phoneme file through the phoneme addressing, and play the phonetic file, which can save the codec conversion resource.
  • the method can speed up the playback efficiency and reduce the hardware of the virtual machine to the CPU.
  • the occupation of resources increases the number of virtual machines running on the physical machine, thereby improving the resource utilization of the physical hardware platform.
  • the first acquisition module 20 may include a query unit 21 and an acquisition unit 22.
  • the query unit 21 is configured to query the playback identification information, the language type, and the codec information associated with the audio package information according to the call playback request;
  • the playback identification information, the language type, and the codec information associated with the audio package information carried by the call playback request are queried and obtained according to the call playback request, and the playback identification information may include Calling the playback configuration parameter, the decoded information may include a codec parameter, a phoneme ID, and the like.
  • the acquiring unit 22 is configured to acquire the sound element list information and the sound element number information according to the playback identification information and the language type.
  • the phoneme list information is applied to the user plane voice resource, and the phoneme list information stores a plurality of codec phone element index addresses.
  • the media gateway by referring to the call playback request, querying a playback target associated with the audio package information The information, the language type, and the codec information are obtained, and the sound element list information and the sound element number information are obtained according to the playback identification information and the language type. Since the sound element list information is a search form, the sound element address of each sound element file is recorded, and the sound element number information is a storage order in which each sound element address of the sound element list information is recorded, so that the media gateway can be made It can quickly obtain the phone address of the call playback, which can speed up the playback.
  • the selection module 30 may include a first determination unit 31 and a second determination unit 32.
  • the first determining unit 31 is configured to determine a phoneme address according to the phoneme list information, the codec information, and the phoneme number information;
  • the phone address of the call play and the acquired sound element file is determined.
  • the second determining unit 32 is configured to determine the phoneme file according to the phoneme address.
  • the user plane playback needs to index the phoneme address according to the codec parameters and the phoneme IDs included in different types of codec information.
  • a two-level index can be established.
  • a corresponding audio index array needs to be established for each codec (eg, AMR rate, etc.), and the phone address of the code type is indexed according to the code type information, and the index table needs to occupy a certain memory space of the user plane.
  • the phone file addressing process is performed when the user plane plays, that is, after the phone address is obtained, the phone file is determined according to the phone address, so that the media gateway plays the phone file to the playback end.
  • the phoneme address is determined according to the phoneme list information, the codec information, and the phoneme number information
  • the phoneme file is determined according to the phoneme address, so that the media gateway directly searches through the phoneme.
  • the call playback control device may further include: a loading module 40.
  • the loading module 40 is configured to load the phoneme list information, the codec information, and the phone number information corresponding to the phoneme file that has been subjected to codec processing.
  • a sound element file such as a G.711 codec (A/U law) type is converted into a binary file format and output according to different codecs.
  • Voice payload information files of different compressed patterns the conversion organizes the phonetic files of different codecs (such as G.729//EVRC/GSM_FR/..., etc.) generated according to certain rules.
  • the codec file is loaded into the media gateway tone management task/process.
  • the user Select the phonem to be loaded (you can specify whether to filter the loaded phone); initiate the request from the network management -> voice task (master), the voice task (master) enters the loading state; the voice task (master) connects to the network management service via FTP End, get the size of the file to be loaded, and get the file to be loaded to the local voice process (main); voice task (main) update the local phone configuration information, and make persistent preservation; voice task (main) pair
  • the batch saves the phonetic file to report the progress of the download; when all the codec to be loaded is processed, the response of the process is reported.
  • voice process (main) and the user plane voice process/voice process (standby) check and synchronization include the following processing steps:
  • User-side voice process/voice process (standby) power-on processing user-side voice process/voice process (standby) reads the voice configuration information and phone number information and loads when power-on; user-side voice task/voice task Regularly comparing the loaded configuration information with the phone number information (including whether it exists, and the size, time, CRC information, etc.
  • voice process/voice process (standby) tone element initiates verification: the voice process (main) periodically sends the module information with normal communication status to the voice task (main); the data area used by the voice task (main) to open the sound element check
  • the voice task (main) performs local save and receives the voice verification request after the user plane voice process/voice process (standby) is powered on; the voice task (main) initiates voice check in the idle state; when a certain module After the completion of the voice verification, it is determined whether there is still a module to be verified, and if present, the voice task (main) initiates a voice round-robin check actively or periodically.
  • User plane voice process/voice process (standby) voice element verification process voice task (master) initiates voice verification; enters voice element synchronization state; user plane voice task/voice task (standby) saves voice after receiving voice verification
  • the task (main) information is obtained by comparing the phone configuration information with the local phone configuration information; after the inconsistent information is found, the voice metafile is reacquired from the voice process (main) through FTP, and the local voice configuration information is modified and persisted; After batch processing of the inconsistent data, the progress is reported to the voice task (main); when all the phonetic check requests are completed, the voice task (main) enters the idle state.
  • the user plane increases the organization of the sound memory management, that is, organizes the phonetic files of different codecs (such as G.729//EVRC/GSM_FR/8) generated.
  • First use two queues (both node mode dynamic application and release), for example, a file file queue and a free block queue.
  • the phone file queue is used to manage the inserted phone file;
  • the free block queue is used to manage the free memory block.
  • the target memory block When allocating memory, you can find a target memory block that is slightly larger than the free memory block of the required size condition, splitting the target memory block into the first sub-target memory block and the second sub-target memory block, the first sub-target memory.
  • the size of the block is the required size
  • the size of the second sub-target memory block is the remaining size of the size of the target memory block after removing the size of the first sub-target memory block.
  • a new file queue node is generated, pointing to the memory of the first sub-target memory block, and linking the file node to the file queue. Point the free node to the memory of the second sub-target memory block.
  • the free node is not needed and the idle node can be released.
  • the user plane memory When the user plane memory is released, find the file node corresponding to the memory that needs to be released, and check the memory pointed to by the file node. If the memory on the adjacent side of the memory pointed to by the file node is free memory, the adjacent sides will be The free memory is merged with the memory pointed to by the file node. And a new idle node points to the merged memory, that is, the new idle node is linked into the idle node queue, and then the free nodes on the adjacent sides are respectively released, and the file node is released. If only the memory side pointed to by the file node is free memory, the memory is merged with the free memory on the side; if the memory on the adjacent sides of the memory pointed to by the file node is not idle, a new one is generated. The idle node manages the memory pointed to by the file node.
  • the memory compaction is actually a memory shift, that is, the memory of the file is copied forward, and the free memory is merged together.
  • the media gateway directly obtains the corresponding address through the phoneme addressing.
  • the audio file, and play the audio file without the need for pattern conversion processing during call playback, saving code conversion resources, which speeds up the playback efficiency and reduces the virtual machine's hardware resources such as CPU. Occupy, increase the number of virtual machines running on the physical machine, thereby improving the resource utilization of the physical hardware platform.
  • the call playback control device further includes: a second acquisition module 50 .
  • the second obtaining module 50 is configured to: when the parameter of the current session description protocol SDP is changed after the media gateway performs playback, acquire a phone element corresponding to a change of the parameter of the SDP. file.
  • the playback parameters can be modified correspondingly to reach the voice file of the playback terminal. You can continue playing.
  • SDP codec is required before and after SDP parameter switching.
  • the new SDP codec parameter is used to re-analyze whether the TC is needed. If the analysis result is that the new SDP requires TC, and the TC is currently being used, the original TC and the audio element resources are used to continue playing, and the playback metafile is not modified.
  • No codec is required before and after SDP parameter switching.
  • the new SDP codec parameter is used to re-analyze whether the TC is needed. If the analysis results in that the new SDP does not require a TC and the TC is not currently used, the current flow remains unchanged.
  • the new SDP codec parameters are used to re-analyze whether the TC is needed. If the analysis result is that the new SDP requires the TC, and the TC is not currently used, the TC resource can be applied first, and the connection between the RTP and the TONE is removed (when the playback channel of the user plane remains unreleased), and the RTP and the TC are connected.
  • the playback channel switches to the new pattern (G.711 is consistent with the internal A/U law of the network element) Metafile, and can calculate the time before the switching pattern is played, and use the new pattern to play from the switching pattern.
  • the new SDP codec parameter is used to re-analyze whether the TC is needed. If the analysis result is that the new SDP does not require the TC, and the TC is currently being used, the connection between the RTP and the TC can be removed, the connection between the TC and the TONE is removed (the playback channel of the user plane remains unreleased), and the TC is released.
  • the media gateway performs playback, if it is detected that the current SDP parameter changes, the phone file corresponding to the change of the parameter of the SDP is acquired, so that the embodiment of the present disclosure is in a call.
  • the codec information of the call playback can be modified in time, so that the phonetic file of the call playback terminal can continue to play.
  • the call play control apparatus further includes:
  • the third obtaining module 60 is configured to: after the media gateway performs playback, if the AMR rate of the playback listening end is changed, the sound corresponding to the AMR rate is acquired. Metafile.
  • the present disclosure can automatically identify the AMR rate adjustment of the listening end, and can switch to the new AMR rate to continue playing.
  • the voice resource module identifies the rate adjustment packet sent by the peer RTP processing module, and performs analysis processing, when the media gateway loads the sound bank of the different rate sets before and after the AMR adjustment.
  • the user plane voice playback channel switches to the new AMR rate by itself, and can recalculate the time before the switching pattern is played, and starts playing the new pattern from the switching pattern.
  • the AMR rate of the control process of the user plane is notified, and the control process of the user plane modifies the playback statistics. If the adjusted sound corresponding to the AMR rate is not loaded, the voice playback channel can automatically play the G.711 pattern of the sound element for playback.
  • the phoneme file corresponding to the AMR rate change is acquired.
  • the wireless signal where the playback end is located is weak.
  • the AMR codec playback is requested to reduce the playback rate, thereby ensuring the quality of playback.
  • Embodiment 7 of the present disclosure further provides a non-transitory computer readable storage medium storing computer executable instructions for executing the call play control method.
  • Embodiment 8 of the present disclosure further provides an electronic device.
  • the electronic device may include:
  • a processor 710 and a memory 720 may further include a communications interface 730 and a bus 740.
  • the processor 710, the memory 720, and the communication interface 730 can complete communication with each other through the bus 740.
  • Communication interface 730 can be used for information transfer.
  • the processor 710 can call the logic instructions in the memory 720 to perform the call play control method of the above embodiment.
  • the logic instructions in the memory 720 described above may be implemented in the form of a software functional unit and sold or used as a stand-alone product, and may be stored in a computer readable storage medium.
  • the technical solution of the present disclosure may be embodied in the form of a software product stored in a storage medium, including a plurality of instructions for causing a computer device (which may be a personal computer, a server, or a network) The device or the like) performs all or part of the steps of the method described in the embodiments of the present disclosure.
  • the foregoing storage medium may be a non-transitory storage medium, including: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
  • a medium that can store program code, or a transitory storage medium including: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
  • the program when executed, may include a flow of an embodiment of the method described above, wherein the computer readable storage medium may be a magnetic disk, an optical disk, a read only memory (ROM), or a random access memory. (RAM), etc.
  • the computer readable storage medium may be a magnetic disk, an optical disk, a read only memory (ROM), or a random access memory. (RAM), etc.
  • Embodiments of the present disclosure implement a media gateway in a cloud computing platform through a disclosed call playback control method
  • the media gateway can output the code data stream required for playback to the RTP processing module, and can not perform pattern conversion processing in the virtual machine, thereby saving code conversion resources and speeding up playback efficiency and reducing
  • the virtual machine occupies hardware resources such as CPU, thereby improving the resource utilization of the physical hardware platform.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种呼叫放音控制方法和装置，该方法包括：媒体网关接收携带音包信息的呼叫放音请求；根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；以及根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。

Description

呼叫放音控制方法及装置 技术领域
本公开涉及移动通信技术领域，例如涉及一种呼叫放音控制方法及装置。
背景技术
随着移动通信技术的发展，电话普及率的提高，用户对电信业务的要求越来越高，呼叫放音业务成为一项重要的电信业务。目前，在云计算平台中，媒体网关在呼叫放音时，对媒体流的交互的码型具备编解码器(Transcoder，TC)的编解码转换的功能，包括采用G.711单一解编码格式文件的管理呼叫放音的音元文件，并在虚拟机中直接采用在实时传输协议-编解码-音元(Real-time Transport Protocol，RTP-TC-TONE)的接续方式来进行呼叫放音。即在虚拟化的硬件平台上，可直接在虚拟机中进行音元文件的TC处理，而虚拟机处理语音编解码的能力相对比较差，一个虚拟机仅能处理有限的TC转换，因此放音业务中可能需要占用大量的虚拟机，同时编解码转换对虚拟机CPU和内存资源占用非常大。因此在通过在虚拟机中完成语音编解码处理后再进行呼叫放音具有局限性，这将导致放音的配置成本很高，会造成云平台的硬件资源的浪费，同时也对媒体流的传输业务的性能造成了较大的影响。
发明内容
本公开提供一种呼叫放音控制方法及装置，可解决当前呼叫放音流程中需要在虚拟机中进行语音编解码处理的问题。
本公开实施例提供的一种呼叫放音控制方法，所述呼叫放音控制方法包括以下步骤：
媒体网关接收携带音包信息的呼叫放音请求；
根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；以及
根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。
可选地，所述根据呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息的步骤包括：
根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息；以及
根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元 编号信息。
可选地，所述根据音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件的步骤包括：
根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址；以及
根据所述音元地址确定所述音元文件。
可选地，所述媒体网关接收携带音包信息的呼叫放音请求的步骤之前还包括：
加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息。
可选地，所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件的步骤之后，还包括：
在所述媒体网关进行放音后，若检测到当前的会话描述请求SDP的参数发生改变时，则获取与所述会话描述请求SDP的参数发生改变时对应的音元文件。
可选地，所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件的步骤之后，还包括：
在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。
此外，本公开实施例还提供一种呼叫放音控制装置，所述呼叫放音控制装置包括：
接收模块，设置为接收携带音包信息的呼叫放音请求；
第一获取模块，设置为根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；以及
选择模块，设置为根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。
可选地，所述第一获取模块包括：
查询单元，用于根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息；
获取单元，设置为根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。
可选地，所述选择模块包括：
第一确定单元，设置为根据所述音元列表信息、所述编解码信息及所述音 元编号信息确定音元地址；以及
第二确定单元，设置为根据所述音元地址确定所述音元文件。
可选地，所述呼叫放音控制装置还包括：
加载模块，设置为在所述媒体网关接收携带音包信息的呼叫放音请求之前，加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息。
可选地，所述呼叫放音控制装置还包括：
第二获取模块，设置为在所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件之后，以及
在所述媒体网关进行放音后，若检测到当前的会话描述请求SDP的参数发生改变时，则获取与所述会话描述请求SDP的参数发生改变时对应的音元文件。
可选地，所述呼叫放音控制装置还包括：
第三获取模块，设置为在所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件之后，以及
在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。
此外，本公开实施例还提供一种非暂态计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述呼叫放音控制方法。
此外，本公开实施例还提供一种电子设备，该电子设备包括一个或多个处理器、存储器以及一个或多个程序，所述一个或多个程序存储在存储器中，当被一个或多个处理器执行时，执行上述呼叫放音控制方法。
本公开实施例通过媒体网关接收携带音包信息的呼叫放音请求，根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息，并根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。由于在云计算平台的媒体网关放音业务使用中，根据接收到的呼叫放音请求，该媒体网关直接出放音需要的码型数据流到RTP，不在虚拟机内进行码型的转换处理，使得媒体网关直接通过音元寻址获取到对应的音元文件，并播放该音元文件，节省了编解码转换资源，并加快了放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而提高了物理硬件平台的资源利用率。
附图说明
图1为本公开呼叫放音控制方法的第一实施例的流程示意图；
图2为相关技术中呼叫放音方式的构架示意图；
图3为本公开实施例呼叫放音方式的构架示意图；
图4为本公开实施例的音元文件制作与装载示意图；
图5为本公开实施例的用户面音元寻址示意图；
图6为本公开呼叫放音控制方法的第二实施例中根据呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息的细化流程示意图；
图7为本公开呼叫放音控制方法的第三实施例中根据音元列表信息、编解码信息及音元编号信息选择对应的音元文件的流程示意图；
图8为本公开呼叫放音控制方法的第四实施例的流程示意图；
图9为本公开呼叫放音控制方法的第五实施例的流程示意图；
图10为本公开呼叫放音控制方法的第六实施例的流程示意图；
图11为本公开呼叫放音控制装置的第一实施例的功能模块示意图；
图12为本公开呼叫放音控制装置的第二实施例中第一获取模块的功能模块示意图；
图13为本公开呼叫放音控制装置的第三实施例中选择模块的功能模块示意图；
图14为本公开呼叫放音控制装置的第四实施例的功能模块示意图；
图15为本公开呼叫放音控制装置的第五实施例的功能模块示意图；
图16为本公开呼叫放音控制装置的第六实施例的功能模块示意图；以及
图17为本公开一种电子设备的硬件结构示意图。
具体实施方式
应当理解，此处所描述的可选实施例仅仅用以解释本公开，并不用于限定本公开。在不冲突的情况下，以下实施例和实施例中的特征可以相互组合。
参照图1，图1为本公开呼叫放音控制方法的第一实施例的流程示意图。
在本实施例中，所述呼叫放音控制方法包括S10-S30。
在S10中，媒体网关接收携带音包信息的呼叫放音请求；
在本实施例中，媒体网关接收到服务器发送的携带音包信息的呼叫放音请求，以请求该媒体网关向放音收听端放音。该音包信息包含放音业务参数，如统一资源定位符(Uniform Resource Locator，URL)地址。
在S20中，根据所述呼叫放音请求，媒体网关获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；
在接收到该呼叫放音请求后，基于H.248协议，根据该呼叫放音请求，该媒体网关获取已制作并已加载完成的、与该音包信息关联的音元列表信息、编解码信息及音元编号信息，并获取用户面语音资源。
在S30中，根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。
在获取到该音元列表信息、编解码信息及音元编号信息后，基于该媒体网关中的H.248协议，进行TC资源分析和接续处理，使得该媒体网关中的用户面语音模块的电路接通。在该用户面语音模块的电路接通后，该用户面语音模块根据该音元列表信息、编解码信息及音元编号信息选择对应的音元文件进行播放。
基于该媒体网关中的H.248协议，对G.711码型放音环节的改造包括：放音流程改造；多种停放音流程改造；收号流程改造；多种停收号流程改造；上下文资源分析流程和接续拆续分析和处理流程改造，以支持以下场景的接续和TC资源分析：
场景1：G.711码型的放音流程为：RTP的码型为G.711，TONE采用G.711码型的音元，与网关内部A/U律一致；
场景2：G.711放音+TC方式收号流程改造为：RTP的码型为G.711，TONE采用G.711码型的音元，与网关内部AU律一致；
场景3：压缩码型放音流程改造为：RTP的码型为压缩码型，TONE采用G.711码型的音元，与网关内部A/U律一致；
场景4：压缩码型放音+TC方式收号流程改造为：RTP的码型为压缩码型，TONE采用G.711码型的音元，与网关内部A/U律一致。
基于该媒体网关中的H.248协议，对其他压缩码型放音环节的改造包括：放音流程改造；多种停放音流程改造；收号流程改造；多种停收号流程改造；上下文资源分析流程和接续拆续分析和处理流程改造，以支持以下场景的接续和TC资源分析：
场景1：压缩码型放音流程为：RTP的码型与TONE的码型一致的场景；
场景2：放音+TC方式收号流程为：RTP的码型任意，TONE采用G.711码型的音元，与网关内部A/U律一致；其中，如果RTP的码型不是G.711，不收号。
需要说明的是，当没有加载压缩码型的音库时，如果需要放音，可以统一采用默认的G.711码型的音元进行放音。
图2为相关技术中呼叫放音方式的构架示意图，相关技术中的呼叫放音方式是在放音时，将需要放音的音数据编解码成放音终端识别的码型，从而达到呼叫放音的目的。
图3为本公开实施例的呼叫放音方式的构架示意图，本公开实施例的呼叫 放音方式是在放音时，不需要编解码，可通过音元寻址的方式查询到需要播放的音元文件，从而达到呼叫放音的目的。
图4为音元文件制作与装载示意图，输入标准的.wav格式的音元文件后，将该音元文件转换成媒体网关支持的编解码信息(如压缩码型净荷文件)，并将该编解码信息加载且存储到该媒体网关中，以提供呼叫放音的音元文件。
图5为用户面音元寻址示意图，不同类型的音元文件对应不同类型的编解码信息，因此用户面放音可以根据不同类型的编解码信息包含的编解码参数和音元身份标识(Identification，ID)来索引音元地址，为此，可以建立两级索引，为每种编解码型(如：自适应多速率编解码(Adaptive Multi-Rate Codec，AMR)的速率)建立一个音元索引数组，根据码型信息索引该种码型的音元地址。
本实施例通过媒体网关接收携带音包信息的呼叫放音请求，根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息，并根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。
由于在云计算平台的媒体网关放音业务使用中，根据接收到的呼叫放音请求，该媒体网关直接输出放音需要的码型数据流到RTP处理模块，不在虚拟机内进行码型的转换处理，使得媒体网关可直接通过音元寻址获取到对应的音元文件，并播放该音元文件，可节省编解码转换资源，该方法可加快放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而可提高物理硬件平台的资源利用率。
可选地，基于所述第一实施例，本公开实还包括呼叫放音控制方法的第二实施例，在本实施例中，参照图6，上述S20可以包括S21-S22。
在S21中，根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息；
在本实施例中，根据该呼叫放音请求，查询并获取与该呼叫放音请求携带的音包信息关联的放音标识信息、语言类型及所述编解码信息。
其中，该放音标识信息可包括呼叫放音配置参数，该解编码信息可包括编解码参数和音元ID等。
在S22中，根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。
在获取到与该呼叫放音请求携带的音包信息关联的放音标识信息和语言类型后，基于该媒体网关中的H.248协议，查询该与该放音标识信息、语言类型对应的音元列表信息，并申请用户面语音资源，该音元列表信息存储的是多个编解码音元索引地址。
本实施例通过根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息，并根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。由于该音元列表信息是一个检索表格，记录了每个音元文件的音元地址，而该音元编号信息是记录该音元列表信息每个音元地址的存储顺序，因此可使得媒体网关能够快速的获取到呼叫放音的音元地址，从而可加快放音效率。
可选地，基于所述第一实施例，在本公开呼叫放音控制方法的第三实施例中，参照图7，上述S30包括S31-S32。
在S31中，根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址；
在本实施例中，在获取到音元列表信息、音元编号信息后，结合与该呼叫放音请求关联的编解码信息，确定该呼叫放音与获取的音元文件的音元地址。
在S32中，根据所述音元地址确定所述音元文件。
不同类型的音元文件对应不同类型的编解码信息，因此用户面放音需要根据不同类型的编解码信息包含的编解码参数和音元ID来索引音元地址。为此，可以建立两级索引，需要为每种编解码(如：AMR速率)建立一个对应的音元索引数组，根据码型信息索引该种码型的音元地址，该索引表需要占用用户面一定的内存空间。
用户面放音时音元文件寻址处理，即在获取到该音元地址后，根据该音元地址确定该音元文件，以供该媒体网关向放音收听端播放该音元文件。
本实施例通过根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址，根据所述音元地址确定所述音元文件，使得媒体网关直接通过音元寻址获取到对应的音元文件，并播放该音元文件，而可以无需在呼叫放音时进行码型转换处理，可节省编解码转换资源，该方法可加快放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而可提高物理硬件平台的资源利用率。
可选地，基于所述第一实施例，在本公开呼叫放音控制方法的第四实施例中，参照图8，上述S10之前，所述呼叫放音控制方法还可以包括S40。
在S40中，加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息。
在本实施例中，在输入标准的.wav格式的音元文件后，如G.711编解码(A/U律)类型的音元文件，通过转换为二进制文件格式，根据不同的编解码输出不同压缩码型的语音净荷信息文件；该转换按照一定规则，对生成的不同编解码(如G.729//EVRC/GSM_FR/…等)的音元文件进行组织。
将编解码的音库文件加载到该媒体网关主音管理任务中/进程中。根据用户的选择需要加载的音元(可以指定是否过滤已加载音元)；从网管-＞语音任务(主)发起请求，语音任务(主)进入加载状态；语音任务(主)通过文件传输协议(File Transfer Protocol，FTP)连接到网管服务端，获取需要加载的文件大小，并获取需要加载的文件到本地的语音进程(主)；语音任务(主)更新本地的音元配置信息，并做持久化的保存；语音任务(主)对批量保存的音元文件上报下载的进度；当所有的待加载的编解码音元处理完成后，上报处理完成的响应。
需要说明的是，语音进程(主)与用户面语音进程/语音进程(备)校验与同步，可包含以下的处理步骤：
用户面语音进程/语音进程(备)上电处理：用户面语音进程/语音进程(备)在上电时，读取语音配置信息和音元编号信息并加载；用户面语音任务/语音任务(备)定期比较加载的配置信息和音元编号信息(包括是否存在，且大小、时间、CRC信息等一致比较)，并删除不一致的信息；向语音任务(主)发起音校验请求并收到响应；用户面语音进程/语音进程(备)音元发起校验：语音进程(主)定期向语音任务(主)发送通信状态正常的模块信息；语音任务(主)开音元校验使用的数据区；语音任务(主)进行本地保存收到用户面语音进程/语音进程(备)上电后发起音校验请求；语音任务(主)在空闲态的情况下发起语音校验；当某个模块的语音校验完成后判断是否还有待校验的模块，如果存在则语音任务(主)主动或定时发起语音轮循校验。
用户面语音进程/语音进程(备)音元校验过程：语音任务(主)发起语音校验；进入音元同步态；用户面语音任务/语音任务(备)收到语音校验后保存语音任务(主)信息并获取音元配置信息与本地音元配置信息进行比较；发现不一致的信息后通过FTP从语音进程(主)重新获取语音元文件，修改本地的语音配置信息并持久化保存；批量处理完不一致的数据后上报进度给语音任务(主)；当所有音元检查请求完成后，语音任务(主)进入空闲态。
同时，用户面增加对音内存管理组织方式，即对生成的不同编解码(如G.729//EVRC/GSM_FR/…等)的音元文件进行组织。首先使用两个队列(节点方式均动态申请和释放)，例如，音元文件队列及空闲块队列。其中，音元文件队列，设置为管理插入的音元文件；空闲块队列，设置为管理空闲内存块。
在分配内存时，可找到一个比所要求尺寸条件的空闲内存块稍大的目标内存块，将该目标内存块分裂为第一子目标内存块和第二子目标内存块，第一子目标内存块的大小为所要求的尺寸大小，第二子目标内存块的大小为该目标内存块的大小去除第一子目标内存块的大小后的剩余大小。产生新的文件队列节点，指向第一子目标内存块的的内存，并将该文件节点链入文件队列。将空闲结点指向第二子目标内存块的内存。此外，本领域技术人员应该理解，当可以找到一个完全符合所要求尺寸条件的空闲内存块时，则该空闲节点就不需要了， 可以将该空闲节点释放掉。
在用户面内存释放时，可以找到需要释放的内存对应的文件节点，并检查文件节点指向的内存，如果该文件节点指向的内存的相邻两侧内存均为空闲内存，则将相邻两侧的空闲内存和该文件节点指向的内存进行合并。并用一个新的空闲节点指向该合并的内存，即新的空闲节点链入空闲节点队列，则分别指向该相邻两侧的空闲节点被释放，同时，释放文件节点。如果仅该文件节点指向的内存一侧为空闲内存，则将本内存和该一侧的空闲内存进行合并；如果该文件节点指向的内存的相邻两侧内存均不空闲，则产生一个新的空闲节点管理该文件节点指向的内存。
在用户面内存紧缩时，即当共享内存中的空闲碎片过多，虽然总的空闲容量能满足一个音元的记录，但是没有一个单一的碎片能容纳音元的记录，则需要内存紧缩。内存紧缩实际就是内存移位，即将有文件的内存向前拷贝，空闲内存合并到一起。
本实施例通过加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息，使得媒体网关直接通过音元寻址获取到对应的音元文件，并播放该音元文件，而不需要在呼叫放音时进行码型转换处理，节省了编解码转换资源，该方法加快了放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而提高了物理硬件平台的资源利用率。
可选地，基于上述第一至第三任一实施例，在本公开呼叫放音控制方法的第五实施例中，参照图9，上述S30之后，所述呼叫放音控制方法还包括S50。
在S50中，在所述媒体网关进行放音后，若检测到会话描述协议(Session Description Protocol，SDP)的参数发生改变时，则获取与所述SDP的参数发生改变时对应的音元文件，其中，SDP是一种会话描述格式，可以为会话通知、会话邀请和其他形式的多媒体会话初始化等目的提供多媒体会话描述。
在本实施例中，在放音过程中，当放音终端发生SDP切换(如：SDP中的放音编解码等参数修改)，可及时对应修改放音参数，达到放音终端的音元文件可以继续播放。
若SDP参数切换前后都需要编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP需要TC，并且当前也正在使用TC，则使用原有TC和音元资源继续播放，不修改放音元文件。
若SDP参数切换前后都不需要编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP不需要TC，并且当前也未使用TC，则 当前的流程保持不变。
若SDP参数切换前无编解码，切换后有编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP需要TC，并且当前不在使用TC，则可以首先申请TC资源，拆除RTP和TONE之间的接续(此时用户面的放音通道保持不释放)，接续RTP和TC，接续TC和TONE；再通知用户面控制进程；然后用户面控制进程可以通知TONE放音通道；最后放音通道切换到新的码型(G.711与网元内部A/U律一致)的音元文件，且可计算得到切换码型之前播放的时间，从切换码型开始使用新的码型播放。
若SDP参数切换前有编解码，切换后无编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP不需要TC，并且当前在使用TC，则可以拆除RTP和TC之间的接续，拆除TC和TONE之间的接续(用户面的放音通道保持不释放)，释放TC资源，接续RTP和TONE；再通知用户面控制进程；然后用户面控制进程可以通知TONE放音通道；最后放音通道切换到新的码型的音元文件，且可通过计算得到切换码型之前播放的时间，从切换码型开始使用新的码型播放。
本实施例通过在所述媒体网关进行放音后，若检测到当前的SDP的参数发生改变时，则获取与所述SDP的参数发生改变时对应的音元文件，使得本公开实施例在呼叫放音终端发生SDP切换时，可以及时对应修改呼叫放音的编解码信息，从而达到呼叫放音终端的音元文件可以继续播放。
可选地，基于所述第一至第三任一实施例，在本公开呼叫放音控制方法的第六实施例中，参照图10，在上述S30之后，所述呼叫放音控制方法还包括S60。
在S60中，在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。
在本公开实施例的放音过程中，若收听端发生了主动AMR速率调整，多媒体网管可自动识别收听端AMR速率调整，并且可以立即切换到新的AMR速率上继续播放。
在媒体网关加载了AMR调整前后不同速率集的音库的情况下，语音资源模块可识别收听端RTP发送的速率调整报文，并进行分析处理。当识别到发生AMR速率调整时，用户面语音放音通道自行切换到新的AMR速率上，且可重新计算得到切换码型之前播放的时间，从切换码型开始使用新的码型播放。并通知用户面的控制进程AMR速率发生变化，用户面的控制进程对放音统计信息进行修改。若调整后的AMR速率对应的音元未加载，则语音放音通道自动播放G.711码型的音元进行播放。
本实施例通过在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。当放音收听端所在的无线信号弱，宽带小的情况下，可以在进行AMR编解码放音时请求降低播放的速率，从而保证放音的质量。
参照图11，图11为本公开呼叫放音控制装置的第一实施例的功能模块示意图。
在本实施例中，所述呼叫放音控制装置包括：接收模块10、第一获取模块20和选择模块30。
所述接收模块10，设置为接收携带音包信息的呼叫放音请求；
在本实施例中，媒体网关中的接收模块10接收到服务器发送的携带音包信息的呼叫放音请求，请求该媒体网关向放音收听端放音。该音包信息可以包含放音业务参数，如URL地址。
所述第一获取模块20，设置为根据所述呼叫放音请求，获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；
在接收到该呼叫放音请求后，基于H.248协议，根据该呼叫放音请求，媒体网关中的第一获取模块20获取已制作并已加载完成的、与该音包信息关联的音元列表信息、编解码信息及音元编号信息，并获取用户面语音资源。
所述选择模块30，设置为根据所述音元列表信息、所述编解码信息及所述音元编号信息，选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。
在获取到该音元列表信息、编解码信息及音元编号信息后，基于该媒体网关中的H.248协议进行TC资源分析和接续处理，使得该媒体网关中的用户面语音模块的电路接通。在该用户面语音模块的电路接通后，该用户面语音模块根据该音元列表信息、编解码信息及音元编号信息选择对应的音元文件进行播放。
基于该媒体网关中的H.248协议，对G.711码型放音环节的改造可以包括：放音流程改造；多种停放音流程改造；收号流程改造；多种停收号流程改造；上下文资源分析流程和接续拆续分析和处理流程改造，以支持以下场景的接续和TC资源分析：
场景1：G.711码型的放音流程为：RTP的码型为G.711，TONE采用G.711码型的音元，与网关内部A/U律一致；
场景2：G.711放音+TC方式收号流程改造为：RTP的码型为G.711，TONE采用G.711码型的音元，与网关内部A/U律一致；
场景3：压缩码型放音流程改造为：RTP的码型为压缩码型，TONE采用G.711码型的音元，与网关内部A/U律一致；
场景4：压缩码型放音+TC方式收号流程改造为：RTP的码型为压缩，TONE 采用G.711码型的音元，与网关内部A/U律一致。
基于该媒体网关中的H.248协议，对其他压缩码型放音环节的改造可以包括：放音流程改造；多种停放音流程改造；收号流程改造；多种停收号流程改造；上下文资源分析流程和接续拆续分析和处理流程改造，以支持以下场景的接续和TC资源分析：
场景1：压缩码型放音流程为：RTP的码型与TONE的码型一致的场景；
场景2：放音+TC方式收号流程为：RTP的码型任意，TONE采用G.711码型的音元，与网关内部A/U律一致；其中，如果RTP的码型不是G.711，不收号。
需要说明的是，当没有加载压缩码型的音库时，如果需要放音，可以统一采用默认的G.711码型的音元进行放音。
本实施例通过接收模块10接收携带音包信息的呼叫放音请求，第一获取模块20根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息，选择模块30根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件。
由于在云计算平台的媒体网关放音业务使用中，根据接收到的呼叫放音请求，该媒体网关可以直接输出放音需要的码型数据流到RTP处理模块，不在虚拟机内进行码型的转换处理，使得媒体网关可以直接通过音元寻址获取到对应的音元文件，并播放该音元文件，可节省编解码转换资源，该方法可加快放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而可提高物理硬件平台的资源利用率。
可选地，本公开呼叫放音控制装置的第二实施例中，参照图12，所述第一获取模块20可包括查询单元21和获取单元22。
所述查询单元21，设置为根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息；
在本实施例中，根据该呼叫放音请求，查询并获取与该呼叫放音请求携带的音包信息关联的放音标识信息、语言类型及所述编解码信息，该放音标识信息可以包括呼叫放音配置参数，该解编码信息可以包括编解码参数和音元ID等。
所述获取单元22，设置为根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。
在获取到该与该呼叫放音请求携带的音包信息关联的放音标识信息和语言类型后，基于该媒体网关中的H.248协议，查询该与该放音标识信息、语言类型对应的音元列表信息，并申请用户面语音资源，该音元列表信息存储的是多个编解码音元索引地址。
本实施例通过根据所述呼叫放音请求，查询与所述音包信息关联的放音标 识信息、语言类型及编解码信息，并根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。由于该音元列表信息是一个检索表格，记录了每个音元文件的音元地址，而该音元编号信息是记录该音元列表信息每个音元地址的存储顺序，因此可以使得媒体网关能够快速的获取到呼叫放音的音元地址，从而可加快放音效率。
可选地，在本公开呼叫放音控制装置的第三实施例，参照图13，所述选择模块30可包括第一确定单元31和第二确定单元32。
所述第一确定单元31，设置为根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址；
在本实施例中，在获取到音元列表信息、音元编号信息后，结合与该呼叫放音请求关联的编解码信息，确定该呼叫放音与获取的音元文件的音元地址。
所述第二确定单元32，设置为根据所述音元地址确定所述音元文件。
不同类型的音元文件对应不同类型的编解码信息，因此用户面放音需要根据不同类型的编解码信息包含的编解码参数和音元ID来索引音元地址，为此，可以建立两级索引，需要为每种编解码(如：AMR速率等)建立一个对应的音元索引数组，根据码型信息索引该种码型的音元地址，该索引表需要占用用户面一定的内存空间。
用户面放音时音元文件寻址处理，即在获取到该音元地址后，根据该音元地址确定该音元文件，以供该媒体网关向放音收听端播放该音元文件。
本实施例通过根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址，根据所述音元地址确定所述音元文件，使得媒体网关直接通过音元寻址获取到对应的音元文件，并播放该音元文件，而可以无需在呼叫放音时进行码型转换处理，可节省编解码转换资源，该方法可加快放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而可提高物理硬件平台的资源利用率。
可选地，在本公开呼叫放音控制装置的第四实施例，参照图14，所述呼叫放音控制装置还可以包括：加载模块40。
所述加载模块40，设置为加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息。
在本实施例中，在输入标准的.wav格式的音元文件后，如G.711编解码(A/U律)类型的音元文件，通过转换为二进制文件格式，根据不同的编解码输出不同压缩码型的语音净荷信息文件；该转换按照一定规则，对生成的不同编解码(如G.729//EVRC/GSM_FR/…等)的音元文件进行组织。
将编解码的音库文件加载到该媒体网关主音管理任务中/进程中。根据用户 的选择需要加载的音元(可以指定是否过滤已加载音元)；从网管-＞语音任务(主)发起请求，语音任务(主)进入加载状态；语音任务(主)通过FTP连接到网管服务端，获取需要加载的文件大小，并获取需要加载的文件到本地的语音进程(主)；语音任务(主)更新本地的音元配置信息，并做持久化的保存；语音任务(主)对批量保存的音元文件上报下载的进度；当所有的待加载的编解码音元处理完成后，上报处理完成的响应。
需要说明的是，语音进程(主)与用户面语音进程/语音进程(备)校验与同步，包含以下的处理步骤：
用户面语音进程/语音进程(备)上电处理：用户面语音进程/语音进程(备)在上电时，读取语音配置信息和音元编号信息并加载；用户面语音任务/语音任务(备)定期比较加载的配置信息和音元编号信息(包括是否存在，且大小、时间、CRC信息等一致比较)，并删除不一致的信息；向语音任务(主)发起音校验请求并收到响应；用户面语音进程/语音进程(备)音元发起校验：语音进程(主)定期向语音任务(主)发送通信状态正常的模块信息；语音任务(主)开音元校验使用的数据区；语音任务(主)进行本地保存收到用户面语音进程/语音进程(备)上电后发起音校验请求；语音任务(主)在空闲态的情况下发起语音校验；当某个模块的语音校验完成后判断是否还有待校验的模块，如果存在则语音任务(主)主动或定时发起语音轮循校验。
用户面语音进程/语音进程(备)音元校验过程：语音任务(主)发起语音校验；进入音元同步态；用户面语音任务/语音任务(备)收到语音校验后保存语音任务(主)信息并获取音元配置信息与本地音元配置信息进行比较；发现不一致的信息后通过FTP从语音进程(主)重新获取语音元文件，修改本地的语音配置信息并持久化保存；批量处理完不一致的数据后上报进度给语音任务(主)；当所有音元检查请求完成后，语音任务(主)进入空闲态。
同时，用户面增加对音内存管理组织方式，即对生成的不同编解码(如G.729//EVRC/GSM_FR/…等)的音元文件进行组织。首先使用两个队列(节点方式均动态申请和释放)，例如，音元文件队列及空闲块队列。其中，音元文件队列，用于管理插入的音元文件；空闲块队列，用于管理空闲内存块。
在分配内存时，可以找到一个比所要求尺寸条件的空闲内存块稍大的目标内存块，将该目标内存块分裂为第一子目标内存块和第二子目标内存块，第一子目标内存块的大小为所要求的尺寸大小，第二子目标内存块的大小为该目标内存块的大小去除第一子目标内存块的大小后的剩余大小。产生新的文件队列节点，指向第一子目标内存块的的内存，并将该文件节点链入文件队列。将空闲结点指向第二子目标内存块的内存。此外，本领域技术人员应该理解，当可以找到一个完全符合所要求容量条件的空闲内存块，则该空闲节点就不需要了，可以将该空闲节点释放掉。
在用户面内存释放时，找到需要释放的内存对应的文件节点，并检查文件节点指向的内存，如果该文件节点指向的内存的相邻两侧内存均为空闲内存，则将相邻两侧的空闲内存和该文件节点指向的内存进行合并。并用一个新的空闲节点指向该合并的内存，即新的空闲节点链入空闲节点队列，则分别指向该相邻两侧的空闲节点释放，同时，释放文件节点。如果仅该文件节点指向的内存一侧为空闲内存，则将本内存和该一侧的空闲内存进行合并；如果该文件节点指向的内存的相邻两侧的内存均不空闲，则产生一个新的空闲节点管理该文件节点指向的内存。
在用户面内存紧缩时，即当共享内存中的空闲碎片过多，虽然总的空闲容量能满足一个音元的记录，但是没有一个单一的碎片能容纳音元的记录，则需要内存紧缩。内存紧缩实际就是内存移位，即将有文件的内存向前拷贝，空闲内存合并到一起。
本实施例通过加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息，使得媒体网关直接通过音元寻址获取到对应的音元文件，并播放该音元文件，而不需要在呼叫放音时进行码型转换处理，节省了编解码转换资源，该方法加快了放音效率，减少虚拟机对CPU等硬件资源的占用，提升物理机运行的虚拟机数量，从而提高了物理硬件平台的资源利用率。
可选地，基于上述第一至第三任一实施例，在本公开呼叫放音控制装置的第五实施例中，参照图15，所述呼叫放音控制装置还包括：第二获取模块50。
所述第二获取模块50，设置为在所述媒体网关进行放音后，若检测到当前的会话描述协议SDP的参数发生改变时，则获取与所述SDP的参数发生改变时对应的音元文件。
在本实施例中，在放音过程中，当放音终端发生SDP切换(如：SDP中的放音编解码等参数修改)，可及时对应修改放音参数，达到放音终端的音元文件可以继续播放。
若SDP参数切换前后都需要编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP需要TC，并且当前也正在使用TC，则使用原有TC和音元资源继续播放，不修改放音元文件。
若SDP参数切换前后都不需要编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP不需要TC，并且当前也未使用TC，则当前的流程保持不变。
若SDP参数切换前无编解码，切换后有编解码。在SDP切换流程中，如果 放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP需要TC，并且当前不在使用TC，则可以首先申请TC资源，拆除RTP和TONE之间的接续(此时用户面的放音通道保持不释放)，接续RTP和TC，接续TC和TONE；再通知用户面控制进程；然后用户面控制进程可以通知TONE放音通道；最后放音通道切换到新的码型(G.711与网元内部A/U律一致)的音元文件，且可以计算得到切换码型之前播放的时间，从切换码型开始使用新的码型播放。
若SDP参数切换前有编解码，切换后无编解码。在SDP切换流程中，如果放音流程判断当前正在放音或正在放音和收号，则采用新SDP编解码参数对是否需要TC进行重新分析。如果分析结果为新的SDP不需要TC，并且当前在使用TC，则可以拆除RTP和TC之间的接续，拆除TC和TONE之间的接续(用户面的放音通道保持不释放)，释放TC资源，接续RTP和TONE；再通知用户面控制进程；然后用户面控制进程可以通知TONE放音通道；最后放音通道切换到新的码型的音元文件，且可以通过计算得到切换码型之前播放的时间，从切换码型开始使用新的码型播放。
本实施例通过在所述媒体网关进行放音后，若检测到当前的SDP的参数发生改变时，则获取与所述SDP的参数发生改变时对应的音元文件，使得本公开实施例在呼叫放音终端发生SDP切换时，可以及时对应修改呼叫放音的编解码信息，从而达到呼叫放音终端的音元文件可以继续播放。
可选地，基于上述第一至第三任一实施例，在呼叫放音控制装置的第六实施例中，参照图16，所述呼叫放音控制装置还包括：
所述第三获取模块60，设置为在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。
在本公开实施例的放音过程中，若收听端发生了主动AMR速率调整，本公开可以自动识别收听端AMR速率调整，并且可切换到新的AMR速率上继续播放。
在媒体网关加载了AMR调整前后不同速率集的音库的情况下，语音资源模块识别对端RTP处理模块发送过来的速率调整报文，并进行分析处理。当识别到发生AMR速率调整时，用户面语音放音通道自行切换到新的AMR速率上，且可以重新计算下切换码型之前播放的时间，从切换码型开始使用新的码型播放。并通知用户面的控制进程AMR速率发生变化，用户面的控制进程对放音统计信息进行修改。若调整后的AMR速率对应的音元未加载，则语音放音通道可以自动播放G.711码型的音元进行播放。
本实施例通过在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。当 放音收听端所在的无线信号弱，宽带小的情况下，在进行AMR编解码放音时请求降低播放的速率，从而保证放音的质量。
基于上述实施例，本公开实施例七还提供了一种非暂态计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述呼叫放音控制方法。
基于上述实施例，本公开实施例八还提供了一种电子设备。参照图17所示，该电子设备可以包括：
处理器(processor)710和存储器(memory)720；还可以包括通信接口(Communications Interface)730和总线740。
其中，处理器710、存储器720和通信接口730可以通过总线740完成相互间的通信。通信接口730可以用于信息传输。处理器710可以调用存储器720中的逻辑指令，以执行上述实施例的呼叫放音控制方法。
此外，上述的存储器720中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开实施例所述方法的全部或部分步骤。而前述的存储介质可以是非暂态存储介质，包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质，也可以是暂态存储介质。
最后需要说明的是，本领域普通技术人员可理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来执行相关的硬件来完成的，该程序可存储于一个非暂态计算机可读存储介质中，该程序在执行时，可包括如上述方法的实施例的流程，其中，该计算机可读存储介质可以为磁碟、光盘、只读存储记忆体(ROM)或随机存储记忆体(RAM)等。
以上仅为本公开的可选实施例，并非因此限制本公开的专利范围，凡是利用本公开说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本公开的专利保护范围内。
工业实用性
本公开实施例通过公开的呼叫放音控制方法实现在云计算平台的媒体网关 放音业务使用中，该媒体网关可以出放音需要的码型数据流到RTP处理模块，可以不在虚拟机内进行码型的转换处理，可节省编解码转换资源，并加快放音效率，减少虚拟机对CPU等硬件资源的占用，从而提高了物理硬件平台的资源利用率。

Claims (13)

  1. 一种呼叫放音控制方法，包括：
    媒体网关接收携带音包信息的呼叫放音请求；
    根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；以及
    根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫编解码器TC资源分析和接续处理后向放音收听端播放所述音元文件。
  2. 如权利要求1所述的呼叫放音控制方法，其中，所述根据呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息包括：
    根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息；以及
    根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。
  3. 如权利要求1所述的呼叫放音控制方法，其中，所述根据音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件包括：
    根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址：以及
    根据所述音元地址确定所述音元文件。
  4. 如权利要求1所述的呼叫放音控制方法，在所述媒体网关接收携带音包信息的呼叫放音请求之前，还包括：
    加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息。
  5. 如权利要求1-3任一项所述的呼叫放音控制方法，在所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件之后，还包括：
    在所述媒体网关进行放音后，若检测到当前的会话描述协议SDP的参数发生改变时，则获取与所述SDP的参数发生改变时对应的音元文件。
  6. 如权利要求1-3任一项所述的呼叫放音控制方法，在所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件之 后，还包括：
    在所述媒体网关进行放音后，若检测所述放音收听端的自适应多速率编解码AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。
  7. 一种呼叫放音控制装置，包括：
    接收模块，设置为接收携带音包信息的呼叫放音请求；
    第一获取模块，设置为根据所述呼叫放音请求获取与所述音包信息关联的音元列表信息、编解码信息及音元编号信息；以及
    选择模块，设置为根据所述音元列表信息、所述编解码信息及所述音元编号信息选择对应的音元文件，以供所述媒体网关在进行呼叫编解码器TC资源分析和接续处理后向放音收听端播放所述音元文件。
  8. 如权利要求7所述的呼叫放音控制装置，其中，所述第一获取模块包括：
    查询单元，设置为根据所述呼叫放音请求，查询与所述音包信息关联的放音标识信息、语言类型及编解码信息；以及
    获取单元，设置为根据所述放音标识信息及所述语言类型获取所述音元列表信息及所述音元编号信息。
  9. 如权利要求7所述的呼叫放音控制装置，其中，所述选择模块包括：
    第一确定单元，设置为根据所述音元列表信息、所述编解码信息及所述音元编号信息确定音元地址；以及
    第二确定单元，设置为根据所述音元地址确定所述音元文件。
  10. 如权利要求7所述的呼叫放音控制装置，还包括：
    加载模块，设置为在所述媒体网关接收携带音包信息的呼叫放音请求之前，加载已进行编解码处理的所述音元文件对应的所述音元列表信息、所述编解码信息及所述音元编号信息。
  11. 如权利要求7-9任一项所述的呼叫放音控制装置，还包括：
    第二获取模块，设置为在所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件之后，以及
    在所述媒体网关进行放音后，若检测到当前的会话描述协议SDP的参数发生改变时，则获取与所述SDP的参数发生改变时对应的音元文件。
  12. 如权利要求7-9任一项所述的呼叫放音控制装置，还包括：
    第三获取模块，设置为在所述根据音元列表信息、所述编解码信息选择及所述音元编号信息对应的音元文件，以供所述媒体网关在进行呼叫TC资源分析和接续处理后向放音收听端播放所述音元文件之后，以及
    在所述媒体网关进行放音后，若检测所述放音收听端的所述AMR速率发生改变时，则获取到与所述AMR速率发生改变时对应的音元文件。
  13. 一种非暂态计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1-6任一项的呼叫放音控制方法。
PCT/CN2016/108113 2015-12-25 2016-11-30 呼叫放音控制方法及装置 WO2017107750A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510989342.5A CN106921609A (zh) 2015-12-25 2015-12-25 呼叫放音控制方法及装置
CN201510989342.5 2015-12-25

Publications (1)

Publication Number Publication Date
WO2017107750A1 true WO2017107750A1 (zh) 2017-06-29

Family

ID=59089015

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/108113 WO2017107750A1 (zh) 2015-12-25 2016-11-30 呼叫放音控制方法及装置

Country Status (2)

Country Link
CN (1) CN106921609A (zh)
WO (1) WO2017107750A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632249B (zh) * 2018-03-26 2020-12-08 厦门亿联网络技术股份有限公司 一种用于VoIP开发调试的codec解包实现方法及装置
CN112735486B (zh) * 2020-12-22 2022-07-15 重庆德科电子仪表有限公司 一种基于a-law算法的音频播放方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1750571A (zh) * 2005-10-28 2006-03-22 武汉市中光通信公司 一种适用于ip媒体服务器的媒体处理系统
CN101674207A (zh) * 2009-10-21 2010-03-17 中兴通讯股份有限公司 测试播放方法及媒体网关mgw
US20120213340A1 (en) * 2011-02-17 2012-08-23 Shiping Li Systems and methods for playing recorded announcements

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1750571A (zh) * 2005-10-28 2006-03-22 武汉市中光通信公司 一种适用于ip媒体服务器的媒体处理系统
CN101674207A (zh) * 2009-10-21 2010-03-17 中兴通讯股份有限公司 测试播放方法及媒体网关mgw
US20120213340A1 (en) * 2011-02-17 2012-08-23 Shiping Li Systems and methods for playing recorded announcements

Also Published As

Publication number Publication date
CN106921609A (zh) 2017-07-04

Similar Documents

Publication Publication Date Title
US10097884B2 (en) Media playback method, client and system
CN102006368B (zh) 基于移动终端记忆卡缓存技术的流媒体音频文件播放方法
US20170094435A1 (en) Audio playing method, apparatus, and system for multiple playing devices
CN107911361B (zh) 支持多会话的语音管理方法、装置、终端设备及存储介质
US20150281308A1 (en) Method and system for downloading and playing media file, client, server, and storage medium
JP7353497B2 (ja) 能動的に対話の開始を提起するためのサーバ側処理方法及びサーバ、並びに能動的に対話の開始が提起できる音声インタラクションシステム
US9866604B2 (en) Progressive download playback
US9288657B2 (en) Control domain change based on network registration condition
CN107395742A (zh) 基于智能音箱的网络通信方法以及智能音箱
CN110831092A (zh) Pdu会话管理、节点关联和upf发现的方法及设备
WO2017107750A1 (zh) 呼叫放音控制方法及装置
WO2018171548A1 (zh) 一种解码方法、终端以及计算机可读存储介质
WO2018041096A1 (zh) 媒体服务器调度方法、装置、系统及存储介质
WO2019061636A1 (zh) 调用系统工具的方法、装置、可读存储介质及设备
JP6549261B2 (ja) アプリケーション実装方法およびサービスコントローラ
CN111210826B (zh) 语音信息处理方法、装置、存储介质和智能终端
CN112084210A (zh) 数据处理方法、装置、电子设备及存储介质
CN109842590A (zh) 一种查勘任务的处理方法、装置及计算机可读存储介质
CN114640657A (zh) 多注册中心的融合方法、装置
US20230146871A1 (en) Audio data processing method and apparatus, device, and storage medium
CN113949739B (zh) 跨设备播放方法、装置、电子设备及存储介质
WO2015192451A1 (zh) 音频播放方法及装置
WO2016107178A1 (zh) 彩铃的播放方法及装置
WO2013000212A1 (zh) 实现终端接入集群业务的方法、终端和基站
WO2013189335A2 (zh) 一种彩信转发方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16877561

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16877561

Country of ref document: EP

Kind code of ref document: A1