Abstract:
The invention comprises a system and method for transmitting and receiving multiplexed Voice over Internet Protocol (VoIP) traffic. The invention advantageously provides efficient gateway-to-gateway communication by reducing overhead where at least two conversations are transmitted between VoIP gateways. Additionally, signal degradation is avoided since there is no transcoding of signals.

Description:
BACKGROUND OF THE DISCLOSURE 
   1. Technical Field of the Invention 
   This invention generally relates to the field of communication systems and, more particularly, to a Voice over Internet Protocol (VoIP) gateway to gateway communication system for use in an Internet Protocol (IP) network. 
   2. Description of the Background Art 
   Voice over Internet Protocol (VoIP) is a technology that allows the transmission of voice using an Internet Protocol (IP) network, such as the Internet. For instance, a calling party places a call on a telephone set. The telephone set digitizes the voice signal and transmits the voice signal to a VoIP gateway servicing the calling party. The VoIP gateway, in turn, establishes a call with a VoIP gateway that services the called party. 
   Presently the International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) Recommendation H.323 specifies the technical requirements for the packets transmitted between VoIP gateways. Each packet has a Real-time Transport Protocol (RTP) header for carrying real time services such as voice and video in a payload portion of the RTP packet, a payload identifier so that the receiving gateway can determine the type of information contained in the packet, and sequence numbers and timstamps for identifying the order of the packets. In addition, the RTP packet is encapsulated in a User Datagram Protocol (UDP) transport/Internet Protocol (IP) layer packet. 
   Unfortunately, RTP and UDP overheads are too large. For example, the UDP header is 40 bytes and the RTP header is 12 bytes. As conventional methods are used to reduce the size of the Internet Protocol (IP) voice payload from 64 kb/s to as low as 4 kb/s, the RTP and UDP comprise a larger portion of the data actually transmitted resulting in inefficiency when transporting packets between VoIP gateways. 
   SUMMARY OF THE INVENTION 
   The invention comprises a system and method for transmitting and receiving multiplexed Voice over Internet Protocol (VoIP) traffic. The invention advantageously provides efficient gateway-to-gateway communication by reducing overhead where at least two conversations are transmitted between the same VoIP gateways. Additionally, signal degradation is avoided since there is no transcoding of signals. 
   A method of transporting voice traffic from a Voice over Internet Protocol (VoIP) gateway, over an Internet Protocol (IP) network, to a destination, according to the present invention comprises the steps of: receiving voice traffic at the VoIP gateway; determining whether the destination is serviced by a second VoIP gateway; multiplexing the voice traffic at the VoIP gateway; and transporting the multiplexed voice traffic to the second VoIP gateway utilizing a plurality of transport packets, responsive to an affirmative determination that the destination is serviced by the second VoIP gateway. 
   An apparatus for transporting voice traffic over an Internet Protocol (IP) network to a destination, according to the present invention, comprises: a first Voice over Internet Protocol (VoIP) gateway, for receiving voice traffic; the first VoIP gateway determining whether said destination is serviced by a second VoIP gateway; the first VoIP gateway multiplexing said voice traffic; the first VoIP gateway transporting the multiplexed voice traffic to the second VoIP gateway utilizing a plurality of transport packets, responsive to an affirmative determination that the destination is serviced by the second VoIP gateway. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which: 
       FIG. 1  depicts a high level block diagram of a communications system including the present invention; 
       FIG. 2  depicts a high level block diagram of an embodiment of the controller suitable for use within a Voice over Internet Protocol (VoIP) gateway; 
       FIG. 3  depicts a flow diagram of a method for providing VoIP gateway to gateway communication over the Internet Protocol (IP) network according to the invention; 
       FIG. 4  depicts a diagram of a modified H.323 packet data structure useful in understanding the operation of the communications system in  FIG. 1 ; 
       FIG. 5  depicts a transport packet data structure comprising multiple RTP payloads; and 
       FIG. 6  depicts a call flow diagram useful in understanding an embodiment of the present invention. 
   

   To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. 
   DETAILED DESCRIPTION 
   The invention will be primarily described within the context of a pair of subscribers (A and B) communicating via Voice over Internet Protocol (VoIP) utilizing different transport mediums, for example Digital Subscriber Line (DSL), Plain Old Telephone Service (POTS), cellular and cable modem technologies. It should be noted by those skilled in the art that the applicability of the present invention is not limited to this embodiment. 
     FIG. 1  depicts a high level block diagram of a communications system including the present invention. Specifically, the system of  FIG. 1  comprises a first VoIP gateway  122  which is coupled to a telephone  102  via a transmission medium  110  (illustratively, a copper pair, coaxial cable, fiber optic cable or the like), a first Voice over Digital Subscriber Service Line (VoDSL) Integrated Access Device (IAD)  112  via a transmission medium  114 , a cable modem  116  via a transmission medium  118 , and a first cell site  120  via a transmission medium  121 . First VoDSL IAD  112  is in turn coupled to a terminal  104  (illustratively, a telephone, a Personal Computer (PC) or workstation). A terminal  106  is coupled to cable modem  116 . A cellular phone  108  is coupled to first cell site  120  via a radio frequency link. 
   It should be noted that the present invention does not require a specific DSL service type, such as Asymmetric Digital Subscriber Line (ADSL), Rate Adaptive DSL (RADSL), Single-line DSL (SDSL), Integrated Services Digital Network (IDSL) and the like. Therefore, those skilled in the art and informed by the teachings of the present invention will be able to readily adapt any appropriate DSL service type to the present invention. 
   The first VoIP gateway  122  is coupled to an Internet Protocol (IP) network  126 . Also coupled to IP network  126  is a second VoIP gateway  128  and, optionally, a gatekeeper  124 . The gatekeeper has a database (not shown) for storing IP addresses which correspond to telephone numbers. Each VoIP gateway  122 ,  128  has a plurality of User Datagram Protocol (UDP) ports (not shown) as well as a respective VoIP gateway controller  122 C and  128 C respectively. Second VoIP gateway  128  is coupled to a telephone  132  via a transmission medium  130 , a second Voice over Digital Subscriber Service Line (VoDSL) Integrated Access Device (IAD)  140  via a transmission medium  142 , a second cable modem  144  via a transmission medium  146 , and a second cell site  148  via a transmission medium  149 . Second VoDSL IAD  140  is in turn coupled to a terminal  134 . In addition, a terminal  136  is coupled to second cable modem  144 , and cellular phone  138  is coupled to second cell site  148  via a radio frequency link. 
   It should be noted that the operation of the first VoIP gateway  122  is similar to the operation of the second VoIP gateway  128 . As such, only differences between the first VoIP gateway  122  and second VoIP gateway will be described in more detail. 
   As a call arrives at the first VoIP gateway  122 , for example from a DSL subscriber, first VoIP gateway  122  compares the phone number of the called party to a database which has a corresponding IP address for a VoIP gateway (e.g. VoIP gateway  128 ) that serves the called party. After a determination is made that the second VoIP gateway exists and is compatible, via signaling messages communicated between the respective gateways another determination is made by the first VoIP gateway  122  whether traffic is being presently provided to the second VoIP gateway  128 . If traffic is currently being provided to the second VoIP gateway  128 , voice traffic from the recent call is encapsulated with a modified Real-time Transport Protocol (RTP) which will be discussed more fully in  FIG. 3 . The modified RTP packet is then multiplexed with other voice traffic going to the second VoIP gateway  128  and encapsulated in a User Datagram Protocol (UDP) transport packet. The UDP transport packet with the encapsulated modified multiplexed RTP packets are communicated to the second VoIP gateway  128  via a logical link. If traffic is not currently being provided to the second VoIP gateway  128 , the modified RTP packet is encapsulated in a user data protocol transport packet. Multiplexing will then occur when traffic from other callers is being routed to the second VoIP gateway  128 . 
   It should be noted that each modified RTP packet includes an identifier for each caller. This way when a call becomes inactive for particular callers and called parties, the logical link is not broken but remains up until all calls become inactive. 
   At the second VoIP gateway  128 , the UDP/IP packet is received and the modified RTP packets are demultiplexed and decoded. Each call is then routed to the appropriate destination. 
   In another embodiment of the invention, the gatekeeper  124  can be used to look up IP addresses for corresponding telephone numbers. 
   It should be noted by those skilled in the art that although the invention is described in the context of a call being established in one direction, the call can be established in either direction and communication between the respective gateways  122  and  128  can occur simultaneously according to the present invention. 
     FIG. 2  depicts a high level block diagram of an embodiment of the controller suitable for use within a Voice over Internet Protocol (VoIP) gateway. Specifically,  FIG. 2  depicts a high level block diagram of a VoIP gateway  122  suitable for use in the communication system  100  of  FIG. 1 . The VoIP gateway controller  122 C comprises a microprocessor  220  as well as memory  230  for storing programs  250  such as VoIP processing method  300  which will be described more fully below in a discussion of  FIG. 3 . The microprocessor  220  cooperates with conventional support circuitry  240  such as power supplies, clock circuits, cache memory and the like as well as circuits that assist in executing the software methods of the present invention. As such, it is contemplated that some of the process steps discussed herein as software processes may be implemented with hardware, for example, a circuitry that cooperates with the microprocessor  220  to form various steps. 
   The VoIP gateway controller  122 C also comprises input/output circuitry  210  that forms an interface between the microprocessor  220 , the IP network  126 , telephone  102 , VoDSL IAD  112 , cable RG  116 , cell site  120 , and other VoIP circuitry (not shown). 
   Although the VoIP controller  122 C is depicted as a general purpose computer that is programmed to perform VoIP control and processing functions in accordance with the present invention, the invention can be implemented in hardware, in software, or a combination of hardware and software. As such, the processing steps described above with respect to the various figures are intended to be broadly interpreted as being equivalently performed by software, hardware, or a combination thereof. 
   It will be appreciated by those skilled in the art that the VoIP controller  122 C provides sufficient computer functionality to implement the invention as described above. 
     FIG. 3  depicts a flow diagram of a method for providing VoIP gateway to gateway communication according to the invention. The method  300  of  FIG. 3  may be stored in the VoIP controller  122 C in, for example, memory  230  within the portion used for storage of various programs  250 . 
   The method  300  is initiated at step  302  and proceeds to step  304 , where the first VoIP gateway  122  receives a request from a source to connect to a respective destination. It should be noted that the first VoIP gateway may also receive multiple requests from multiple sources for connections to multiple destinations. 
   At step  306  a determination is made as to whether the requested destination is served by a corresponding VoIP gateway (e.g. VoIP gateway  128 ) via signaling messages between the respective VoIP gateways. Box  308  provides exemplary means of determining whether such a corresponding VoIP gateway exists. Specifically, the telephone number of the called party can be compared to a database in the first VoIP gateway  122  which contains a list of telephone numbers and respective IP addresses of VoIP gateways which serve those telephone numbers. Alternatively, a gatekeeper  124  including such data can be used in order to conserve memory in the VoIP gateways. The gatekeeper  124  will look up a respective IP address for the called party. In addition, any type of memory storage device can be used in place of a VoIP gateway or gatekeeper to store telephone numbers and corresponding IP addresses. The method  300  then proceeds to step  310 . 
   At step  310  a query is made as to whether a second VoIP gateway  128  found at step  306  is compatible with the first VoIP gateway  122 . Compatibility is defined as being able to demultiplex and decode the data structure used in the present invention. If the query at step  310  is answered negatively, the method  300  proceeds to step  312  where the call is routed and transmitted in a conventional manner. That is, if a second gateway does not exist, or an existing second gateway is not compatible, then conventional call routing is employed. The method then proceeds to step  314  where it exits. 
   If the query at step  310  is answered affirmatively, the method proceeds to step  316  where a query is made as to whether first VoIP gateway  122  presently provides voice traffic to second VoIP gateway  128 . If the query at step  316  is answered affirmatively, the method then proceeds to step  320 . If the query at step  316  is answered negatively, the method then proceeds to step  318  where a logical link is established between first VoIP gateway  122  and second VoIP gateway  128  with a port number and call identifier. The matter  300  then proceeds to step  320 . 
   At step  320  the voice traffic is appended with a modified Real-time transport protocol header according to the present invention. In communicating to each other, each respective gateway communicates a UDP port number to the other gateway in which to access the gateway and a call identifier in which to differentiate the respective callers. For instance, the first VoIP gateway  122  may communicate that a transmission is occurring on port number 2 and the calling party is identified as caller number 7. The second gateway  128  will respond with a port number (i.e., port number 7) and identify the called party as number 5. 
   At step  322 , the new call is multiplexed with the other, if any, ongoing conversations onto a UDP/IP packet. It should be noted that the addition of the newly multiplexed voice traffic is constrained by Quality of Service issues such as the number of modified RTP packets which can be multiplexed due to latency, delay and time stamp constraints, etc. 
   At step  324 , a query is made as to whether any additional modified RTP packets from new callers need to be multiplexed. If the query at step  326  is answered affirmatively, the method proceeds to step  304 . If the query at step  324  is answered negatively, the method proceeds to step  326 . 
   At step  326  a query is made as to whether all callers are still active. If the query at step  326  is answered affirmatively, the method proceeds to step  324 . If the query at step  326  is answered negatively, the method proceeds to step  330  where any inactive callers are dropped and the inactive caller&#39;s respective call identifier is released and made available for assignment to future callers. 
   At step  330  a query is made as to whether only one caller is active. If the query is answered negatively, the method proceeds to step  324 . If the query at step  330  is answered affirmatively, the method proceeds to step  332  where the logical link is broken and the port is cleared. The method then proceeds to step  334  where it ends. 
     FIG. 4  depicts a diagram of a modified H.323 packet data structure useful in understanding the operation of the communications system in  FIG. 1 . Specifically,  FIG. 4  shows the packet data structure of a modified Real-time Transport Protocol (RTP) packet, according to the present invention, that may be used to transport voice and other data between VoIP gateways, such as first VoIP gateway  122  and second VoIP gateway  128 . Any differences between the standard RTP packet structure and the modified RTP packet structure of  FIG. 4  comprise data structure modifications according to the present invention. The standard or unmodified RTP packet data structure is more thoroughly described in the International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) Recommendation H.323, which is incorporated herein by reference in its entirety. 
   The data structure of modified RTP packet  400  comprises a conventional RTP header  402 , an RTP Payload  410 , and the following additional fields: a Call Identifier field (CI)  404  for identifying a caller between a telephone set and a respective gateway; a Length Indicator field (LI)  406  for identifying the size of the payload; and a Header Error Check (HEC) field  408  for identifying errors in the Call Identifier field  404  and the Length Indicator field  406 . It should be noted by those skilled in the art that HEC field  408  can be modified to identify errors in additional fields. The size of Call Identifier field  404  is one byte, but may be larger depending on the number of terminals or telephone sets coupled to a respective gateway. The HEC field  408  is preferably one byte. 
   In another embodiment of the modified RTP packet data structure of the present invention, Header Error Checker field  408  allows one bit error correction due to errors induced by noise, interference and other environmental conditions. This error correcting capability improves Quality of Service (QoS) for the traffic represented by the packets transmitted between the VoIP gateways. 
   The above described packet structure may be transported as payload within a transport data packet structure as depicted in  FIG. 5 . Specifically  FIG. 5  depicts a User Datagram Protocol (UDP)/Internet Protocol (IP) transport layer packet comprising multiple modified RTP packets and payloads. The UDP/IP packet data structure is more thoroughly described in the International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) Recommendation H.323. 
   A UDP/IP packet  500 , according to the invention, comprises multiple modified RTP packets as illustrated in  FIG. 5 , where RTP1  504  and associated payload  506 , RTP2  508  and associated payload  510 , up to RTPN  512  and associated payload  514  are independent from each other and are encapsulated in a common UDP/IP packet  500  having a UDP header  502 . 
     FIG. 6  depicts a call flow diagram useful in understanding an embodiment of the present invention. In the call flow diagram of  FIG. 6 , the signaling for the call setup and disconnect among first VoIP gateway  122 , gatekeeper  124  and second VoIP gateway  128  is defined in the International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) Recommendation H.225, which is incorporated herein by reference in its entirety. Control operations as well as capabilities exchange is defined in the International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) Recommendation H.245, which is incorporated herein by reference in its entirety. 
   H.225 signaling begins with party A initiating an Internet call by picking up telephone  102  and dialing party B&#39;s telephone number which is also known as an E.164 address. At step  602  the first VoIP gateway  122  communicates a Location Request (LRQ) message to gatekeeper  124  seeking the transport address of the second VoIP gateway  128  serving party B&#39;s telephone number. Gatekeeper  124  retrieves a table which contains transport addresses for corresponding telephone numbers. 
   At step  604 , gatekeeper  124  communicates a Location Confirmation (LCF) message to first VoIP  122  indicating that a transport address for second VoIP  128  was found. The LCF message may also contain the transport address of the second VoIP gateway  128 . 
   Although not shown, gatekeeper  124  can also provide a Location Reject (LRJ) message indicating that for the telephone number given a corresponding transport address for a second VoIP  128  that serves party B can not be found. A failure to detect a corresponding phone number phone number can result, for example, from party A dialing the wrong telephone number, the database for storing telephone numbers and corresponding transport addresses has not been updated or the VoIP gateway serving party B is not recognized by the gatekeeper  124 . 
   At step  606 , first VoIP gateway  122  communicates an Admissions Request (ARQ) message to gatekeeper  124  providing admissions control and bandwidth management functions. For instance, first VoIP gateway  122  may specify the requested call&#39;s bandwidth to gatekeeper  124 . 
   Gatekeeper  124  responds at step  608  by communicating an Admissions Confirm (ACF) message to the first VoIP gateway  122  indicating that the first VoIP&#39;s  122  request for bandwidth has been received and the parameters for the call accepted. 
   At step  610  first VoIP gateway  122  communicates a Setup message to second VoIP gateway  128  using the transport address. Responsively, at step  612 , second VoIP gateway  128  communicates a Call Proceeding message to first VoIP gateway  122  indicating that the Setup message is in process. 
   At step  614 , if VoIP gateway  128  would like to receive the call from VoIP gateway  122 , VoIP gateway  128  communicates an ARQ message to gatekeeper  124  providing admissions control and bandwidth management functions. 
   In response to VoIP gateway&#39;s  128  ARQ message, gatekeeper  124  communicates an ACF message at step  616  indicating that VoIP gateway&#39;s  128  ARQ message has been received and the parameters for the call accepted. 
   At step  618 , second VoIP gateway  128  communicates an Alerting message to first VoIP gateway  122  indicating that party B&#39;s telephone  132  is ringing. When party B picks up telephone  132  at step  420 , second VoIP gateway communicates a Connect message to first VoIP gateway  122  indicating that an H.225 call signaling channel has been established. 
   The call flow diagram of  FIG. 6  enters the capabilities exchange stage at step  622  where first VoIP gateway  122  and second VoIP gateway  128  communicate Capabilities Exchange messages with each other. During this process the respective VoIP gateways make known to each other their capability to receive and decode various signals. For example, it is not necessary that a VoIP gateway understand all of the respective VoIP gateway&#39;s capabilities. Capabilities not used or understood are simply disregarded by the respective VoIP gateway. 
   At step  624  first gateway  122  communicates an Open Logical Channel message to second VoIP gateway  128  indicating that a Logical Channel should be opened. The Open Channel message fully describes the content of the Logical Channel, including media type, algorithm in use, any options and all other information needed for second VoIP gateway  128  to interpret the content of the Logical Channel for example. Illustratively, the Open Logical Channel message is depicted as containing port number one as a means for which second VoIP gateway  128  can communicate UDP/IP packets to the first VoIP gateway  122  for the second caller. 
   Second VoIP gateway  128  responds at step  626  with an Open Logical Channel Acknowledgement message indicating that first VoIP gateway  122  can communicate UDP/IP packets to second VoIP gateway  128  via port number two for the second caller, for example. 
   The call flow diagram of  FIG. 6  enters the call signaling stage at step  628  where first VoIP gateway  122  communicates a Disconnect message to second VoIP gateway  128  indicating that party A has terminated the call. 
   In response to the termination of the call by party A, at step  630 , second VoIP gateway  128  communicates a Release message to first VoIP gateway  122  indicating that the prior message has been received and party B has released the call. 
   The call flow diagram of  FIG. 6  enters the control stage at step  632  where first gateway  122  communicates a Close Logical Channel message to second VoIP  128  indicating that the call for a specified Call Identifier  406  should be terminated. For example, if there was only one call going from the first VoIP gateway  122  to second VoIP gateway  128  on port number one for a caller with a Call Identifier  404  of two, closing the Logical Channel will clear the call with the given Call Identifier  404  of two and clears the UDP port. However, if more than one call was taking place between first VoIP gateway  122  and second VoIP gateway  128 , closing the Logical Channel will only clear the call for a specific Call Identifier  406 . The UDP port remains intact and other calls remain in progress until the specific user terminates the call. 
   At step  634 , second VoIP gateway  128  communicates a Close Logical Channel Acknowledgement message to first VoIP gateway  122  indicating that the called party has terminated their portion of the call, and the Logical Channel going from second VoIP gateway  128  to first VoIP gateway  122  should be closed for the respective Call Identifier  404 . 
   The above-described invention advantageously provides a means of communicating voice traffic between VoIP gateways in composite call formation form. Moreover, the invention advantageously does not require a conversion of the voice traffic payloads into a different format between gateways. The voice traffic payloads remain intact. Thus avoiding signal degradation and delay in converting payloads into different formats. In this manner, the invention provides a substantial improvement over prior art VoIP gateway-to-gateway communication; thereby providing a signal with reduced overhead where at least two conversations are transmitted between VoIP gateways. 
   It is noted that the number of modified RTP packets included within a UDP/IP packet is limited by Quality of Service issues. For instance, multiplexing a large number of modified RTP packets will increase system latency and delay due to increased buffering requirements. 
   Although various embodiments which incorporate the teachings of the present invention have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings.