WO2007131421A1

WO2007131421A1 - A method and device for playing the playback sound of failure

Info

Publication number: WO2007131421A1
Application number: PCT/CN2007/001385
Authority: WO
Inventors: Haiyong Chen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-04-28
Filing date: 2007-04-25
Publication date: 2007-11-22
Also published as: CN101047985A

Abstract

A method and device for playing the playback sound of failure. The method comprises: in the process of setting up the call, the network device having detected the failure of the call analyses the failure reason, generates the playback sound of failure according to the failure reason determined by itself, and transmits the said playback sound of failure to the preceding device of setting up the call. And the device comprises: a call receiving module for receiving the call request; a failure analysis module for detecting a call failure and analyzing the failure reason; and a playback sound of failure module for generating the corresponding playback sound of failure according to the failure reason. The method and device in the invention can assure the accuracy of the playback sound of failure.

Description

Method and device for failing to play

Technical field

The present invention relates to the field of communications, and more particularly to a method and apparatus for failing to play. Background of the invention

In the case of using the Internet Protocol (IP) bearer, call setup may fail due to number analysis failure or call restriction. The call failure is a broad concept, which means that the caller cannot be connected normally, or the call setup is abnormal. If such a failure occurs, a failed playback is required to the user terminal that initiated the call. 1 is a flow chart of a failed playback in the prior art, including: Step 101: A caller places a call to a called party.

In this step, the caller can place a call indicating that the call has not failed on the calling device.

Step 102: The called party detects that the call fails, analyzes the current call failure, and returns a failure notification message to the calling party, where the failure notification message includes a failure status code and a failure cause value.

Step 103: After receiving the failure notification message, the calling party performs a failed playback to the user terminal according to the rules set by itself.

It should be noted that a call setup process may involve a large number of network devices, where the calling party and the called party refer to not a fixed device, but a relative concept. For example, a device that issues a call request 1 (hereinafter referred to as device A) is referred to as a calling party; with respect to device A, a device that receives a call request 1 (hereinafter referred to as device B) is referred to as a called party. If device B is not the end device established by the call, after processing the received call request 1, device B will place a call to its backward device (hereinafter referred to as device C). Seek 2. At this time, with respect to device C, device B is the calling party that made the call request 2. As shown in Figure 1, in the existing failed playback strategy, the caller performs a failed playback based on the failure status code and the failure cause value returned by the called party.

For example, in the specification of the 3rd Generation Partnership Project (3GPP2), the Session Initial Protocol (SIP) incoming, the SIP outgoing abnormality, or the called paging response appear before In case of abnormality, the SIP trunk can inform the calling party through the SIP status code or the cause value in the ISDN User Part (ISUP) message, and the calling party performs the playback according to the above information.

However, if the called party detects the call failure, the returned information, such as the SIP status code and the cause value in the ISUP message, does not adequately reflect the true cause of the failure. That is to say, the caller cannot perform the failed playback only by the above information. Furthermore, the caller's failed playback does not support personalization well. Summary of the invention

The invention provides a method and a device for failing to play, and the main technical solutions are as follows: A method for failing to play, the method comprising:

During the call setup process, the network device detecting the failed call analyzes the failure reason, generates a failed playback according to the failure reason determined by itself, and sends the failed playback to the forward device established by the call.

A failed playback device, the device comprising:

a call receiving module, configured to receive a call request;

A failure analysis module, configured to detect a call failure and analyze the cause of the failure;

The failed playback module is configured to issue a corresponding failed playback according to the failure reason. It can be seen from the above technical solution that the method and device for failing to play the sound of the present invention are The failed playback is sent to the forward device of the call setup to ensure the accuracy of the failed playback. BRIEF DESCRIPTION OF THE DRAWINGS

1 is a flow chart of a failed playback in the prior art;

2 is a flow chart of a method for failing to play in an embodiment of the present invention;

3 is a flow chart of failed playback in the first embodiment of the present invention;

4 is a flow chart of failed playback in a second embodiment of the present invention;

Figure 5 is a flow chart showing the failure of playback in the third embodiment of the present invention;

6 is a flow chart of failed playback in a fourth embodiment of the present invention;

Figure 7 is a schematic illustration of a failed playback device in accordance with one embodiment of the present invention. Mode for carrying out the invention

The contents of the present invention will be described in detail below with reference to the accompanying drawings.

As shown in FIG. 2, the method for playing a call when the call fails is as follows: Step 201: The first network device sends a call request to the second network device, where the call request may be an Invite message or the like.

The first network device may also be referred to as a calling party, and the second network device may also be referred to as a called party. Step 202: The second network device detects that the call fails, analyzes the reason for the failure, and performs a failed playback according to the true failure reason.

Among them, the real reasons for failure include failures in the succession of the tandem office and failures in the landed office.

The failures that occur when the tandem office is connected include: an Invite message exception, a Locreq return failure, a called call restriction, a called busy, a called shutdown, a called number routing failure, Temporary failure of the switch.

The failures in the called office include: Invite message exception, called call restriction, paging no response, switch temporary failure, switching device congestion, network failure, and the like.

In addition, the called party can set personalized failed playback for different operators according to actual needs.

Step 203: The second network device sends a failed playback to the first network device.

In this step, if the bearer between the calling party and the called party has not been established, the called party will establish a bearer between the calling party and the calling party through the signaling interaction, and send the failed voice to the calling party through the bearer, and the bearer is placed in the failure. After the tone is sent, remove it.

Step 204: The first network device sends the failed playback generated by the second network device to the user terminal.

Optionally, the second network device may also send a failure notification message to the first network device, where the failure notification message carries a failure status code, a failure cause value, and the like.

As seen from the above description, in this embodiment, the first network device that detects the call failure and has the sound-discharging capability performs a failed playback to ensure the accuracy of the playback. The network device may be a gateway or a landing. The present invention is not limited. Further, different network settings can be set for different operators in the network device to implement personalized settings.

3 is a flow chart of the failed playback in the first embodiment of the present invention. This specific example only shows a part of the network devices in the call setup process, and the network devices involved in the actual application are not limited thereto.

Step 301: A Softswitch-based Mobile Switching Center emulation (MSCe), hereinafter referred to as MSCel, processes the Invite message after receiving the Invite message of the game. The Invite message carries the SDP-4 and may also carry an IAM message packet. In the process of processing the Invite message, if no abnormality is found, the MSCel sends a Locreq message to the HLR. The subsequent procedure can refer to 3GPP2 X.S0025, which is not mentioned here, that is, there is no call failure in the MSCel.

If an abnormal situation occurs, such as a number analysis failure or a call restriction, enter the call failure processing flow, and go to step 302.

Step 302: The MSCel sends an Add message to the Media Gateway (MGGW), requesting the MGW to establish an IP endpoint 5 according to the RTP protocol.

The mode of the IP endpoint 5 is SendOnly, and the media information of the remote endpoint is SDP-4. Step 303: The MGW feeds back response information to the MSCel, where the response information includes SDP-5 information of the IP endpoint 5.

Step 304: The MSCel sends a 183 message to the peer, where the 183 message carries the SDP-5 information of the IP endpoint 5, and is used to establish a bearer between the IP endpoint 5 and the remote endpoint.

In this step, the MSCel may also send a 180 message to the opposite office. Of course, in order to avoid making the game mistakenly think it is ringing, it is preferable to use the 183 message.

Step 305 306: After receiving the P ACK message of the remote endpoint, the MSCel sends

200 response.

Steps 307~308: The bearer is established between the calling party and the called party, and the MSCel sends a MOD message to the MGW, and receives the MOD response of the MGW, and the playback starts. At the same time, MSCel starts the Tone Complete Timer and waits for the playback to end.

In this step, MSCel will perform a failed playback based on the actual failure reason. Further, different playback schemes can be set for different operators.

After steps 307-308, the case of step 309a may occur, and the case of step 309b may also occur.

Step 309a: Before the Tone Complete Timer times out, the MGW sends a NOTIFY message to the MSCel, and the MSCel feeds back the NOTIFY REPLY message. Go to step 310.

Step 309b: The playback end timer expires, and step 310 is performed.

Step 3 10~31 1: MSCel sends a SUBTRACT message to the MGW, requesting to delete the IP endpoint 5, and the MGW feeds back the SUBTRACT response.

Step 312 3 13 : MSCe l generates a failure cause value, and sends a non-2XX message carrying the failure cause value to the opposite office, and the game feedback ACK response, and the failed playback process ends.

4 is a flow chart of the failed playback in the second embodiment of the present invention, including:

After receiving the Invite message of the game, the MSCel sends a Locreq message to the HLR. If the Locreq message does not indicate an abnormal situation, the subsequent procedure can refer to 3GPP2 X.S0025, and details are not described herein.

If the Locreq message indicates that an abnormal situation occurs, the call fails, and the MSCel actively performs the playback. The specific procedure is the same as steps 302 to 313.

Figure 5 is a flow chart of the failed playback in the third embodiment of the present invention, including:

The MSCel sends an Invite message to the MSCe2, which carries the SDP-4 and may also carry the IAM message packet.

MSCe2 processes the received Invite message. If there is no abnormality, MSCe2 sends a 180 or 183 message to the MSCel, which can carry the ACM message packet, and the subsequent procedure is consistent with 3GPP2 X.S0025.

If an abnormal situation occurs, such as the routing of the called number fails, perform a process similar to steps 302~3.

6 is a flow chart of the failed playback in the fourth embodiment of the present invention, including: Step 601: MSCe2 issues a page to the BS.

After that, MSCe2 waits for the BS to return a response. If MSCe2 receives the paging response from the BS, the subsequent procedure is consistent with 3GPP2 X.S0025. If the paging is abnormal, such as paging timeout, etc., a flow similar to steps 302 to 3 13 is performed. The IP network may perform the flow of step 602 606 while MSCe2 is waiting for BS feedback. It should be noted that the interaction process of the MSCe2 and the BS, and the processes of steps 602 to 606 may be two processes that do not affect each other.

Step 602: After receiving the 18x message of the MSCe2, the MSCel sends an 18x message to the opposite office.

Step 603: The office sends a PRACK message to the MSCel as a response to the 18x message sent by the MSCel.

Step 604: The MSCel sends a PRACK message to the MSCe2 as a response to the 18x message sent by the MSCe2.

Step 605 606: MSCe2 sends a 200 for PRACK response to the MSCel, and the MSCel sends a 200 for PRACK response to the opposite office.

In the specific example of FIG. 3 to FIG. 6, the network device that fails the call is detected, and the failed playback is performed according to the true failure reason, so that the accuracy of the failed playback can be ensured. Moreover, the method allows different playback schemes to be set for different operators to achieve personalization.

FIG. 7 is a schematic diagram of a failed playback device according to an embodiment of the present invention, including: a call receiving module 701, configured to receive a call request, where the call request may be an Invite message or the like.

The failure analysis module 702 is configured to determine whether a call failure occurs and determine the cause of the failure.

The voice recording module 703 is configured to store voice files corresponding to various real failure reasons. Further, the voice recording module 704 can store voice files corresponding to different operators, respectively.

The failed playback module 704 is configured to select a corresponding voice file according to the reason of the failure, perform a failed playback, and send the voice file to the sender of the call request.

Optionally, the device further includes a bearer establishing module, configured to establish a bearing between the calling party and the called party Load, and remove the bearer after the failed playback is completed.

Optionally, the apparatus further includes a failure notification module, configured to issue a failure notification message to the issuer of the call request.

In actual application, the failed playback device shown in Figure 7 can be set on any device of the IP network, such as a switch, etc., and when a call failure is detected, a failed playback is sent to the forward device established by the call.

Call setup is a process in which a network device triggers step by step. Therefore, the forward device for call setup refers to the network device of the previous level that the call is established before the call fails.

The above is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim

A method for failing to play, characterized in that the method comprises:

The method according to claim 1, wherein the generating a failed playback according to the failure reason determined by itself comprises: presetting a voice file corresponding to each failure reason, and selecting a corresponding voice file to fail play music.

The method according to claim 2, wherein the presetting the voice file corresponding to each failure reason comprises: setting different voice files for different operators.

The method according to claim 1, wherein the transmitting the failed forwarding to the forward device of the call setup comprises: establishing a bearer between the network device detecting the failed call and the forward device establishing the call , the playback is failed by the bearer transmission.

The method according to claim 4, wherein the network device that detects the call failure is the first softswitch-based mobile switching center MSCe, and the forward device established by the call is located in the call setup. a second MSCe in the previous stage of the MSCe, where the second MSCe is configured with a corresponding second endpoint;

The first MSCe interacts with the media gateway functional entity to establish a first endpoint corresponding to the first MSCe;

The first MSCe sends an 18X message to the second MSCe, where the 18X message carries the first endpoint SDP information;

The second MSCe establishes bearers of the first endpoint and the second endpoint according to the first endpoint SDP information.

The method according to claim 5, further comprising: the first MSCe starts to fail to play, and starts a playback timer;

If the playback end message of the media gateway function entity is received before the playback timer expires, the first MSCe deletes the first endpoint;

Otherwise, after the playback timer expires, the first endpoint is deleted.

The method according to claim 5, further comprising: the first MSCe generating a failure cause value according to the failure reason, and sending a non-2XX message carrying the failure cause value to the second MS Ce.

The method according to claim 5, wherein the establishing the first endpoint comprises: setting a mode of the first endpoint to SendOnly, and setting the remote media information to the second endpoint SDP information.

The method according to any one of claims 1 to 8, wherein the reason for the failure is: the tandem office fails to succeed.

10. The method according to claim 9, wherein the failure of the tandem office to succeed comprises at least one of the following:

Invite message exception, Locreq return failure, called call restriction, called busy, called shutdown, called number routing failure, switch temporary failure.

The method according to any one of claims 1 to 8, wherein the reason for the failure is: the called landing station fails.

12. The method according to claim 11, wherein the failure of the called landing station comprises at least one of the following:

Invite messages are abnormal, called call barring, paging no response, switch temporary failure, switching device congestion, network failure.

13. A failed playback device, the device comprising: a call receiving module, configured to receive a call request; A failure analysis module, configured to detect a call failure and analyze the cause of the failure;

The failed playback module is configured to issue a corresponding failed playback according to the failure reason.

14. The apparatus according to claim 13, wherein the apparatus further comprises a voice recording module for storing a failed playback corresponding to different failure causes.

The device according to claim 13, wherein the device further comprises a bearer establishing module, configured to establish a bearer between the call request sender and the receiver; and the failed play module is further configured to pass the bearer A failed playback is issued.

The device according to any one of claims 13 to 15, characterized in that the device further comprises a failure notification module, configured to generate a failure cause value according to the failure reason, and issue a failure notification message carrying the failure cause value. .