Abstract:
Providing interoperability on a voice communication network by detecting incompatible bit packing payload formats of ADPCM encoded voice data signals in an encoder/decoder. A mismatch of bit packing formats between little endian format and big endian format is determined through the use of a media gateway control protocol package called Real Time Protocol that allows a Call Agent to detect the presence of garbled audio and allows an intelligent gateway to detect the payload format being used by remote endpoints during call setup procedures and then switch the gateway&#39;s encoding for the payload to the payload format being used by the remote endpoint. The invention may be applied to an ITU G.726 encoder/decoder.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     None  
       FIELD OF THE INVENTION  
       [0002]     The present invention relates to using a call flow for detecting and resolving interoperability problems between a single voice codec using different payload formats. The invention can be applied to ITU G.726 interoperability issues.  
       BACKGROUND OF THE INVENTION  
       [0003]     In typical telecommunications systems, voice calls and data are transmitted by carriers from one network to another network. Networks for transmitting voice calls include packet-switched networks transmitting calls using voice over Internet Protocols (VoIP), circuit-switched networks like the public switched telephone network (PSTN), asynchronous transfer mode (ATM) networks, etc. Recently, voice over packet (VOP) networks are becoming more widely deployed. Many incumbent local exchange and long-distance service providers use VoIP technology in the backhaul of their networks without the end user being aware that VoIP is involved.  
         [0004]     An example of networks and components for a VoIP call is illustrated in  FIG. 1 . The diagram shows a communication network that could be any managed network accessing the Internet such as an packet network with IP protocols, Asynchronous Transfer Mode (ATM), or Ethernet network. The communications network comprises a router  14  connected to various customer premise equipment and to media gateway  12 . Media gateway  12  must be capable of detecting changing resource or network conditions. The ability to detect and monitor changing resource and network conditions can result in significant cost reductions and/or improved quality. Router  14  is connected to Internet Access Device (IAD)  16 , wireless access point (AP)  22 , and/or IP PBX (personal branch exchange)  23 . A voice call may be placed between any of the customer equipment phones  18  connected to IAD  16 , wireless IP phone  24  connected to AP  22 , or IP PBX phone  30  and POTS (plain old telephone system) phone  32 . Using special software, calls could also be placed through computer  20  connected to IAD  16  or portable computer  26  connected to AP  22 .  
         [0005]     Customer equipment is connected through access broadband network  28  to the Internet  34  by media gateway  12 . On the far end is the PSTN  48  connected to POTS phone  52  through a Central Office  50 . PSTN  48  is also connected to the Internet  34  through a trunk gateway, composed of signal gateway  46 , media gateway controller/proxy (MGC)  32 , and trunk media gateway (MG)  42 . IP and packet data (e.g., real time protocol (RTP packet data)) associated with the call is routed between IAD  16  and trunk MG  42 . The trunk gateway system provides real-time two-way communications interfaces between the IP network (e.g., the Internet) and the PSTN  48 . As another example, a VoIP call could be initiated between WIPP  24  and WIPP  40  connected to AP  38 . In this call, voice signals and associated packet data are sent between MG  12  and MG  48  through Internet  34 , thereby bypassing the PSTN  48  altogether.  
         [0006]     Factors that affect voice quality in a VoIP network are fairly well understood. The level of control over these factors will vary from network to network. This is highlighted by the differences between a well-managed small network enterprise verses an unmanaged network such as the Internet. Network operational issues affect network performance and will create conditions that affect voice quality. These issues include outages/failures of network switches, routers, and bridges; outages/failure of VoIP elements such as call servers and gateways; and traffic management during peak periods and virus/denial of service attacks.  
         [0007]     Interoperability between VoIP systems is a critical ingredient of high-quality VoIP systems. There are many software and hardware devices in a VoIP system that must be implemented in order to reach the quality of carrier-class systems. The most important software features include echo cancellation, voice compression, packet play-out software, tone processing, fax and modem support, packetization, signaling support, and network management. New networking technologies and deployment models are also causing additional challenges that affect the ability of VoIP service providers to guarantee the highest levels of service quality (e.g., toll quality) in their deployments. Two such examples are where the VoIP service provider does not control the underlying packet transport network, and the use of packet networks with potentially high delay and loss, such as in 802.11 WLAN (Wireless Local Area Network) technology.  
         [0008]     A problem affecting the interoperability of VoIP systems, and hence the quality of voice systems, is a problem with interoperability between two widely-used but incompatible packing formats for Real-time Protocol (RTP) loads when using ADPCM. Adaptive Differential Pulse-Code Modulation (ADPCM) is a widely-used coding technique for digital communications over a computer network that uses a method of predictive coding to achieve data reduction. An advantage of ADPCM is a bit rate reduction by the use of an adaptive scale factor and quantizing according to a fixed quantization curve. The result of the incompatible packing formats is garbled audio when a caller implements one of the formats and a receiver implements the opposing format.  
         [0009]     One standard is the ITU-T standard G.726, titled “40, 32, 24, 16 kbit/s ADAPTIVE DIFFERENTIAL PULSE CODE MODULATION (ADPCM),” describes an algorithm for conversion of a single 64 kbit/s A-law or mu-law PCM channel encoded at 8,000 samples/s to and from a 40, 32, 24, or 16 kbit/s channel. The conversion is applied to the data stream using ADPCM transcoding methods. The G.726 data rates of 40, 32, 24, and 16 kbit/s have codewords of 5, 4, 3, and 2 bits, respectively, and are described as G726-40, G726-32, G726-24, and G726-16. Samples for G.726 encoding must be packed into octets using “little endian” ordering. Big endian or little endian packing methods indicate packing bytes in a certain order according to what bytes are most significant or least significant. Big endian systems sequence bits where the most significant bit in a sequence is stored at the lowest, or first, storage address, whereas in a little endian format the least significant bit in the sequence is stored first.  
         [0010]     For G.726 the 4-bit code words must be packed into octets wherein the first code word is packed in the four LSBs of the first octet and with the LSB of the code word in the LSB of the octet. The second code word is placed in the four MSBs of the first octet, with the MSB of the second code word packed into the MSB of the octet. The packing of code words continues in this manner with the first code word of each pair of words placed in the least significant four bits of the octet, and so forth.  
         [0011]     The “little endian” method for packing samples into octets in the G726-16, -24, -32, and -40 formats for RTP payloads is the same packing method that is specified in ITU-T Recommendation X.420 for packing ADPCM samples into octets. IETF adopted this format for G72640, -32, -24, -16 RTP payloads.  
         [0012]     The opposing packing format is the ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport that specifies big-endian format for the same. This has resulted in interoperability problems in the VoIP industry as many vendors have adopted the AAL2 format for RTP payloads too.  
         [0013]     The revised AVT-RTP-Profile (RFC 3551) has attempted to resolve this issue by discontinuing the use of payload type “2” for G726-32 and has recommended the use of dynamic RTP payload type. Also for the I.366.2 (Annex E) format a new MIME subtypes of AAL2-G726-16, -24, -32, -40 are specified and MIME registration of the same is expected to happen soon. This probably can solve the problem in some implementations going forward, however, interoperability with installed base of VoIP devices is not ensured.  
         [0014]     G726-32 with dynamic payload is likely to indicate that the payload conforms to IETF specification, however, there is nothing that prevented use of dynamic payload for G726-32 in older implementations. Thus, in many older implementations the type of payload format cannot be determined remotely. Moreover G726-16, -24, and -40 have always used dynamic payloads, so relying on payload alone can result garbled audio.  
         [0015]     A gateway compliant with RFC 3551 and implanting G.726 can probably support G726-XX as well as AAL2-G726-XX payload formats. However, when the gateway&#39;s SDP contains G726-XX alone, there is no way for gateway to determine the payload format conclusively. For some signaling protocols, it may be possible to indicate support for both payload formats. However, there is no method for an existing gateway to determine if the payload format of a remote gateway negotiates using only G726 as described above.  
         [0016]     One solution for ADPCM interoperability is proposed in the IETF&#39;s RFC 3551 standard “RTP Profile for Audio and Video Conferences with Minimal Control,” by Schulzrinne, H. and Casner, S. (July, 2003). RFC 3551 has only solved the issue for interoperability among future systems, as far as currently existing systems in the field are concerned the gateways can not determine the payload format conclusively. Clearly, there is a need for gateway to determine the G.726 payload format conclusively to prevent garbled audio output when it encounters non-complaint systems.  
       SUMMARY  
       [0017]     To overcome the drawbacks of the prior art, the present invention solves the problem of G.726 ADPCM interoperability of different bit packing methods used in payload formats. by For signaling protocols such as MGCP/MEGACO one can define a package such that Call-Agent when ITU G.726 is used as a codec and can facilitate the bit packing format verification by briefly putting the remote connection in netwtest mode or continuity test mode so that a gateway supporting this package can easily determine the format used by remote.  
         [0018]     The preferred method uses an MGCP Package such that a Call Agent can facilitate bit packing format verification of either G.726 bit endian or little endian payload formats. An advantage to the invention is that it provides seamless interoperability for VoIP systems using G.726 protocols with that have legacy systems using ML2-G726-XX payload formats, and vice-versa.  
         [0019]     The present invention uses a call flow that Call Agents can employ to allow endpoints to detect G726 interoperability problem and allow intelligent implementations to resolve the problem. There are two incompatible G726 payload formats that are in use today. Recent implementations support both payload formats and are identified by different MIME subtypes, however interoperability with existing gateways in the field is not ensured. The call flow described in the preferred embodiment uses a basic MGCP package called G726, which will allow a Call Agent to detect the presence of garbled audio and allows an intelligent gateway to detect the payload format being used by remote endpoints during call setup procedure and switch it&#39;s encoding for the payload to the one being used by remote.  
         [0020]     It may be desirable to indicate the capability to interoperate with any G726 implementation using the call flow proposed here. This can be accomplished by defining an empty package, for e.g. “G726”, with no signals or events. This document also defines a general purpose media descriptor (gpmd) parameter called “endian” which can be registered with IANA which will allow Call Agent/Gateways to identify the payload format in some cases. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0021]     For a better understanding of the nature of the present invention, its features and advantages, the subsequent detailed description is presented in connection with accompanying drawings in which:  
         [0022]      FIG. 1  is a diagram of a packet network using voice over Internet Protocols (VoIP);  
         [0023]      FIG. 2  is a network diagram illustrating gateway devices implementing the signaling protocol of the preferred embodiment;  
         [0024]      FIG. 3  is a flowchart diagram using signaling to determine ADPCM interoperability between an originating intelligent gateway and a terminating legacy gateway;  
         [0025]      FIG. 4  is a flowchart diagram using signaling to determine ADPCM interoperability between an originating legacy gateway and a terminating intelligent gateway. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0026]     The present invention provides a system and method for interoperability between the RTP payload formats using ITU G.726 encoding method using little endian ordering for ADPCM and the RTP payload formats specified in ITU-T I.366.2 Annex E for ATM AAL2 transport that uses big endian ordering. A system for the preferred embodiment for is represented in the network diagram of  FIG. 2 . The diagram depicts a network used for placing a call using voice over Internet Protocol (VoIP) between IP phone  54  at one end and IP phone  66  at the other end. IP phone accesses the Internet  60  through Internet Access Device (IAD)  56  and media gateway  58 . IAD  56  may be any device used for accessing the Internet such as a modem, T1/T5 line, etc., as is known in the art. Gateway  58  is a gateway implementing ADPCM protocols with voice data samples packed into octets using little endian methods in the G.726-16, -24, -32, or 40 payload formats specified consistent with ITU X.420 recommendations.  
         [0027]     On the other end of the network, IP phone  66  accesses the Internet  60  through Internet Access Device (IAD)  64  and media gateway  62 . IAD  64  may be any device used for accessing the Internet such as a modem, T1/T5 line, etc., as is known in the art. Gateway  62  is a gateway implementing ADPCM protocols with voice data samples packed into octets using big endian methods for RTP payload formats in the ITU I.366.2 Annex E standards for ATM AAL2 transport.  
         [0028]     In this section, we provide two example call flows using RTP package defined in [5] to achieve G.726 interoperability with an existing implementation which uses unknown G.726 payload format. The first one illustrates the case where the originating side is the intelligent gateway with the ability to determine the G.726 payload format and take corrective action, and the terminating side is legacy implementation. The second one is for the case when originating side is legacy gateway which is using unknown payload format for G726. The basic idea is to use the continuity test capability available in gateways that support the RTP package, and then intelligent gateways could decide if it needs to switch G726 payload format for call to succeed. Note that there is no need to indicate this capability or to define a new event to indicate the success. A dumb gateway that can not switch the payload format when the need arises or when continuity tests fails, is a hint for call agent to either drop the call or use some other encoding method. When the continuity test passes, the Call Agent proceeds with normal call flow procedure, and do not need to know the payload format details.  
         [0029]     Referring to  FIG. 3 a  flowchart diagram demonstrates the preferred method for using signaling to determine ADPCM interoperability between intelligent originating gateway  58  and legacy terminating gateway  62 . A Call Agent may reside in originating gateway  58  or a network device connected to gateway  58  on the originating end of a call. A call is setup  68  between originating intelligent gateway  58  and terminating legacy gateway  62 . The call setup messages are as follows:  
                                                             #   GW-o   CA   GW-t                                1   &lt;−   CRCX (M:recvonly)           2   200 (sdp-o)   −&gt;       3       CRCX (M:netwtest, S:, R:, sdp-o)   −&gt;       4       &lt;−   200 (sdp-t)       5   &lt;−   MDCX (M:sendrecv, S:r/co1,                      R:r/co1, S:rt, sdp-t)       6   200   −&gt;       7   NTFY (O:co1)   −&gt;       8   &lt;−   200       9       MDCX (M:sendrecv, S:rg)   −&gt;       10        &lt;−   200       11         (Normal operations follow)                  
 
         [0030]     In the first step  70  the Call Agent in originating gateway  58  issues a CreateConnection command to terminating gateway  62  instructing it to use G726-32 media encoding upon receiving an off-hook notification using the following messages:  
         [0031]     CRCX 100 aaln/1@gw-o.somewhere.net MGCP 1.0  
         [0032]     C: 1  
         [0033]     L: a:G726-32, p:20  
         [0034]     M: recvonly  
         [0035]     In the next step  72  the gateway acknowledges the command and includes SDP with following codec information:  
         [0036]     200 100 OK  
         [0037]     I:1  
         [0038]     v=0  
         [0039]     o=−25678 753849 IN IP4 10.0.34.121  
         [0040]     s=− 
         [0041]     c=IN IP4 10.0.34.121  
         [0042]     t=0 0  
         [0043]     m=audio 30000 RTP/AVP 96  
         [0044]     a=rtpmap:96 G726-32/8000  
         [0045]     The messaging continues in step  74  with the Call Agent issuing a CreateConnection command to the terminating gateway  64  instructing gateway  64  to use G726-32 media encoding (with an unknown payload format) and the connection mode is netwtest. The following messaging is used for the command:  
         [0046]     CRCX 200 aaln/1@gw-t.somewhere.net MGCP 1.0  
         [0047]     C: 2  
         [0048]     L: a:G726-32, p:20  
         [0049]     M: netwtest  
         [0050]     v=0  
         [0051]     o=−25678 753849 IN IP4 10.0.34.121  
         [0052]     s=− 
         [0053]     c=IN IP4 10.0.34.121  
         [0054]     t=0 0  
         [0055]     m=audio 30000 RTP/AVP 96  
         [0056]     a=rtpmap:96 G726-32/8000  
         [0057]     In the next step  76  the terminating gateway  62  sends back a success response to originating gateway  58  with its SDP which also includes capability information. The following messages are used to transmit the response:  
         [0058]     200 200 OK  
         [0059]     I:2  
         [0060]     v=0  
         [0061]     o=−25678 753849 IN IP4 10.10.10.1  
         [0062]     s=− 
         [0063]     c=IN IP4 10.10.10.1  
         [0064]     t=0 0  
         [0065]     m=audio 20000 RTP/AVP 2  
         [0066]     In step  78  the Call Agent in turn transmits a ModifyConnection command to the originating gateway  58  and this time the command includes the request for event co1 and applies signal co1 (optionally duration can be specified) on the connection using the following messaging:  
         [0067]     MDCX 101 aaln/1@gw-o.somewhere.net MGCP 1.0  
         [0068]     C: 1  
         [0069]     I: 1  
         [0070]     M: sendrecv  
         [0071]     X: a1  
         [0072]     R: r/co1@1  
         [0073]     S: rt, r/co1@1  
         [0074]     v=0  
         [0075]     o=−25678 753849 IN IP4 10.10.10.1  
         [0076]     s=− 
         [0077]     c=IN IP4 10.10.10.1  
         [0078]     t=0 0  
         [0079]     m=audio 20000 RTP/AVP 2  
         [0080]     After receiving the command in step  78 , the originating gateway  58  acknowledges the command  80 . The acknowledgement is sent with the following message:  
         [0081]     200 201 OK  
         [0082]     At this point in the procedure, a call is established  82  is using G726-32 encoding where the terminating side is in loopback mode netwtest. Once a call is established  82 , originating gateway  58  can employ any capable mechanism to verify the voice path or determine the payload format being used by terminating gateway  62 . The Call Agent should allow sufficient time before giving up on event “co1” notification, and when none received, it can be assumed that the terminating gateway  62  has failed to verify the voice path in loopback mode, and can optionally specify timeout, and request events such as “oc/” (operation complete).  
         [0083]     Thus, in step  84  originating gateway  58  determines the payload format in use by terminating gateway  62 . Since originating gateway  58  is an intelligent gateway, after determining a mismatch with the format for the “dumb” legacy gateway  62 , gateway  58  changes its own payload format  86  such that it is able to establish two way voice path with the terminating gateway  62  using encoding method G726-32. Originating gateway  58  then generates the notification for event co1 using the following messages:  
         [0084]     NTFY 1001 aaln/1@gw-t.somewhere.net MGCP 1.0  
         [0085]     O: r/co1@1  
         [0086]     X: a1  
         [0000]     The Call Agent acknowledges the Notify command using the message:  
         [0087]     200 1001 OK  
         [0088]     After acknowledgement of the Notify command, the Call Agent then instructs  88  terminating gateway  62  to ring the phone  66  and changes the connection mode to sendrecv. The following messages are used for step  88 :  
         [0089]     MDCX 201 aaln/1@gw-t.somewhere.net MGCP 1.0  
         [0090]     C: 2  
         [0091]     I: 2  
         [0092]     M: sendrecv  
         [0093]     R: rg  
         [0094]     X: b2  
         [0095]     The terminating gateway  62  acknowledges the commands sent in  88  by the Call Agent with the acknowledgement message:  
         [0096]     200 201 OK  
         [0097]     After the acknowledgement message is received by the Call Agent, the normal call flow can proceed  90 . Terminating gateway  6  would eventually notify the call agent about an off-hook event, which will result in Call Agent stopping the ringback tone on the originating side. Once the ringback tone is stopped on the originating side, a two-way voice path is established between phone  54  and phone  66 .  
         [0098]     By employing the preferred embodiment in a communication network using ADPCM encoding for voice data signals, the possibility of call rejection or garbled speech will be eliminated and call completion rate would improve for encoding methods such as ITU G.726.  
         [0099]      FIG. 4  illustrates a flowchart diagramming steps of an alternative embodiment for providing interoperability between two networks that use different bit packing formats for ADPCM-encoded voice data signals. Instead of providing payload format detection on the originating side, the alternative embodiment provides payload format detection support on the legacy, or “dumb,” leg of an IP call. In the alternative embodiment, the originating gateway  58  is assumed to be a legacy device that has an unknown payload format for encoding G.726 and cannot detect payload formats from other devices on the network nor change its own payload format. The terminating side  62  is the intelligent gateway that has the ability to detect G.726 format.  
         [0100]     The call setup procedure  92  is enacted using the following messaging:  
                                                             #   GW-o   CA   GW-t                                1   &lt;−   CRCX (M:recvonly)           2   200 (sdp-o)   −&gt;       3       CRCX(M:sendrecv, sdp-o)   −&gt;       4       &lt;−   200 (sdp-t)       5   &lt;−   MDCX(M:netwtest, S:rt)       6       RQNT(R:r/co1, S:r/co1)   −&gt;       7       &lt;−   200       8       &lt;−   NTFY (O:r/co1)       9       200   −&gt;       9       RQNT(S:rg)   −&gt;       10        &lt;−   200       11         (Normal operations follow)                  
 
         [0101]     After call setup, the payload format for the currently transmitted voice data is determined  94  by the terminating gateway  62  and upon off-hook notification. If there is a mismatch between the payload format in the terminating gateway  62  and originating gateway  58 , then terminating gateway  62  switches to a compatible payload format  96 . The normal call flow follows  98  where the ringback tone on the originating side  58  is stopped and the connection put in sendrecv mode for a two way-voice call to be established between phones  54  and  66 .  
         [0102]     One skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration and not limitation, and the present invention is limited only by the claims that follow.