Abstract:
Methods, systems, and computer program products for establishing transcoding free connections between UMA and UMTS call legs are disclosed. According to one method, a media gateway determines whether codec configurations used by UMA and UMTS legs of a call are compatible. In response to determining that the configurations are compatible, media gateway determines whether rate control is necessary to establish a transcoding free connection. In response to determining that rate control is necessary, the media gateway issues rate control requests on the UMA and UMTS legs as appropriate. The media gateway determines whether the rate control requests are successful. In response to determining that the requests are successful, the media gateway establishes a transcoding free connection between the UMA and the UMTS legs of the call.

Description:
RELATED APPLICATIONS  
       [0001]     This application claims the benefit of a U.S. provisional patent application No. 60/759,596 entitled, “Methods, Systems, and Computer Program Products for Providing Transcoder Free Operation (TrFO) and Interworking Between Unlicensed Mobile Access (UMA) and Universal Mobile Telecommunications System (UMTS) Call Legs Using A Media Gateway”, filed Jan. 17, 2006; the disclosure of which is incorporated herein by reference in its entirety. 
     
    
     TECHNICAL FIELD  
       [0002]     The subject matter described herein relates to providing transcoder free operation and interworking between UMA and UMTS call legs. More particularly, the subject matter described herein relates to methods, systems, and computer program products for providing transcoder free operation and interworking between UMA and UMTS call legs using a media gateway.  
       BACKGROUND ART  
       [0003]     In voice communications networks, such as voice over IP networks, transcoding refers to converting from one type of voice compression to another. Transcoding is necessary when different legs of a call have incompatible coder/decoders (codecs); however, when the different legs of a call use compatible codecs, it is desirable to establish a transcoding free connection. Establishing a transcoding free connection is desirable because transcoding introduces delay and degrades voice quality. The terms “transcoder free” and “transcoding free” are used interchangeably herein to refer to the absence of transcoding in a connection.  
         [0004]     It may be desirable to establish a transcoder free connection when both legs of a call are UMTS. It may also be desirable to establish a transcoder free connection when at least one leg of a call is not UMTS. For example, it may be desirable to establish a transcoder free connection between a UMA call leg and a UMTS call leg. Third Generation Partnership Project (3GPP) Technical Standard TS 29.163 requires transcoder free operation when an IP multimedia media gateway (IM-MGW) is used to bridge a connection between an Nb and an Mb interface. An Mb interface is an interface between the media gateway and an access point in the UMA network. An Nb interface is an interface between the media gateway and another media gateway in the UMTS network.  
         [0005]     Although the above-referenced 3GPP standard indicates that transcoder free operation should be implemented by an IM-MGW, the technical standard fails to describe any hardware or software necessary to achieve such operation. Moreover, the technical standard omits many of the details required for transcoder free operation. For example, the technical standard fails to address timing issues with regard to rate control, redundancy reconciliation between the UMA and UMTS networks, and differences in packetization timing between the UMA and UMTS networks.  
         [0006]     Accordingly, in light of these difficulties, there exists a need for methods, systems, and computer program products for providing transcoder free operation and interworking between UMA and UMTS call legs using a media gateway.  
       DISCLOSURE OF THE INVENTION  
       [0007]     According to one aspect, the subject matter described herein includes a method for establishing a transcoding free connection between a UMA call leg and a UMTS call leg. The method includes determining whether UMA and UMTS call legs have compatible codecs. In response to determining that the UMA and UMTS call legs have compatible codecs, it is determined whether rate control is needed to establish a transcoding free connection. If it is determined that rate control is needed, at least one rate control request is issued from a media gateway to at least one of the UMA and UMTS call legs. Media streams from the UMA and UMTS call legs are monitored to determine whether the rate control is successful. In response to determining that the rate control is successful, a transcoding free connection is established in the media gateway between the UMA and UMTS call legs.  
         [0008]     The terms “call,” “session,” and “connection” are used interchangeably herein to refer to a path over which media communications are exchanged between UMA and UMTS nodes. Thus, a call, session, or connection that involves UMA and UMTS nodes may carry voice, video, non-voice audio, or any media communication between the nodes.  
         [0009]     The subject matter described herein for providing transcoder free operation and interworking between UMA and UMTS call legs using a media gateway may be implemented using hardware, software, firmware, or any combination thereof. In one implementation, the subject matter described herein can be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein include chip memory devices, disk memory devices, programmable logic devices, application specific integrated circuits and downloadable electrical signals. In addition, a computer program product that implements the subject matter described herein can be located on a single computing device or platform or may be distributed across multiple computing devices or platforms. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0010]     Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings:  
         [0011]      FIG. 1  is a network diagram illustrating a media gateway for providing interworking and transcoder free operation between a UMA network and a UMTS network according to an embodiment of the subject matter described herein;  
         [0012]      FIG. 2  is a flow chart illustrating exemplary steps for establishing a transcoder free connection between a UMA call leg and a UMTS call leg using a media gateway according to an embodiment of the subject matter described herein;  
         [0013]      FIG. 3  is a message flow diagram illustrating exemplary rate control requests that may be issued by a media gateway to establish a transcoder free connection between a UMA call leg and a UMTS call leg according to an embodiment of the subject matter described herein;  
         [0014]      FIG. 4  is a block diagram illustrating an exemplary internal architecture of a media gateway for establishing a transcoder free connection and for providing interworking between user plane protocols of UMA and UMTS call legs according to an embodiment of the subject matter described herein;  
         [0015]      FIG. 5  is a block diagram illustrating exemplary steps that may be performed by a media gateway in establishing an internal transcoder free connection for a call that includes a UMA leg and UMTS leg according to an embodiment of the subject matter described herein;  
         [0016]      FIG. 6  is a block diagram illustrating an alternate method for establishing a transcoder free connection in a media gateway for a call that has a UMA leg and a UMTS leg according to an embodiment of the subject matter described herein;  
         [0017]      FIG. 7  is a flow chart illustrating exemplary steps that may be performed by a media gateway in response to a codec mode request received from a UMA endpoint of a call including a UMA leg and a UMTS leg according to an embodiment of the subject matter described herein;  
         [0018]      FIG. 8  is a flow chart illustrating exemplary steps that may be performed by a media gateway in response to a rate control request received from a UMTS leg of a call including a UMTS leg and a UMA leg according to an embodiment of the subject matter described herein;  
         [0019]      FIG. 9  is a flow chart illustrating exemplary steps for redundancy reconciliation that may be performed by a media gateway for building redundancy on a UMA call leg based on packets received from a UMTS call leg according to an embodiment of the subject matter described herein;  
         [0020]      FIG. 10  is a flow diagram illustrating redundancy reconciliation for packets transmitted from a UMTS call leg to a UMA call leg according to an embodiment of the subject matter described herein;  
         [0021]      FIG. 11  is a flow chart illustrating exemplary steps for using redundant frames received on a UMA call leg to restore packets transmitted to a UMTS call leg according to an embodiment of the subject matter described herein;  
         [0022]      FIG. 12  is a flow diagram illustrating the use of UMA redundancy to transmit a lost frame to a UMTS call leg where the two call legs have the same packetization time according to an embodiment of the subject matter described herein; and  
         [0023]      FIG. 13  is a flow diagram illustrating exemplary steps for using UMA redundancy to transmit lost frames to a UMTS call leg when the two legs have different packetization times according to an embodiment of the subject matter described herein. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0024]      FIG. 1  is a block diagram illustrating a network including a media gateway for establishing a transcoder free connection between a UMA call leg and a UMTS call leg according to an embodiment of the subject matter described herein. Referring to  FIG. 1 , a media gateway  100  and a media gateway controller  102  are positioned between UMA network  104  and UMTS network  106 . Media gateway  100  interfaces with an access point (AP)  108  in the UMA network via the Mb interface. A UMA handset  110  may connect to media gateway  100  via access point  108 .  
         [0025]     Media gateway  100  interfaces with media gateway controller  102  via an Mn or Mc interface. Media gateway  100  and media gateway  102  exchange control and state information via the Mn or Mc interface. For example, media gateway controller  102  may issue MEGACO or MGCP call control commands to media gateway  100  via the Mn or Mc interface to control session setup, tear down, and maintenance.  
         [0026]     Media gateway  100  interfaces with UMTS network  106  via an lu interface and an Nb interface. More particularly, media gateway  100  connects to a radio network controller (RNC)  112  via the lu interface. Radio network controller  112  may control one or more base stations that allow a UMTS handset to initiate and terminate calls using media gateway  100 . Media gateway  100  connects with media gateway  114  via an Nb interface. Media gateway  114  may connect with one or more base station controllers  116  that allow UMTS handsets to connect to the network via an air interface.  
         [0027]     In the network illustrated in  FIG. 1 , it may be desirable to establish calls between UMA network  104  and UMTS network  106 . That is, a call may have a UMA leg that connects to UMA network  104  and a UMTS leg that connects to UMTS network  106 . If the codecs used by the different legs of the call are compatible, it may be desirable to establish a transcoder free connection using media gateway  100  in order to avoid packetization delay and to improve voice quality.  
         [0028]      FIG. 2  is a flow chart illustrating exemplary steps that may be used to establish a transcoding free connection between a UMA call leg and a UMTS call leg using media gateway  100  according to an embodiment of the subject matter described herein. Referring to  FIG. 2 , in step  200 , media gateway  100  identifies a codec configuration used by different legs of a UMTS-UMA connection. This step may be performed by analyzing call setup signaling messages used to initially establish the UMTS-UMA connection. For example, if call setup is performed using session initiation protocol (SIP), the initial codec used by each endpoint of a connection may be specified in the session description protocol (SDP) portion of each SIP call setup message.  
         [0029]     In step  202 , media gateway  100  determines whether the codec configurations of the call legs match. For example, this step may include determining whether both ends of the connection use the same type of codec, such as an adaptive modulation rate (AMR) codec. If it is determined that the codec configurations do not match, control proceeds to step  204  where the connection is set up with transcoding at the media gateway.  
         [0030]     In step  202 , if it is determined that the codec configurations match, control proceeds to step  206  where media gateway  100  identifies whether rate control needs to be issued. Rate control is required to be issued for compatible codecs if the encoding rate being transmitted by one side to the other side does not match the decoding rate being used by the receiving side. If the rates are the same, rate control does not need to be issued and control proceeds to step  208  where a transcoding free connection is set up in the media gateway. An exemplary media gateway architecture for establishing a transcoding free connection will be described in detail below.  
         [0031]     In step  206 , if it is determined that rate control requests need to be issued, control proceeds to step  210  where media gateway  100  issues rate control requests on the UMA and/or UMTS legs so that the rate sent by the UMA leg to the UMTS leg matches the receiving rate of the UMTS leg and so that the rate sent by the UMTS leg to the UMA leg matches the receiving rate of the UMA leg. In step  212 , media gateway  100  determines whether the rate control is successful. If rate control is not successful, control proceeds to step  204  where the connection in the media gateway is set up with transcoding. If the rate control is successful, control proceeds to step  208  where a transcoding free connection is set up in the media gateway.  
         [0032]      FIG. 3  is a message flow diagram illustrating exemplary steps that may be performed by media gateway  100  in issuing appropriate rate control as illustrated by step  210  in  FIG. 2 . Referring to  FIG. 3 , it is assumed that UMTS node  108  sends packetized voice information encoded at 12.2 kilobits per second and wants to receive packetized voice encoded at 7.95 kilobits per second. It is also assumed that UMA node  112  or  114  sends packetized voice information encoded at 10.2 kilobits per second and wants to receive packetized voice information encoded at 7.4 kilobits per second. Accordingly, in line  1  of the message flow diagram, media gateway  100  issues a rate control message to UMTS node  108  requesting that UMTS node  108  change its sending codec rate to 7.4 kilobits per second. In line  2  of the message flow diagram, MG  100  issues a codec mode request (CMR) to the UMA node requesting that the UMA node  112  or  114  change its sending codec rate to 7.95 kilobits per second. In line  3  of the message flow diagram, UMTS node  108  sends an acknowledgement message to media gateway  100  acknowledging that the sending codec rate has been changed to 7.4 kilobits per second. Media gateway  100  detects this fact and determines that rate control was successful on the UMTS side. Similarly, in line  3  of the message flow diagram, media gateway  100  detects packetized voice from UMA node  112  or  114  with a media stream encoded at 7.95 kilobits per second. After line  4 , media gateway  100  determines that the rate change was successful on the UMA side.  
         [0033]     Accordingly, after line  4 , media gateway  100  can establish a transcoding free connection between UMTS node  108  and UMA node  112  or  114 . In line  5  of the message flow diagram, UMTS node  108  sends packetized voice information to UMA node  112  or  114  via the transcoder free connection in media gateway  100 . Similarly, in line  6  of the message flow diagram, UMA node  112  or  114  sends packetized voice information to UMTS node  108 .  
         [0034]      FIG. 4  is a block diagram illustrating an exemplary internal architecture for media gateway  100  according to an embodiment of the subject matter described herein. Referring to  FIG. 4 , media gateway  100  includes a plurality of voice servers  400  for performing voice processing functions. In the illustrated example, each voice server module  400  includes a voice over packet chip  402 , a time slot interconnection (TSI)  404 , a CPU  406 , and a digital signal processor (DSP)  408 . Voice over packet chip  402  of each voice server module  400  includes voice over packet assembly and disassembly capabilities. For example, each voice over packet chip may implement real time transmission protocol (RTP), ATM adaptation layer 1, and ATM adaptation layer 2 for sending and receiving voice packets over IP or ATM networks. TSI  404  makes on demand connections between voice over IP chip channels, TDM matrix channels, and DSPs  408 . Each DSP  408  performs transcoding, echo cancellation, and other payload translation functions. Each DSP  408  may implement luUp and NbUp protocol stacks for interfacing with UMTS nodes. CPU  406  controls the overall operation of each voice server module  400 . Ethernet interfaces  410  connect each voice server module  400  to a packet switching fabric  412 . Packet switching fabric  412  may be any suitable type of switching fabric for switching packets between voice server module  400  and Ethernet interfaces  410 . Examples of switching fabrics suitable for use with embodiments with the subject matter described herein include ATM switching fabrics and Ethernet switching fabrics. In the examples described below, it will be assumed that packet switching fabric  412  comprises an Ethernet switching fabric.  
         [0035]     Media gateway  100  also includes broadband network interfaces  414  for connecting media gateway  100  to external networks for receiving packets from the network. Broadband network interfaces  414  may include IP network interfaces as well as ATM network interfaces. Each broadband network interface  414  may include a network processor  416 , a connection table  418 , and an Ethernet,interface  420 . Network processors  416  may control the writing of data to each connection table  418 . Each connection table  418  maintains connection data for forwarding media packets to the correct voice server. Internal Ethernet interfaces  420  connect each broadband network interface  414  to packet switching fabric  412 .  
         [0036]     Packet switching fabric  412  interconnects voice servers  400  and broadband network interfaces  414 . In the illustrated example, packet switching fabric  412  includes a plurality of ports, numbered 1-5. Five ports are shown for illustrative purposes only. It is understood that packet switching fabric  412  may include fewer or more than five ports, depending on the number of devices connected to packet switching fabric  412 .  
         [0037]     Media gateway  100  also includes a TDM matrix module  422  for switching TDM timeslots between TDM network interfaces  424  and voice servers  400 . TDM network interfaces  424  connect media gateway  100  to external TDM devices, such as TDM-enabled switching offices.  
         [0038]     A control module  426  controls the overall operation of media gateway  100 . In the illustrated example, control module  426  includes a UMA-UMTS TrFO controller  428  for receiving information from CPUs  406  of each voice server module regarding ingress and egress encoding rates being used by media streams of a UMA or a UMTS connection. UMA-UMTS TrFO controller  428  may also receive data from media gateway controller  102  indicating initial rates used by each end of a UMA-UMTS connection. UMA-UMTS TrFO controller  428  may determine, based on the rates, whether TrFO is possible and instruct the CPUs of the appropriate voice servers to issue rate control requests and establish a Transcoding free connection.  
         [0039]      FIG. 5  is a block diagram illustrating exemplary steps for achieving TrFO for a call that includes a UMA leg and a UMTS leg according to an embodiment of the subject matter described herein. Referring to  FIG. 5 , a first call leg (labeled 1) is established between UMA node  112  or  114  and voice server card  400 A. A second call leg (labeled 2) is established between UMTS node  108  and a second voice server card  400 B. A third media connection (labeled 3) is established between broadband interface card  414  and voice server  400 B. Once UMA-UMTS TrFO controller  428  determines that transcoder free operation is possible and instructs the voice server cards to issue any needed rate control, UMA-UMTS TrFO controller  428  instructs broadband interface card  414  to replace connection 1 with connection 3. Replacing connection 1 with connection 3 may include instructing broadband interface card  414  to update its connection table  418  to reflect the new voice server for the call.  
         [0040]     Setting up the transcoding free connection may include instructing voice server card  400 B to implement the appropriate Nb or lu protocol stack for interfacing with UMTS node  108  over a transcoding-free channel. Tables 1 and 2 shown below illustrate the status of connection table  418  of a broadband network interface card  414  before and after a transcoding free connection is established. Tables 1 and 2 each include a first column indicating the external or network VPI/VCI value associated with incoming ATM cells that carry voice. The second column in each table includes a new VPI/VCI value used internally between the voice server cards and the network interfaces. The third column includes the voice server MAC address corresponding to the connection. It can be seen that in Table 1, before the transcoding free connection is established, the connection to each endpoint includes a separate voice server MAC address. In Table 2, after the transcoding free connection is established, the voice server MAC address to which both endpoints of the connection are connected is Ethernet address EthO, which corresponds to a single voice server card.  
                             TABLE 1                           Broadband Interface Connection Table Before TrFO            External VPI/VCI   New VPI/VCI   Voice Server MAC Addr.               100/1   110/1   Eth 0       100/2   110/2   Eth 1                  
 
         [0041]    
       
         
               
             
               
               
               
             
           
               
                 TABLE 2 
               
             
             
               
                   
               
               
                   
               
               
                 Broadband Interface Connection Table After TrFO 
               
             
          
           
               
                 External VPI/VCI 
                 New VPI/VCI 
                 Voice Server MAC Addr. 
               
               
                   
               
               
                 100/1 
                 110/3 
                 Eth 1 
               
               
                 100/2 
                 110/2 
                 Eth 1 
               
               
                   
               
             
          
         
       
     
         [0042]     An important function performed by a DSP once a transcoding free connection is established is radio access bearer sub-flow combination indicator (RFCI) mapping. In order to perform such mapping, the DSP may maintain separate RFCI values for each connection endpoint. Tables 3 and 4 shown below are examples of RFI values that may be maintained by a DSP on a voice server card according to an embodiment of the subject matter described herein.  
                             TABLE 3                           RFCI Values and Rates for Endpoint A                Channel Index   Rate                       1   12.2k           2   10.2k           3   7.95k           4    6.7k                      
 
         [0043]    
       
         
               
             
               
               
               
             
           
               
                 TABLE 4 
               
             
             
               
                   
               
               
                   
               
               
                 RFCI Values and Rates for Endpoint B 
               
             
          
           
               
                   
                 Channel Index 
                 Rate 
               
               
                   
                   
               
               
                   
                 5 
                 12.2k 
               
               
                   
                 6 
                 10.2k 
               
               
                   
                 7 
                 7.95k 
               
               
                   
                 8 
                  6.7k 
               
               
                   
                   
               
             
          
         
       
     
         [0044]     From Tables 3 and 4, the channel index and the corresponding rates for each endpoint can be determined. Once the DSP knows the indices and corresponding rates, the DSP can perform mappings between indices used by different endpoints. In the examples illustrated in Tables 3 and 4, the mappings would be 1-5, 2-6, 3-7, and 4-8.  
         [0045]      FIG. 6  is a block diagram illustrating an alternate method for implementing TrFO for a call having a UMA leg and a UMTS leg in a media gateway according to an embodiment of the subject matter described herein. Referring to  FIG. 6 , a first media stream connection (labeled 1) is established between UMA node  112  or  114  and voice server  400 A. A second media connection (labeled 2) is established between UMTS node  108  and voice server  400 B. Once UMA-UMTS TrFO controller  428  (illustrated in  FIG. 4 ) determines that transcoder-free operation is possible, UMA-UMTS TrFO controller  428  instructs voice server  402 A to perform a loop back function and to initiate a connection (labeled 3) with voice server  402 B. Implementing a loop back connection at voice server  402 A means that the DSP on voice server  402 A is not impacted. Thus, even though the solution illustrated in  FIG. 6  requires two voice servers, DSP processing resources are conserved over conventional TrFO implementations in media gateway, because DSP resources on the voice server where the loop back is implemented are not used.  
       Rate Control Procedures  
       [0046]     As described above, one aspect of establishing and maintaining a transcoding free connection for a call that includes a UMA and a UMTS leg is implementing rate control for both legs of a call. UMTS protocols include rate control messages to implement rate control procedures. UMA protocols do not have separate rate control messages and instead uses a codec mode request (CMR) field stored in media stream packets. While the above-referenced  3 GPP standard indicates that media gateways should appropriately handle rate control requests from the Mb interface or the Nb interface, the standard is silent as to the timing and other implementation details of such procedures.  
         [0047]      FIG. 7  is a flow chart illustrating exemplary steps that may be performed by a media gateway  100  in processing a rate control request initiated by a UMA endpoint according to an embodiment of the subject matter described herein. Referring to  FIG. 7 , in step  700 , media gateway  100  receives a media packet including a CMR field on the Mb interface. In step  702 , media gateway issues a rate control request on the lu or Nb interface, depending on how the UMTS node is connected to media gateway  100 , requesting that the UMTS endpoint begin sending media packets encoded at the requested rate.  
         [0048]     In step  704 , processing diverges depending on whether the UMTS endpoint is using luUP version 1 or version 2. If luUP version 1 is being used, control proceeds to step  706  where media gateway  100  monitors voice packets on the lu interface to see if the rate changes before a timeout period. In step  708 , if media gateway  100  determines that the rate has changed, control proceeds to step  710  where media gateway  100  determines that the rate change was successful. In step  710 , if media gateway  100  determines that the rate has not changed before the timeout period, control proceeds to step  714  where media gateway  100  determines that the rate change was not successful.  
         [0049]     Returning to step  704 , if luUP version 1 is not being used, control proceeds to step  716  where media gateway  100  determines whether luUP version 2 or NbUP is being used on the UMTS leg. If neither of these protocols is being used, control proceeds to step  718  where other protocol processing is performed. If, however, one of these protocols is being used, control proceeds to step  720  where media gateway  100  waits for an acknowledgement from the UMTS leg on the lu or Nb interface. In step  722 , media gateway  100  determines whether the acknowledgement was received within the timeout period. If the acknowledgment was received within the timeout period, control proceeds to step  712  where media gateway  100  determines that the rate change was successful. If, however, media gateway  100  does not receive the acknowledgement within the timeout period, media gateway  100  proceeds to step  714  where it determines that the rate change was unsuccessful.  
         [0050]      FIG. 8  is a flow chart illustrating exemplary steps that may be performed by media gateway  100  in responding to a rate control request initiated by the UMTS leg of a call or session. Referring to  FIG. 8 , in step  800 , media gateway  100  receives a rate control request on the lu or Nb interface. In step  802 , media gateway  100  changes the CMR field on all packets sent over the Mb interface to reflect the requested rate. In step  804 , processing diverges depending on whether luUP version 1 is being used. If luUP version 1 is being used, control proceeds to step  806  where media gateway  100  sends packetized voice to the UMTS interface where the packetized is encoded at the rate at which media gateway  100  receives packetized voice on the Mb interface.  
         [0051]     If luUP version 1 is not being used, control proceeds to step  808  where media gateway  100  determines whether luUP version 2 or NbUP is being used. If neither of these protocols is being used, control proceeds to step  810  where media gateway  100  performs other protocol processing. If however, one of these protocols is being used, control proceeds to step  812  where media gateway  100  monitors the encoding rate being used on the Mb interface. In step  816 , media gateway  100  determines whether the requested rate is detected within the timeout period. If the requested rate is not detected within the timeout period, control proceeds to step  818  where media gateway  100  sends a negative acknowledgment on the lu or Nb interface. If the requested rate is being used within the timeout period, control proceeds to step  820  where media gateway  100  sends positive acknowledgement on the lu or Nb interface.  
       Redundancy Reconciliation  
       [0052]     Another aspect of establishing and maintaining a transcoding free connection between a UMA and a UMTS call leg is redundancy reconciliation. A UMA connection uses packet redundancy to reconstruct voice packets in the event that a packet is lost. However, such redundancy is not used on a UMTS connection. Accordingly, media gateway  100  may reconcile this redundancy and send the appropriate packets over the UMTS and UMA legs of a connection.  
         [0053]      FIG. 9  is a flow chart illustrating exemplary steps performed by media gateway  100  in building redundant voice frames to be sent over a UMA leg based on voice frames received over a UMTS leg of a connection. Referring to  FIG. 9 , in step  900 , media gateway  100  receives a packet from a UMTS call leg including a current voice frame. If the current voice frame is the first voice frame received for a connection, it is sent to the UMA leg without waiting to build redundancy in order to avoid delays. However, media gateway  100  may copy the current voice frame to sent with the next current voice frame as a redundant voice frame. Accordingly, in step  902 , media gateway  100  buffers n+1 voice frames, where n is the UMA redundancy level and builds packets to send over the UMA call leg with the appropriate redundancy level. In step  904 , media gateway  100  sends packets with the current voice frame and n previous voice frames to the UMA leg.  
         [0054]     It should be noted that each current voice frame may be sent immediately to the UMA leg. Copies of each current voice frame may be made and maintained by media gateway  100  to build redundant frames to be sent along with each current voice frame.  
         [0055]      FIG. 10  is a flow diagram illustrating exemplary steps for building UMA redundancy from UMTS data. Referring to  FIG. 10 , in line  1 , media gateway  100  receives a packet with voice frame F 1  from a UMTS leg of a call. In line  2 , media gateway  100  immdiately sends a packet with voice frame F 1  over the UMA call leg. In line  3 , media gateway  100  receives a packet with voice frame F 2  from the UMTS call leg. In line  4 , media gateway  100  sends a voice packet with frames F 1  and F 2  to the UMA call leg. In line  5  of the message flow diagram, media gateway  100  receives a packet with voice frame F 3 . In line  6  of the message flow diagram, media gateway  100  sends a voice packet with voice frames F 2  and F 3  to the UMA call leg.  
         [0056]      FIG. 11  is a flow chart illustrating exemplary steps that may be performed by media gateway  100  in processing packets received from the UMA leg. Referring to  FIG. 11 , in step  1100 , media gateway  100  receives packets with the current voice frame and n previous voice frames from the UMA call leg. In step  1102 , media gateway forwards the current voice frame to the UMTS call leg. In step  1104 , media gateway determines whether a packet loss was detected on the UMA call leg. If a packet loss has not been detected, control returns to step  1100  where the next UMA packet is received and processed.  
         [0057]     In step  1100 , if a packet loss is detected on the UMA leg, control proceeds to step  1106  where media gateway  100  receives the next packet from the UMA call leg. In step  1108 , media gateway  100  forwards the current voice frame and previous lost voice frames to the UMTS call leg.  
         [0058]      FIG. 12  is a message flow diagram corresponding to the flow chart of  FIG. 11 . In  FIG. 12 , it is assumed that the packetization times of the UMA and UMTS call legs are the same. In lines  1 - 3  of the message flow diagram, media gateway  100  receives packets from the UMA leg and forwards the current voice frame to the UMTS leg. In line  4 , a packet loss occurs on the UMA call leg. In line  5 , the packet with the current voice frame and the lost frame are received from the UMA leg. Media gateway  100  sends the current packet and the lost packet at about the same time.  
         [0059]      FIG. 13  is a flow diagram illustrating redundancy reconciliation that may be performed by media gateway  100  where the UMA and UMTS legs use different packetization times. In  FIG. 13 , the UMA leg uses a 40 millisecond packetization time and the UMTS leg uses a 20 millisecond packetization time. Referring to  FIG. 13 , in line  1 , the UMA call leg sends a packet with voice frames F 1  and F 2  to media gateway  100 . Media gateway  100  immediately sends both packets F 1  and F 2  to the UMTS leg in light of the different packetization time. In line  2  of the message flow diagram, at 80 milliseconds, the UMA call leg sends a packet with voice frames F 1 , F 2 , F 3 , and F 4 , where frames F 3  and F 4  are current. Media gateway  100  sends only the current frames F 3  and F 4  to the UMTS leg. In line  3  of the message flow diagram, a packet is lost. In line  3  of the message flow diagram, media gateway  100  receives a packet from the UMA leg with voice frames F 5 -F 8 . Since none of these frames have been sent to the UMTS leg, media gateway  100  sends four packets with voice frames F 5 -F 8  to the UMTS call leg.  
         [0060]     It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.