Abstract:
A method of transmitting data traffic from a network node comprising the steps of identifying a plurality of data packets as being members of a data session adding a timestamp to the header or data payload of each packet within the session wherein the timestamp is an additional timestamp and transmitting the packets to their destination.

Description:
CLAIM OF PRIORITY 
       [0001]    The present application claims the benefit as a continuation of U.S. application Ser. No. 12/965,355 filed Dec. 10, 2010 which claims the benefit and foreign priority under 35 U.S.C. 119 from Great Britain patent application No. GB 0921668.0, filed Dec. 10, 2009. The entire contents of the aforementioned applications are hereby incorporated by reference as if fully set forth herein. 
     
    
     FIELD 
       [0002]    This invention relates to enhancing the performance of media traffic over the Internet Protocol. It is particularly suitable, but by no means limited, to implementation as a realtime transport protocol (RTP) performance enhancing proxy for an IP (internet protocol) router carrying VoIP (Voice over IP) traffic. 
       BACKGROUND 
       [0003]    Within the digital network systems of today, and in particular the often congested telephony infrastructure of the public switched telephone network (PSTN), it is becoming increasingly popular to route voice communications over the internet, specifically, that is to use VoIP. This is particularly useful when there is no PSTN infrastructure at either the originator or the recipient of a voice communication, such as in a less developed country or a remote location, or where a dedicated network is to be set up for a specific purpose, for example for reasons of data security and integrity. In this event, it is often desired to use a dedicated satellite network. 
         [0004]    Typically, RTP is used for the transfer of audio and video data across an IP network. In general, IP networks suffer from occurrences of network outage, congestion and varying network delays which influence the latency experienced by packets of data travelling across the network. In turn, this may affect the quality of the voice delivered to the recipient as the packets must be recombined at the receiver. If certain packets have been corrupted, lost, or delayed, the packets available for recombination may be insufficient such that, for a given bandwidth, the packets available for recombination cannot provide an acceptable quality level of voice communication. 
         [0005]    In particular, satellite networks tend to suffer from large latency. Packet switched satellite networks also suffer large variations in data packet delay, also known as data packet jitter. 
         [0006]    RTP has a built-in jitter compensation capability, but implementations are not always capable of buffering for the amount of jitter experienced in large latency networks such as satellite networks. Typically, RTP implementations struggle to accommodate jitter of hundreds of milliseconds. This larger jitter that is often present in packet switched satellite networks is manifested as a perceived drop in the audio quality of the transmitted conversation due to insufficient packets being available for recombination at the receiver. 
         [0007]    Therefore, a common problem with media traffic, in particular when traversing a network comprising a satellite link, is the perceived quality of the transmitted voice, which greatly affects quality and user satisfaction, and the network bandwidth required in order to provide sufficient packets at the receiver in order to achieve an acceptable level of quality of the transmitted voice. In addition, it is often the case that the terminal device, such as a VoIP telephone, negotiates its codec bandwidth without knowledge of the network capacity. 
         [0008]    It would therefore be beneficial to provide a performance enhancement for an IP router, especially such a router deployed to carry media traffic over satellite networks, that enables the router to cope with a transmission network that experiences low bandwidth or high jitter/latency network conditions such as those often present in satellite networks. Media traffic such as VoIP packets on the network could be optimised for both network bandwidth efficiency and the perceived quality of the recombined digital audio or other data contained within the data packets traversing the network may also be maintained. 
       SUMMARY 
       [0009]    The invention is as set out in the Claims. 
         [0010]    By adding an additional timestamp to data packets that have been identified as members of a data session, jitter compensation can be performed such that the packets may be re-constituted at the same time and frequency as they arrived at the transmission router and in the correct sequence. The perceived quality of audio transmitted within these packets once reconstituted at the recipient can be maintained. 
         [0011]    By removing requests for non-required codecs, such as codecs with a high-bandwidth requirement, the data traffic requires less bandwidth, and also by identifying packets containing silence and removing those packets from the data session, the data packets may be transmitted in a more efficient manner. 
         [0012]    By identifying and removing replicated data from the header of a data packet, the bandwidth requirement of transmitting those packets can be reduced. 
         [0013]    Any or all of these techniques can be used in combination such that both bandwidth may be reduced and quality levels may be maintained in an IP network carrying media data traffic over IP. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    Embodiments will now be described, by way of example only, and with reference to the drawings in which: 
           [0015]      FIG. 1A  illustrates an overview of a typical IP network; 
           [0016]      FIG. 1B  illustrates a typical LAN to WAN network; 
           [0017]      FIG. 2  illustrates a data path through an IP router according to the invention for LAN to WAN IP routed data; 
           [0018]      FIG. 3  illustrates the data path of  FIG. 2  with an additional RTP Performance Enhancing Proxy Stage; 
           [0019]      FIG. 4  illustrates a data path through an IP router according to the invention for WAN to LAN IP routed data; 
           [0020]      FIG. 5  illustrates the data path of  FIG. 4  with an additional RTP Performance Enhancing Proxy Stage; 
           [0021]      FIG. 6A  shows a flow diagram according to the invention at a conversation originating LAN; and 
           [0022]      FIG. 6B  shows a flow diagram according to the invention at a recipient LAN. 
       
    
    
       [0023]    In the figures, like elements are indicated by like reference numerals throughout. 
       DETAILED DESCRIPTION 
       [0024]    By way of overview, and as is illustrated in  FIGS. 1A and 1B , two media devices  2 ,  3  communicate over an IP network  1 . The IP network comprises, for example, Networks A, B and C. Typically, Networks A and C comprise relatively high bandwidth/low jitter networks such as LANs  10  and  11  of  FIGS. 1B and 2  to  5 . Network B (such as WAN  14  of  FIG. 1B ) would typically comprise a low bandwidth/high jitter network, for example a satellite network. Network B is, in effect, an impaired network that imposes capacity and quality constraints upon the data traffic it carries. 
         [0025]    As shown in  FIG. 1B , local area network (LAN)  10  is coupled via an IP router  12  to a wide area network (WAN)  14  and the internet. Multiple LANs may be connected together in this manner. 
         [0026]    A point-to-point or pseudo point-to-point link (known as an aggregate) is initiated to join LANs across a network such as that of  FIG. 1 . This network may involve the use of satellite transmission. Specific data packet traffic may be routed across an aggregate via a dedicated point-to-point data tunnel (known as a tributary). Tributaries can be multiplexed across aggregates from LAN to LAN via the IP routers and the WAN. In its simplest form, a tributary is a point-to-point tunnel endpoint for transferring packets between the LANs over the intermediate WAN. 
         [0027]    As discussed in more detail below, a standard embedded IP router, such as IP Router  12  in a multiplexer platform is equipped with a performance enhancing proxy for VoIP traffic, which, when enabled, gives an enhanced RTP gateway to the WAN  14 . More specifically, the processing of IP tributary data undergoes the additional steps of:
       Header compression for RTP traffic   Session Initiation Protocol (SIP) filtering, such as SDP (Session Description Protocol) 64 kbit/s codec filtering   Jitter buffering for RTP traffic   Filtering out of certain small samples in G729B codec (a speech coding algorithm providing audio data compression)       
 
         [0032]    Packets that will traverse any one tributary in a particular direction and that are identified, at an originating IP router, as a session such as a conversation, are compressed, filtered and buffered according to the above. Corresponding data manipulation is performed at the recipient IP router for subsequent recombination into a standard RTP form. This technique can allow a reduction in the bandwidth requirement for their successful transmission at an acceptable level of quality, and compensate for the network jitter experienced. Data packet delivery can be guaranteed over the aggregate by way of sequencing, (that is identifying the position of a packet in a sequence) and hence identifying missing packets from the sequence, and also by the use of checksums to identify packet errors. Packets containing errors, for example those caused by corruption or significant delay in the network, may be discarded. 
         [0033]    Hence the quality of VoIP conversations across networks such as satellite networks with, for example, large jitter, can be maintained, and the bandwidth requirement to tunnel these conversations across an IP network may be reduced. 
         [0034]    By utilising the above additional steps in combination with the awareness of conversation context within the multiplexer platform, the jitter buffering can additionally utilise a small proportion (by adding a small timestamp to each voice data packet) of the significant bandwidth savings achieved by the other three steps. As a result of the additional timestamp, the quality of an RTP stream can be preserved across bandwidth-sensitive networks which suffer from large variations in latency (packet-to-packet delays) by providing additional jitter compensation as described in more detail below. 
         [0035]    This technique achieves concurrent low bandwidth usage and high perceived quality. As will be described below, individual controls are provided over each of the above elements such that bandwidth and perceived quality of the transmission may be controlled when it is implemented across a network such as a satellite network. 
         [0036]    Turning to  FIG. 2 , a data path through an IP router  12  according to the invention for LAN to WAN IP routed data within a network of  FIG. 1  is illustrated. An aggregate point to point link  26  provides a data path from LAN  10  to WAN  14  to a destination LAN such as LAN  11  of  FIG. 4 . The IP routed data utilises a tributary tunnel path  24  for point to point data transmission. The tributary data tunnel path used for VoIP RTP data transfer is selected via IP Route  20  and an IP Filter  22  lookup tables. The IP Route Lookup  20  selects a tributary for the LAN interface to forward a packet over via a destination IP address lookup in the IP route table. The IP Filter Lookup  22  can redirect or discard traffic based on other IP traffic attributes, for example redirecting all RTP and SIP traffic down a specific tributary. 
         [0037]    With the performance enhancing proxy in operation, and hence the enhanced RTP gateway enabled, an additional RTP Performance Enhancing Proxy (PEP) stage  30  is performed on the SIP and RTP packets before transmission of these packets over the tributary tunnel path  26  as shown in  FIG. 3 . 
         [0038]    Within the RTP PEP stage  30 , the three steps of SIP filtering  32 , codec filtering  34 , and RTP header compression  36  are executed with an optional fourth step  38  of adding an additional timestamp to the RTP. 
         [0039]    SIP filtering at filter stage  32  comprises stripping out any negotiation messages in the SIP session description protocol messages which request the high-bandwidth codecs such as the 64 kbit/s G.711 codecs, and forcing the audio terminals to use the much less bandwidth intensive 8 kbit/s G.729 codec instead. 
         [0040]    Codec filter stage  34  then filters out small-sample packets which occur in G.729B when transitioning into and out of silence suppression mode. During “normal” conversations, it can be seen that some G729B devices generate smaller samples (of 10 ms) as voice/silence transitions occur. These are silence information descriptors used for comfort-noise generation during silent periods. In realworld listening trials, these packets have not been found to substantially enhance or improve the perceived voice quality. By deleting these packets, bandwidth may be saved. 
         [0041]    Compression stage  36  comprises stripping out the constant portion of the headers of each RTP packet resulting in less header data being transmitted and hence a reduction in the required bandwidth for transmission of the RTP packet. 
         [0042]    Timestamp stage  38  comprises adding a timestamp to each RTP voice packet. This timestamp, an additional timestamp to the standard RTP timestamp, is added to the data payload of each RTP packet and is used as a means of timing the release of the packet into the remote recipient IP network, for example LAN  11 , once the packet has traversed the impaired network. This additional timestamp enables the RTP jitter buffer mechanism to operate for all RTP data streams, since the standard RTP timestamp implementation varies according to the media stream carried. Thus, jitter caused by a high variation of latency in a network link is removed from the voice data packets. A smooth and predictable feed of voice packets is thereby provided to the remote voice terminal, for example in LAN  11 . This substantially improves the overall perceived voice quality of the conversation and due to the bandwidth savings achieved by the other three steps, even after the addition of the timestamp, the bandwidth is still reduced overall from that required by a network link not operating with the features described herein. 
         [0043]    It will be appreciated that all, one or a sub-combination of these stages can be implemented as appropriate. 
         [0044]      FIG. 4  shows the data path through an IP router for WAN to LAN IP routed data from a network such as  FIG. 1 . Typically, the arrangement of  FIG. 4  would provide the recipient part of the aggregate link  26  of  FIG. 2 . Aggregate point to point link  26  provides the data path from WAN  14  to LAN  11 . The IP routed data utilises the same tributary tunnel path  24  for the point to point data transmission. The reverse process of IP Filter  22  and IP Route  20  lookup tables is used at the recipient end of aggregate link  26 . 
         [0045]    When the performance enhancing proxy server is in operation, and hence the enhanced RTP gateway is enabled, an additional RTP PEP stage  50  is performed on the RTP packets as they are received at the endpoint of the tributary tunnel  24  before being routed to the LAN  11  as shown in  FIG. 5 . 
         [0046]    Decompression stage  52  comprises restoring the constant data that was stripped out of the header before transmission such that the original packets are reconstituted at the recipient. This enables standard network infrastructure to deal with the packets once they have arrived at the destination endpoint of tributary  24 . If a timestamp was added during RTP PEP stage  30 , the timestamp is used in conjunction with a jitter buffer  54  to time the release of the RTP packets into recipient LAN  11  and hence provide the packets to the recipient at the correct time and same frequency and order that they arrived at the transmission router. 
         [0047]    In operation, as shown in  FIG. 6A , at step  60 , a VoIP RTP conversation originates and is identified in a LAN, such as LAN  10 . Pre-filtering such that only RTP &amp; SIP UDP traffic is sent across tributary link  24  is carried out at step  61 . In step  61 , protocol headers are interrogated to identify RTP and SIP packets. 
         [0048]    When the RTP packets reach RTP PEP stage  30  (at step  62 ), the RTP PEP filtering mechanism on tributary  24  is carried out as shown in the following pseudo-code. Reference numerals from the figures are provided in the code. 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 If valid UDP packet 
               
               
                 { 
               
               
                    If even port number (RTP packets are even port numbers) 
               
               
                    { 
               
               
                       If SIP packet [SIP filter stage 32] 
               
               
                          Do SIP filtering 
               
               
                       Else 
               
               
                       { 
               
               
                          If (G729BShortPacketFiltering) 
               
               
                          [Codec Filter stage 34] 
               
               
                          { 
               
               
                             If (G729 RTP packet AND length is 
               
               
                             less than 40bytes) 
               
               
                                DiscardPacketAndReturn 
               
               
                          } 
               
               
                          RTPCompressPacket [Compress stage 36] 
               
               
                       } 
               
               
                    } 
               
               
                 } 
               
               
                 ForwardAcrossTribAsStandardIPTraffic [Route Packet step 63] 
               
               
                   
               
             
          
         
       
     
         [0049]    SIP packets are filtered as described in more detail in relation to SIP filter stage  32 , and all other packets are codec filtered by stage  34  and compressed by stage  36 . 
         [0050]    If any data is stripped from a packet, the checksums are recalculated before the data is sent on across the aggregate as a standard IP routed packet at stage  63 . 
         [0051]    When RTP data is identified in PEP stage  30 , a new transport header is used to carry this data across the tributary  24 . The transport header (see table 1 below) identifies the data as RTP PEP data, i.e. the data has been dealt with by RTP PEP stage  30  and includes a conversation identifier that allows up to 255 RTP conversations to be conveyed across each tributary link  24 . The header length for all the new RTP PEP headers is only 2 bytes. 
         [0000]    
       
         
               
               
               
             
               
               
               
               
             
               
               
               
               
               
             
           
               
                   
                 TABLE 1 
               
             
             
               
                   
                   
               
               
                   
                 Bits 
                   
               
             
          
           
               
                   
                 4 
                 4 
                 8 
               
               
                   
                   
               
             
          
           
               
                   
                 Use 
                 Type 
                 HeaderLength 
                 Conversation Id 
               
               
                   
                   
               
             
          
         
       
     
         [0052]    The Type identification code used across IP links identifies the four new types of packet used by the protocol: RTP PEP Start, RTP PEP Start Ack, RTP PEP Compress Data and RTP PEP Nak. 
         [0053]    According to the protocol developed in accordance with the present invention, when a conversation is first identified, data is sent uncompressed with a RTP PEP Start header including static data fields. When a recipient router receives a RTP PEP start header for a new conversation, a conversation context is created, and the static data fields from the header of the uncompressed packet are saved. An RTP PEP start ack packet is returned. Once the RTP PEP start ack packet has been received by the router that originally identified the conversation, the RTP conversation data is sent over the tributary  24  in a compressed form following passing through compressor stage  36  (without the static header fields) and with an RTP PEP compressed data header, described in more detail below. 
         [0054]    The pseudo-code for RTPCompressPacket (compress stage  36  of  FIG. 3 ) is: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If new conversation 
               
               
                   
                 { 
               
               
                   
                   Store static data 
               
               
                   
                   Send uncompressed with RTP PEP Start header 
               
               
                   
                 } 
               
               
                   
                 Else if conversation is not yet ACKed 
               
               
                   
                 { 
               
               
                   
                   Send uncompressed with RTP PEP Start header 
               
               
                   
                 } 
               
               
                   
                 Else 
               
               
                   
                 { 
               
               
                   
                   Send compressed with RTP PEP compressed data header 
               
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
         [0055]    Should compressed data be received with an unknown conversation identifier, an RTP PEP NAK packet is sent back which should cause the originator to identify the conversation again. 
         [0056]    Additionally, before RTP data is sent across the tributary link  24 , a local 16-bit timestamp is prepended to the RTP data payload (between the header and data) if optional jitter buffering is enabled. 
         [0057]    As shown in  FIG. 6B  when a packet with an RTP header is received from a tributary  24 , RTP PEP stage  50  (at step  64 ) applies the following logic: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If RTP Start packet 
               
               
                   
                 { 
               
               
                   
                   Store static data 
               
               
                   
                   Send RTP Start Ack packet 
               
               
                   
                 } 
               
               
                   
                 If RTP Start Ack Packet 
               
               
                   
                 { 
               
               
                   
                   Mark conversation as known 
               
               
                   
                 } 
               
               
                   
                 If RTP compressed data packet [Decompress stage 52] 
               
               
                   
                 { 
               
               
                   
                   Decompress data with static info stored for this conversation 
               
               
                   
                 } 
               
               
                   
                 If RTPJitterBuffer configured [Jitter Buffer stage 54] 
               
               
                   
                 { 
               
               
                   
                   Strip timestamp; 
               
               
                   
                   Push data into jitter buffer 
               
               
                   
                 } 
               
               
                   
                 Else 
               
               
                   
                 { 
               
               
                   
                   Push packet into standard IP routing process [step 65] 
               
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
         [0058]    If the packet is pushed into the jitter buffer, it is processed via the standard IP routing process at step  65  when it emerges from the jitter buffer. 
         [0059]    The individual filter, compression and time-stamping schemes will now be described in more detail: 
         [0060]    SIP Filter Stage  32   
         [0061]    The SIP SDP 64 kbit/s codec filtering logic (see  32  of  FIG. 3 ) searches for SDP within SIP signalling messages and strips out any PCMU and PCMA (G7111 64k codec) negotiation and their associated RTPMAP entries from these messages—this should prevent SIP devices selecting 64k codecs to use over the network. The RTPMAP is part of the RFC2327 Session Description Protocol and describes how a media format maps to RTP payload types. 
         [0062]    For this SIP filtering to take place, the SIP signalling stream should be executing in a non-secured format over User Datagram Protocol (UDP). Preferably, SDP messages should be in the ASCII format. 
         [0063]    Codec Filter Stage  34   
         [0064]    When a G729B codec sends data over an RTP stream it typically generates 20 ms samples of 20 bytes (plus RTP/UDP/IP overhead). As previously described, during “normal” conversations, it can be seen that some G729B devices generate smaller samples (of 10 ms) as voice/silence transitions occur. There can be several of these per second even during, for example, “normal” speech. If these voice samples are not forwarded across the network, the perceived voice quality is not greatly affected and the bandwidth required to forward these packets is saved. These packets are silence information descriptors and are typically used for comfort noise generation. They may therefore be discarded (see  34  of  FIG. 3 ) without creating an unacceptable perceived drop in voice quality. 
         [0065]    Compress Stage  36 , Decompress Stage  52   
         [0066]    Previously when RTP traffic was carried across a network, each RTP packet was sent between the IP tributaries as a complete IP/UDP/RTP packet. The format of this packet is: 
         [0000]    
       
         
               
               
               
               
               
               
             
           
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 2 bytes 
                 20 bytes 
                 8 bytes 
                 12 bytes 
                 N bytes 
               
               
                   
                   
               
             
             
               
                   
                 IPTrib 
                 IP Header 
                 UDP 
                 RTP Header 
                 RTP 
               
               
                   
                 Header 
                   
                 Header 
                   
                 Payload 
               
               
                   
                   
               
             
          
         
       
     
         [0067]    Note that the multiplexer header and possible aggregate headers are still prepended to this data before transmission across the network. 
         [0068]    By making assumptions about the contents of portions of the IP, UDP &amp; RTP headers remaining constant throughout an RTP session (conversations), the router may be configured to search for these conversations occurring, inform the IP tributary peer of the contents of the headers, and then avoid sending the constant portions of the headers with each packet—instead just sending a conversation identifier. When the compressed packet arrives at the target IP tributary, the headers are reconstituted and sent on to the ultimate RTP target (for example LAN  11 ) and the RTP sequence and timestamp information is forwarded intact. 
         [0069]    With the identified static data removed from the header (compress stage  36  of  FIG. 3 ), the compressed data sent between the IP tributaries is: 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                 TABLE 3 
               
               
                   
                   
               
               
                   
                 2 bytes 
                 8 bytes 
                 N bytes 
               
               
                   
                   
               
             
             
               
                   
                 IPTrib Header 
                 Compressed RTP Header 
                 RTP Payload 
               
               
                   
                   
               
             
          
         
       
     
         [0070]    Therefore each RTP packet appears on the aggregate  26  with 32 fewer bytes. For G729k packets, this represents a saving of 52%. In uncompressed form, each 20 byte payload is sent between the tributaries as a 62 byte packet. In compressed form, each 20 byte payload is sent between the tributaries as a 30 byte packet. 
         [0071]    When operating, the IP tributary code must look at each packet to be sent to the peer tributary to identify valid packets (IP &amp; UDP checksums) and known conversations. Performance limitations may result. The code will consider any UDP traffic with an even port number (except the SIP port number  5060 ) as RTP traffic. Service management filters should be used to ensure that only RTP port numbers used in the target network are forwarding down an IP tributary  24  with the RTP compression enabled. 
         [0072]    The feature must be turned on at both ends of an IP tributary  24  for the compression to work. If it is enabled on only one end, then all traffic is sent uncompressed and there is no benefit gained—this should be avoided as the performance overhead of looking for the conversations is still there. If the feature is enabled on one end of an IP tributary, but the peer is using older software that does not support the feature, then all RTP traffic will be discarded by the peer unit. 
         [0073]    Timestamp Stage  38 , Jitter Buffer Stage  54   
         [0074]    Some SIP devices are not very tolerant of the large jitter seen in some IP networks, especially satellite networks. This jitter can be removed from an RTP stream that is forwarded through the embedded IP router  12  and across the network  14 . When enabled, any RTP packets that are forwarded from the IP router  12  to an IP tributary  24  are pre-pended with a timestamp (16 bits) in their data payload. This timestamp is sent across the network with each RTP packet, and the timestamp can be used at the peer unit to forward packet onto the ultimate destination at the same frequency that the packets arrived at the original multiplexer. 
         [0075]    Note that this scheme relies on creating timestamps from the clocks on peer routers across the network and using these to control packet synchronization—if these clocks themselves are not synchronized then over long conversations the jitter buffer may overrun or underrun. This could cause glitches in the delivered voice—however if silence suppression is used, then this is unlikely to occur. 
         [0076]    As discussed above, a separate timestamp is used in addition to the RTP timestamp. This avoids the requirement of having knowledge about the format of the standard RTP timestamp which may change according to the type of data being carried across the RTP stream. 
         [0077]    Note that the additional 16 bit timestamp overhead is not included in the packet formats and calculations in the RTP compression section. This additional overhead is only present when the jitter buffering is enabled, however, there is still an overall bandwidth saving even with the timestamps in use. 
         [0078]    The techniques as described above may be executed on any appropriate hardware or in a software implementation. 
         [0079]    These techniques are primarily described in relation to VoIP RTP traffic used for conversation transmission but can readily be used with any form of RTP traffic, for example, any form of media traffic. In particular, the format of the additional time stamp may be tailored for the needs of the data being transmitted. 
         [0080]    The term conversation is used to identify a simplex RTP stream, that is to say any RTP packets in the reverse direction will be provided with their own separate compression establishment mechanism. 
         [0081]    These techniques may also be applied to any appropriate type of network and for any type of conversation or other data session. Specifically, these techniques may be implemented to jitter-buffer any IP application, not just RTP streams. SIP filtering may also be performed for any codec type, not just G.711.