WO2007006206A1

WO2007006206A1 - A method for detecting and releasing abnormal media gateway rtp resource

Info

Publication number: WO2007006206A1
Application number: PCT/CN2006/001461
Authority: WO
Inventors: Kezhi Qiao; Wenhua Zhu
Original assignee: Zte Corporation
Priority date: 2005-07-14
Filing date: 2006-06-26
Publication date: 2007-01-18
Also published as: CN1897622A; CN101142796A; CN1897622B

Abstract

A method for detecting and releasing abnormal media gateway RTP resource comprises: the media gateway monitors the time when each RTP port receives the media packets, if a RTP port doesn’t receive any media packets during the pre-set time, the media gateway transmits a notification message indicating the RTP port is failure to the softswitch. If the call corresponding to the RTP port at the softswitch is absent, the softswitch returns a response message indicating the call is absent, after receiving the response message, the media gateway closes the RTP port and releases the corresponding call resource. If the call corresponding to the RTP port at the softswitch is present, the softswitch returns a normal response message, after receiving the response message, the media gateway continue performs last step. The present invention can detect and release abnormal RTP resource in time, prevent the abnormal RTP port from continuously transmitting the media stream to the other media gateways in the network.

Description

Method for detecting and releasing abnormal real-time transmission protocol resources of media gateway

The present invention relates to the field of Next Generation Network (NGN) technology, and specifically relates to a method for detecting and releasing a Real Gateway Protocol (RTP) resource of a Media Gateway (MG). Background technique

Softswitch and Media Gateway (MG) are the core devices in the Next Generation Network (NGN). Softswitch mainly performs key functions such as call control, media gateway access control, resource allocation, protocol processing, routing, authentication, and accounting, and provides basic voice services, multimedia services, mobile services, and diversified third-party services to users. The establishment, transmission and release of the voice media stream are implemented under the control of Softswitch.

1 is a schematic diagram of networking of a prior art softswitch and media gateway system. As shown in FIG. 1, the softswitch controls the media gateway to complete the call process through a MEGAC0 (Media Gateway Control) protocol or a MGCP (Media Gateway Control Protocol) protocol. After the user A on the media gateway MG1 and the user B on the MG2 make a call to establish a call, an RTP port is established on the MG1 for encoding the voice of the user A into an RTP media stream, and is sent to the MG2 via the packet switching network; The RTP port resource also decodes and restores the RTP media stream from user B on MG2 to voice to user A. MG2 implements the call in the same way as MG1, so that User A and User B can realize two-way intercommunication of voice.

2 is a schematic diagram of a process of establishing a call by a prior art softswitch control media gateway. As shown in FIG. 2, when user A on MG1 calls user B on MG2, the steps include:

Step 201: User A picks up the phone on MG1, and MG1 reports the soft switch.

Step 202: The softswitch requires the MG1 to release the audible tone and receive the number for the user A;

Step 203: The user on the MG1 dials the number and reports the extracted number to the softswitch.

Step 204: The softswitch sends a command to the MG1 to allocate an RTP resource to the user A for processing the RTP media stream.

Step 205: The softswitch sends a command to the MG2 to request the user B to ring, and allocates an RTP resource to the user B for processing the RTP media stream.

Step 206: The softswitch sends a command to the MG1, requesting to release the ring tone to the user A, and modifying the RTP. The properties of the port;

Step 207: User B on the MG2 picks up the phone and enters the call.

Step 208: The softswitch stops the ringback tone of the user A of the MG1, and modifies the RTP port to the transceiver mode.

Step 209, user A on MG1 hangs up;

Step 210: The softswitch sends a release message to user A on MG1, and MG1 releases user A and RTP resources to stop the processing of the media stream.

Step 211, the user B on the MG2 hangs up;

Step 212: The softswitch sends a release message to the user B on the MG2, and the MG2 releases the user B and the RTP resource to stop the processing of the media stream.

It can be seen from the process that when the step 210- or step 212- is performed, if the release message sent by the softswitch is lost, or the softswitch does not send the message to the media gateway due to some abnormality, the RTP resource on the gateway is not Will be released, that is, the channel is still in the state of receiving and receiving media streams, and the resource is always occupied. If too many abnormal RTP resources are not released, the RTP resources on the media gateway will be exhausted, and new calls will not be established. On the other hand, the abnormal RTP resources still continue to send media streams through the packet network to the other side media gateway. , affecting the performance of the network, and affecting the normal progress of new calls on the RTP port corresponding to the other side of the media gateway.

Therefore, it is necessary to have a mechanism between the media gateway and the softswitch to detect and release the RTP resources in an abnormal situation in time.

For abnormal RTP resources, the traditional approach is to manually release the abnormal RTP resources and release them manually. The other method is to periodically query the call status of the media gateway through softswitch, and release abnormal RTP resources in time. Both of these methods have imperfections. On the one hand, the abnormal RTP resources appearing simultaneously on the media gateway and the softswitch cannot be detected and released in time. On the other hand, the timing query increases the correspondence between the softswitch and the media gateway. The interaction load affects the performance of softswitches and media gateways. Invention disclosure

The technical problem to be solved by the present invention is to provide a method for detecting and releasing abnormal real-time transmission protocol resources of a media gateway, so that RTP resources can be correctly and automatically released, and when abnormal RTP resources are simultaneously present on the media gateway and the soft switch, detection and freed. The invention adopts the following technical solutions:

A method for detecting and releasing an abnormal real-time transmission protocol resource of a media gateway, comprising:

A. The media gateway monitors the situation that each real-time transport protocol port receives the media packet, and if the real-time transport protocol port does not receive the media packet, the media gateway sends a notification message that the real-time transport protocol port is abnormal to the softswitch within the set time. ;

B. If the call of the real-time transport protocol port corresponding to the softswitch does not exist, the softswitch responds with a response message indicating that the call does not exist, and after receiving the response message, the media gateway closes the real-time transport protocol port, releasing the relevant If the call corresponding to the real-time transport protocol port exists on the softswitch, the softswitch responds to the normal response message, and after receiving the response message, the media gateway continues to perform step 8.

The step A also includes the softswitch sending a monitoring message to the media gateway.

The monitoring message includes monitoring an event descriptor of each of the real-time transport protocol ports to receive the media packet and the set time value.

The notification message in the step A includes the following fields: an endpoint identifier of the real-time transport protocol port, a call identifier, and an event descriptor for monitoring each real-time transport protocol port to receive the media packet.

The media gateway reports the real-time transport protocol port exception to the softswitch in an event-triggered manner. The method further includes: if the steps A and B are repeatedly performed for a certain number of times, a real-time transport protocol port does not receive the media packet media gateway to close the real-time transport protocol port in the presence of the call, releasing the relevant The call resource sends a request message indicating the call exit to the soft switch, and after receiving the request message, the soft switch releases the corresponding call resource.

The invention enables automatic detection when the RTP resource cannot be correctly released due to abnormal network and signaling processing between the media gateway and the softswitch, and can be automatically released without manual intervention, and when an abnormal RTP resource occurs simultaneously on the media gateway and the softswitch. And release. BRIEF DESCRIPTION OF THE DRAWINGS

1 is a schematic diagram of networking of a prior art softswitch and media gateway system;

2 is a schematic diagram of a process of establishing a call by a prior art softswitch control media gateway;

3 is a flow chart of detecting, by the present invention, an abnormal RTP resource;

4 is a schematic diagram of a signaling process implemented by the present invention using the MEGAC0 protocol. The best way to implement the invention

The present invention will be further described in detail below with reference to the accompanying drawings and embodiments:

The MEGACO protocol is the 3525 protocol of the IETF. It adopts the idea of a separate gateway. The gateway that processes the original signaling and media is decomposed into two parts: the media gateway and the soft-wire softswitch control the action of the MG through the MEGACO protocol, and the softswitch sends the MG to the MG. The command to be executed, the MG executes and returns the result, and the softswitch also processes the event request that the MG actively reports. The logical relationship in the MEGACO protocol is represented by the connection model. The two most basic components in the connection model are associations and endpoints, and the associations represent the connections and topological relationships between the endpoints. The MEGACO protocol describes different business attributes through a package, which can be extended according to the needs of the business.

The main commands between the softswitch and the MG include SERVICECHA GE (registration), ADD (addition), MODIFY (modification), SUBTRACT (delete), NOTIFY (notification), and so on. 3 is a flow chart of the present invention for detecting the release of abnormal RTP resources, and FIG. 4 is a schematic diagram of the signaling process implemented by the present invention using the MEGACO protocol. The present invention will be described in detail below with reference to FIGS. First define a MEGACO protocol extension package RTTOang, which describes the event hang that detects that the RTP port is hanged, and defines a parameter hangtime for the hang event, which is used to specify how long the media packet is not received. The RTP port is hanged.

Step 401: After the call is established, the softswitch sends a MODIFY command to the RTP endpoint of the incoming call on the MG to detect the RTP port media stream reception condition (step 301), and the MODIFY command includes an event descriptor, and the event description The event includes the event that the RTP endpoint did not receive the media packet for a long time during the call, and how long does it take to trigger the MG to report the event to the softswitch without receiving any media packet. The form of signaling can be as follows:

MEGAC0/1 [123. 123. 123. 4] : 2944

Transaction = 9999 {

Context = 789 {

Modify = RTP0001 {

Events = 2222 {RTPHang/hang (hangtime=60) }

} } }

RTP0001 is the name of the endpoint; RTPHang/hang detects the event that the media stream is not received for a long time; hangtime indicates that no media stream is received within the duration of 60 seconds, and the MG needs to softswitch Report the incident.

Step 402: After receiving the MODIFY command, the MG starts to continuously detect that the RTP endpoint has not received the media packet for a long time (step 302). When the media packet is received within the set time period of the softswitch during the call, the process proceeds to step 301 to periodically detect that the RTP endpoint has not received the media packet for a long time. However, if no media packet is received within the duration set by the softswitch, the MG considers that the RTP port may be suspended and prepares to report the softswitch event to the softswitch using the NOITFY command (step 303). The NOTIFY command contains the ID ID of the RTP endpoint, the association ID, and the event name for which the media pack was not received for a long time. The form of signaling can be as follows:

MEGAC0/1 [124. 124. 124. 222] : 2944 Transaction = 10000 {

Context = 789 {

Notify = RTP0001 {ObservedEvents =2222 {

20050605T22000000: RTPHang/hang} }

} }

RTP0001 is the ID of the endpoint, 789 in Context II 789 is the association ID, and RTPHang/hang is the event name that has not received the media packet for a long time.

Step 403: The softswitch receives the event, determines whether the association ID and the call where the endpoint ID is present (step 304), and if yes, responds to the MG with a normal success response; if soft If the exchange finds that the call with the association ID and the endpoint ID does not exist on the softswitch, the response message to the MG includes an error that the call does not exist. The form of signaling can be as follows:

MEGAC0/1 [123. 123. 123. 4] : 2944 Reply = 10000 {

Context = 789 {Notify = RTP0001 {Error=600 {} } } }

Where Eiror=600 indicates that the association 789 and the endpoint RTP0001 no longer have their calls on the softswitch.

After receiving the response signaling of the softswitch, the MG performs step 301 if the response is a successful response, and continues to detect an event that does not receive any media stream for a long time. If the response returned by the softswitch is a response that the call does not exist, then the The RTP port releases all resources of the call including the RTP port (step 305), and the flow ends here.

In step 404, the MG continuously detects that no media stream has been received for a long time, and repeats 402) ~~403) about ten times, as shown by 402' and 403 in FIG. Each time the soft exchange is reported, the event is soft The switch returns to the MG's successful response, that is, if no media packet is received for a long time in the presence of the call, the call corresponding to the RTP port on the soft switch is also hanged. The MG directly closes the RTP port, releases all resources of the call including the RTP port, and sends the resource to the softswitch.

SERVICECHANGE command, the command contains the association ID, the endpoint ID, and the identity of the outgoing call: Method is F0RCED. The form of signaling can be as follows:

MEGAC0/1 [124. 124. 124. 222] : 2944 Transaction = 19998 {

Context = 789 {

ServiceChange = RTP0001 {Services {

Method=F0RCE}

} } }

The softswitch immediately releases its own call resource upon receipt of the command (step 306).

While the invention has been illustrated and described with reference to the embodiments of the present invention, it will be understood by those skilled in the art that various forms and details may be practiced without departing from the scope and spirit of the invention. Obvious modifications. For example, due to the similarity between the MEGAC0 protocol and the MGCP protocol, the substance of the technical solution of the method is equally applicable to the use of the MGCP protocol. All changes and modifications may be made without departing from the spirit and scope of the invention. Industrial applicability

The technical solution of the present invention can effectively detect and release abnormal RTP resources in time; prevent abnormal RTP ports from continuously sending media streams to other media gateways on the network, thereby affecting network performance and normal on other corresponding ports of the media gateway. The problem of calling overcomes the shortcomings of the prior art that manual intervention is required when the RTP resource cannot be correctly released, and when the abnormal RTP resources are simultaneously present on the media gateway and the softswitch, the detection and release cannot be performed.

Claims

Claim

A method for detecting and releasing an abnormal real-time transmission protocol resource of a media gateway, comprising the steps of:

2. The method for detecting and releasing an abnormal real-time transmission protocol resource of a media gateway according to claim 1, wherein before step A, the softswitch further sends a monitoring message to the media gateway.

3. The method for detecting and releasing an abnormal gateway real-time transmission protocol resource of a media gateway according to claim 2, wherein the monitoring message comprises an event descriptor for monitoring a media packet received by each real-time transport protocol port, and the setting Time value.

The method for detecting and releasing a media gateway abnormal real-time transmission protocol resource according to claim 1 or 3, wherein: the notification message in the step A includes the following fields: an endpoint identifier of the real-time transport protocol port, The call identifier and the event descriptor for monitoring each of the real-time transport protocol ports to receive the media packet.

The method for detecting and releasing the abnormal real-time transmission protocol resource of the media gateway according to claim 1, wherein the media gateway reports the real-time transmission protocol port abnormality to the softswitch in an event-triggered manner. .

6. The method for detecting and releasing an abnormal gateway real-time transmission protocol resource of a media gateway according to claim 1, further comprising: if the steps A and B are repeatedly executed for a specific number of times, a real-time transport protocol port is If the media packet is still not received, the media gateway closes the real-time transport protocol port, releases the relevant call resource, and sends a request message indicating the call exit to the softswitch. After receiving the request message, the softswitch releases the corresponding message. Call resources.