From: Mas Kato (tealp729@xxxxxxxx)
Date: Sun Jun 03 2001 - 17:21:42 GMT-3
At the risk of oversimplification, I would say the compression scheme is
analogous to MPEG2, where for the most part, an uncompressed header is
initially sent and then only the differences between subsequent headers
is transmitted in the compressed headers. The streams are
compressed/decompressed link-by-link and different streams are tracked
by a "context ID."
See RFC-2508 for all the gory details:
ftp://ftp.isi.edu/in-notes/rfc2508.txt.
Mas
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Roman Rodichev
Sent: Sunday, June 03, 2001 12:06 AM
To: ccielab@groupstudy.com
Subject: RTP header compression
This question was bothering me for a long time. RTP header compression
reduces IP/UDP/RTP header size from 40 bytes to 2-4 bytes. I suppose
that
happens only each hop (between two adjacent routers). I still don't
understand how receiving router will recognize what's in the packet?
Does
anyone know approximate header structure of the header-compressed RTP
packet?
IP header is 20 bytes.
1-Version,1-TOS,2-Length,2-ID,2-Fragm,1-TTL,1-Type,2-Checksum,4-Source,4
-Dest.
If the header gets compressed down to 2 bytes (including UDP and RTP),
how
will receiving router identify that it is an IP packet, that it has
protocol
number 17 (UDP) and what the source/destination is?
Is there a different Ethertype or something? I don't get it
Roman
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:17 GMT-3