Multiplex communications – Communication techniques for information carried in plural... – Assembly or disassembly of messages having address headers
Reexamination Certificate
1999-12-30
2003-08-19
Olms, Douglas (Department: 2661)
Multiplex communications
Communication techniques for information carried in plural...
Assembly or disassembly of messages having address headers
C709S247000, C341S060000
Reexamination Certificate
active
06608841
ABSTRACT:
BACKGROUND OF THE INVENTION
Technical Field
The present invention relates to data compression and decompression in a data network and more particularly, relates to a system and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks.
Related Art
In recent years, increased usage of the Internet has resulted in scarcity of network capacity, and compromised performance of traditional applications. At the same time, new applications such as interactive audio and/or video, including video-conferencing or Voice over IP (VoIP) have emerged which demand timely data delivery and much improved quality of service. Real-Time Transfer Protocol (RTP) has been used to obtain inter-operability among different implementations of network real-time applications such as video-conferencing and Voice over IP. For Internet Protocol (IP) based real-time multimedia, RTP may be used on top of User Datagram Protocol (UDP/IP) to make use of multiplexing and checksum services as described in the “
RTP: A Transport Protocol For Real
-
Time Applications
” by Henning Schulzrinne, Stephen L. Casner, Ron Frederick, and Van Jacobson, Request For Comments (RFC) 1889, January 1996. However, there is concern that RTP headers may be too large for acceptable interactive response and line efficiency, when operating over low speed lines such as dial-up modems. For example, in the Internet Protocol version 4 (IPv4), header fields including IP/UDP/RTP may occupy 40 bytes per packet. Likewise, such header fields may occupy 60 bytes per packet in the Internet Protocol version 6 (IPv6). This header-overhead is quite considerable in real-time applications such as conversational voice where the actual voice payload may be as little as 36 bytes (corresponding to 20 ms of GSM coded voice). As a result, such header-overhead needs to be significantly reduced for real-time applications.
Currently, there are few header compression techniques available to compress headers of IP/UDP/RTP datagrams in order to reduce the header-overhead and allow efficient use of bandwidth on low and medium speed links. Most recent example of such header compression techniques is described in the “
Compressing IP/UDP/RTP Headers For Low
-
Speed Serial Links
” by Stephen L. Casner, and Van Jacobson, RFC 2508, February 1999. A header compression mechanism is provided with a compressor/de-compressor for compressing headers of IP/UDP/RTP datagrams to reduce header-overhead to 2-4 bytes. The header compression scheme is based on the observation that most fields of the EP headers remain constant in a packet stream over the life of the connection (i.e., length of a session). Therefore, header compression may be achieved by maintaining a compression state at the de-compressor and by simply transporting a minimal amount of header-overhead (such as a session context identifier and a small sequence number used for error and packet loss detection) from the compressor to the de-compressor. According to RFC 2508, the compression state at the de-compressor may correspond to uncompressed header fields including those that change in every packet and those that do not change in every packet. For the non-changing fields (such as source and destination IP addresses and port numbers), the de-compressor may simply add the corresponding fields stored in the compression state. For the changing fields, however, the de-compressor may rely on the information sent in the compressed packet header. Typically, the information contained in the compressed packet header includes the difference in change with respect to the value of the field in the previous packet (i.e., only non-zero second-order differences of changing fields), and does not include the changed field itself.
For general operation, the compressor starts off by sending full IP/UDP/RTP headers to the de-compressor until the de-compressor establishes a context state for the non-changing fields as well as the first-order difference(s) for the changing fields. Once the context state is established, the compressor need not send the first-order differences (especially those corresponding to RTP header fields such as RTP timestamp and RTP sequence number) unless the second-order difference (delta) is non-zero. When the second-order difference (delta) of the RTP header from packet to packet is zero, the de-compressor can reconstruct a packet without any loss of information by simply adding the first-order differences to the saved uncompressed header representing the previous packet as each compressed packet is received. All that needs to be communicated is a session context identifier (ID) and a small sequence number (not related to the RTP sequence number) in order to maintain synchronization and detect packet loss between the compressor and de-compressor. For example, if the RTP timestamp changes from 20 to 40 to 60 for packets #
1
, #
2
and #
3
, the first-order difference between 20 and 40 and between 40 and 60 is 20. When the initial value of 20 is known, the de-compressor may simply add the correct increment for packet #
3
if an appropriate field in the compressed header indicates that the second-order difference is zero.
On the other hand, if the second-order difference (delta) of the RTP header is not zero for some fields, the new first-order difference for just those fields must be communicated using a compact encoding. The new first-order difference values are added to the corresponding fields in the uncompressed header in the session context of the de-compressor, and are also stored explicitly in the session context to be added to the corresponding fields again on each subsequent packet in which the second-order difference (delta) is zero. Each time the first-order difference changes on subsequent packets, that difference is transmitted and used to update the session context.
However, the header compression scheme as described in RFC 2508 and other RFC documents which contain Internet Standard protocols available to the Internet community are not suitable for operation in environments (such as cellular wireless networks) where bandwidth is at a premium and there are high link errors and high link latencies. The loss of a packet can force the de-compressor to append incorrect header information, such as RTP timestamp and RTP sequence number, to the next successfully received packet. Similarly, if a compressed packet header is in error, similar incorrect reconstruction of an RTP packet can result. For instance, if a packet containing the new first-order difference for a field (or multiple fields) is considered lost (perhaps due to errors), the headers for the subsequent packets cannot be correctly reconstructed until the de-compressor has notified the compressor, and the compressor has successfully re-transmitted the required first-order difference. During this recovery phase, the packets already transmitted and in transit cannot be operated upon for header reconstructions. For real-time applications, such as Voice over IP (VoIP) and Video Conferencing, those packets may be discarded due to the expiration of play-out deadlines. For example, consider a cellular link that has a 60 ms one way delay from the radio access point (such as a base station) to a mobile station (or 120 ms round-trip delay from base station to mobile station and back to base station), and an inter-packet separation between voice packets is 20 ms during a talkspurt. At the start a talkspurt, the RTP timestamp of the very first packet usually increments such that its second-order difference is non-zero due to the silence interval. Therefore, a new first-order difference has to be communicated to the de-compressor in this very first packet. If the packet is somehow lost due to errors, the following three packets (60 ms/20 ms) cannot be reconstructed until the de-compressor informs the compressor about the failure, during which time another three packets would have been transmitted by the compressor (assuming that a talkspurt lasts for at least six packets). All these six packets have to wai
Antonelli Terry Stout & Kraus LLP
Nguyen Van
Nokia Networks Oy
Olms Douglas
LandOfFree
System and method for achieving robust IP/UDP/RTP header... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for achieving robust IP/UDP/RTP header..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for achieving robust IP/UDP/RTP header... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3127312