Subject: Re: RE: [rohc] ROHC: Header parsing

From: "Jagan S" <[email-masked]>
Date: Wed, 17 Mar 2004 20:11:32 +0530

Dear LarsErik,

Thanks for the reply.

>There is no way to explicitly know that packet stream is
>an RTP stream, but one will have to guess. The good thing
>with ROHC IP/UDP/RTP compression is that it is lossless,
>independent of if the UDP payload is actually RTP or not.
>One can thus start with assuming RTP, and if the compression
>ratio turns out to be negative for the RTP part, a profile
>switch to IP/UDP-only should be performed (see section 5.11).

>Cheers,
>/L-E

==> Assuming as RTP profile in the begining of transmission & then changing
over to UDP/IP profile,
 leads to packet losses. And moreover, if the profile is other than UDP/IP,
again another changeover
 is requried to another profile. Will this not lead to lower efficiency?

Another issue is: in U mode, it may not be possible to calculate negative
compression ratio,
 due to the absence of feedback. In this case, the compressor keeps sending
compressed packets
 assuming the profile as RTP/UDP/IP !!!

Is my understanding correct ??

~~~~~~~~~~~~~~~~~~~~
Thanks & With warm regards.,

Jagan S Nathan

L&T Infotech, Bangalore.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Thu, 18 Mar 2004 09:06:06 +0100 (CET)

Hi Jagan,

The compressor knows (from the IP header "Protocol"  field) that its
payload contains UDP. However, as you observed, it doesn't know if the
UDP payload contains RTP.

The approach suggested is for the compressor to (optimistically?)
"assume" that the UDP payload contains RTP, and begin transmitting IR
packets for PROFILE 1.

However, as it transmits these IR packets, the compressor should also
observe the UDP payload, and heuristically try to determine whether
this is indeed RTP.

I guess your concern here is that during this time the compressor
could potentially send some "arbitrary" UDP payload content as RTP
fields in the IR packet. However, this shouldn't be a problem since
fields in the IR packet are used verbatim at the decompressor, so the
re-created header should remain the same.

If the stream is indeed RTP, the compressor can start shifting to a
higher state, and begin sending smaller ROHC packets, e.g., UO-0, etc.
If the UDP payload does not resemble RTP, the compressor can continue
sending the IR packets, but now indicate PROFILE 2 instead, after
which, start shifting to a higher state.

At the decompressor-end, no packets are lost/discarded since the
decompressor/decompressor support the same set of profiles, and hence,
all IR packets. There is no need for a feedback channel or "negative
compression ratios" calculations (which I didn't actually quite
follow!).

The tricky-bit is the compressor making an accurate selection of which
profile should be used, and once that is done, whatever ROHC stream it
generates should be decompressable by the other-end decompressor.

Regards,
vick
+----------------------------------------------------+
 Vicknesan AYADURAI <[email-masked]>
 Ericsson Research: IP Networks - Stockholm, Sweden
 Phone :  +46 8 5087 8084 / Fax:  +46 8 404 7020
+----------------------------------------------------+

> Is my understanding correct ??

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Thu, 18 Mar 2004 09:12:34 +0100

> generates should be decompressable by the other-end decompressor.

And note that the choice of compressing RTP is just an additional
compression improvement. It is a matter of compression efficiency,
the compressed stream will be decompressible with either profile,
independent of actual packet stream, and the compressor will see
from the packets (compressed) it generates whether an assumption
of RTP was correct (if all "RTP fields" are changing in a non-RTP
manner all the time, one can conclude that it is not RTP).

/L-E