Patent Application
20060104290
Media services play an important part in telecommunication systems such as call centers, traditional public switched telephone network (PSTN) switches, and conferencing servers. The convergence of IP technology with telecommunication networks uses media services provided from the Internet to users either in the IP network or in another network. Many types of media services can be deployed.
Media services provided across multiple types of networks, e.g., calls traveling from the Internet to another network can experience unacceptable delay. A portion of the delay is due to the use of a gateway (e.g., a media gateway) and media server that connect the networks. A media gateway, e.g., circuit switch, IP gateway, or channel bank that converts data from a format required for one network to the format required for another network.
Referring to
One or more time division multiplexed (TDM) based networks route data to the media gateway 14 or 17 and the media gateway 14 or 17 transmits the data over the IP network 11. For example, if the sender and receiver are both on the TDM based networks 13 and 15, the data can be transmitted to the media server 16 over the IP network 11. In other examples, the receiver or the sender may be located within the IP network 11 and the second party located on a TDM network. When a sender and receiver are on networks running different protocols, the packet may be routed from the media gateway 14 to the receiver without passing through the media server 16. While such architecture 10 using media gateways, can simplify the routing and collection of data from the TDM based network 13 or 15 and simplify the data conversion to a format recognized by the IP based network 11, the architecture 10 can also increase the delay incurred when transmitting a packet from a sender 12 to a receiver. For example, when a sender and receiver are both located outside the IP network 11, the packet or data will incur delay associated with the transmission of the packet from the media gateway 14 or 17 to the media server 16 to the media gateway 14 or 17.
A conferencing application can require low latency. Long delays can be experienced by callers that use a gateway to connect from a Public Switched Telephone Network (PSTN) network to an Internet Protocol (IP) network, to use, e.g., conferencing services located on the IP network 11. This delay can be due to the compression of speech signals by the gateway 14 for transmission over the IP network. Further delay is introduced as compressed speech frames arrive at the conferencing center (e.g., the media server 16) because the frames are decompressed and buffered for the removal of network jitter. Additionally, a mixed packet stream may need to be delivered back to the media gateway 14, therefore, introducing a second jitter buffer inside the gateway 14. Other delays include those associated with speech decoding, speech look-ahead buffering, network delay, and transmission delay.
The delay for a roundtrip data transmission can be substantial. For example, the delay can be large when more multiple parties call from TDM networks (e.g., PSTN networks) and share media content. For example, when a first party located in network 13 desired to communicate with a second party in network 15. In this example, assuming there is little network jitter and negligible transmission delay, the parties calling from a PSTN or TDM network in a conference would experience approximately 170 ms roundtrip delay when talking to each other using the Internet engineering task force (IETF) recommended a packet size corresponding to, e.g., 20 ms of data for the high compression speech codec ITU-T G.729. The delay includes the delay associated with encode buffering and look ahead buffering, server jitter buffer delay, mixing operation delay, plus gateway buffering. Typical delay times for these delays can be approximately 25 ms+20 ms+20 ms+20 ms in each direction resulting in a total roundtrip time of estimate of 170 ms. Additional propagation delay could add approximately 50 ms in each direction (assuming a relatively long transmission) resulting in a total roundtrip delay of 270 ms. This level of delay may not be acceptable for some media applications.
Referring to
In architecture 10, data (e.g., time division multiplexed (TDM) based data) from multiple callers or senders received by the media gateway 14 or 17 is forwarded to the media server 16. The payloads for multiple packets, from multiple data streams, or from multiple senders can be combined into a larger packet (superframe) and sent from the media gateway 14 to the media server 16. By taking advantage of the common destination of the data, the overhead for the packets sent to the media server can be reduced.
As shown in
For example, a packet can be sent from TDM network 13 to TDM network 15 via IP network 11. In this example, gateway 14 sends packet 50 to the media server 16 (
The packets 50 are generated according to a predefined, common format. The media gateway 14 generates the packet 50 including multiple payloads, the media server 16 processes the packet, and the media gateway 17 sends the payloads to the appropriate destinations. In each packet (e.g., packets received from the media gateway 14 and packets 50 generated for forwarding to the media server 16), all payloads are of the same type. For example, the payloads can be defined by a standard such as RFC1889, to allow a receiver and a transmitter to have the common knowledge of the structure and content of the packets. The type can be indicated in the Real Time Protocol (as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 1889) header 56 of packet 50.
In each packet or data stream (e.g., data received by the media gateway 14 and packets 50 generated for forwarding to the media server 16), all of the payloads have the same size or length. The length is common such that the media server 16 can identify the individual payloads and destination indications. The size of the payload can vary according to the particular Internet Engineering Task Force (IETF) standard used by the network for media transmissions. For example, the ITU-T G.711 standard includes packets with a payload length of 1 ms, the G.729 standard includes a payload length of 10 ms, the G.723.1 standard includes a payload length of 30 ms, and the like. The payload size can be the minimum frame size of the payload type for the implemented standard. In embodiments where the payload size is the minimum frame size of the payload type for the implemented standard, the payload type indicated in the RTP header 56 can also indicate the payload length.
Packet 50 also includes a User Datagram Protocol (UDP) header 54 that includes an indication of the length of packet 50. The number of payloads included in packet 50 is established based on the length of the packet (as indicated in header 54) and the payload type (as indicated in RTP header 56). The destination indication, e.g. port number in packet 50 is of a predefined length and can be independent of the payload type. For example, the port can be represented by two bytes.
Media that is transmitted can include voice frames and silence indication frames (SID frames). Either packet 50 includes either payloads for multiple voice frames or multiple SID frames. A packet 50 including payloads for multiple voice frames can be referred to as a voice superframe while a packet 50 including multiple SID frames can be referred to as an SID superframe. A bit in the RTP header (e.g., marker bit 55) indicates whether a packet 50 is a voice superframe or an SID superframe. For example, for a packet 50 including voice frames, marker bit 55 is set to 0 while for a packet 50 including SID frames marker bit 55 is set to 1 (or vice versa). The payload type indicated in the RTP header 56 and the packet length indicated in the UDP header 54 determine the number of SID frames in an SID superframe or voice frames in a voice superframe.
In some embodiments, the size of packet 50 is limited by the protocol of the associated IP network 11. For example, Ethernet specifies a maximum packet size of 1500 bytes. Thus, the transmitter and receiver conform to this maximum size such that the size of the payload of the superframe (e.g., the total size of the payloads from multiple packets, the associated port indications, and packet header information) does not exceed the specified length for the network.
In addition to voice data and silence indication data, tone data (e.g., tone data is described in RFC 2833) can also be transmitted between a TDM based network and an IP based network via a media gateway and server. In general, tone data is small in size and infrequent in transmission in comparison to the voice data. The tone data is not included in the superframes generated by the media gateway. Instead, the tone data is transported separately between the sender and receiver as individual transmissions. For example, the tone data may not be included in the superframes due to the difference in size compared to voice frames. In addition, the tone data may not be included in the superframes due to the infrequent transmission of tone data. Since tone data is generally transmitted infrequently, handling the tone packets separately is sufficient. In addition, tone information (control information) has less latency requirements in comparison to voice frames.
As described above, the generation and transmission of superframes between the media gateway and the media server can reduce data transport latency without introducing significant overhead. In addition, in some embodiments, the use of the superframe can improve the overall voice or media quality due to the shorter sampling durations. The superframe can also simplify or reduce the computation requirements at the media server because a single header is processed and all payloads for the superframe are of the same type and length.
Referring to
Process 72 is executed at a media gateway and includes receiving 74 one or more data streams from multiple senders in a TDM based network. The media gateway 14 aggregates 76 the payloads from the multiple data streams to generate a packet (e.g., a superframe) having multiple payloads and sends 78 the generated packet to a media server 16.
Process 80 is executed at a media server 14 and includes receiving 82 a frame with an aggregated payload from the media gateway. The media server processes 84 the payloads of the received frame and forwards 86 the frame to a media gateway.
Process 88 is executed at a media gateway and includes receiving 90 the frame with the aggregated payload from the media server 16. The media gateway generates 92 multiple TDM based data steams based on the payloads included in the superframe received from the media server 16. The media gateway forwards 94 the data (each data stream having a single payload) to a receiver (e.g., on the TDM based network) associated with the port indicated in the superframe.
While the description above includes generation of superframes for transmission between a media gateway and a media server, a similar frame structure and payload aggregation could be used for transmission of frames between two media gateways (e.g., without an intermediate media server). In addition, a similar frame structure and payload aggregation could be used between two devices where packets received at a first device are forwarded to the second device regardless of location of the frame origination or the destination of the frame.
Other embodiments are within the scope of the following claims.
