Subject: [rohc] how to find the real RTP head from UDP payload ?

From: "LI_JING" <[email-masked]>
Date: Mon, 5 Sep 2005 15:33:21 +0800

Hi,experts,

    There is a question which I feel puzzled on relization of RHC3095:

    Suppose the profile which is active now is IP/UDP/RTP, we have to guess the part in UDP

payload whether it's a RTP header or it's just the real payload of UDP head.

    As we know, we get some conditions to differ from above cases with judgement as Sou/Des IP address, Sou/Des UDP (even )port ID.  But, it seems not enough to solve the problem.

    Some colleagues suggest to judge from the change regularity of the coming data head.That is
to say, if the current active profile is IP/UDP/RTP,but the part in beginning part of UDP payload changes unregularly,we guess it belong to UDP real paylaod data instead of RTP header.

Sounds reasonable, but how to define the threshold of "unregularly" for the data after UDP 

header ?

     and a further question is:

     if the part is real RTP head,but we guess wrong so to deal it as UDP real payload.so we only get a little bit compress efficiency loss.

     if the part is real UDP payload, but we guess wrong so deal it as a RTP header.Trouble comes ! we have to setup context regularly because the so called"RTP head" changes regularly

with any rule.

     I hope to get your ideas.

　　　　　　　　　　　　　　
> Regards
> 
> LI JING
> [email-masked]
> *****************************************************************
> This e-mail and its attachments contain confidential 
> information from DATANG MOBILE, which is intended only for the 
> person or entity whose address is listed above. Any use of 
> the information contained herein in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in 
> error, please notify the sender by phone or email immediately 
> and delete it!  Thank you.
> *****************************************************************

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Mon, 5 Sep 2005 15:52:39 +0200

Hi,

See some comments in-line.

Note that often, the answers that you are looking for can be found in the ROHC archives at:
http://www.ietf.org/mail-archive/web/rohc/current/index.html
(this is where you should look first, it's often worth it)

Mvh Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of LI_JING
> Sent: den 5 september 2005 09:33
> To: rohc
> Subject: [rohc] how to find the real RTP head from UDP payload ?
> 
> 
> Hi,experts,
> 

Correct. A compressor has to guess that the UDP payload is RTP.
This is called a heuristic guess, and it is ok to do this
because ROHC and its encoding methods guarantee bit-wise transparency.

>
>     As we know, we get some conditions to differ from above 
> cases with judgement as Sou/Des IP address, Sou/Des UDP (even 
> )port ID.  But, it seems not enough to solve the problem.
> 
>     Some colleagues suggest to judge from the change 
> regularity of the coming data head.That is
> to say, if the current active profile is IP/UDP/RTP,but the 
> part in beginning part of UDP payload changes unregularly,we 
> guess it belong to UDP real paylaod data instead of RTP header.
> 

The compressor can determine this, based on if it achieves the
expected level of compression efficiency after trying to compress
some packets in the flow.

>      if the part is real RTP head,but we guess wrong so to 
> deal it as UDP real payload.so we only get a little bit 
> compress efficiency loss.

Correct. The RTP headers simply won't be compressed.
 
>      if the part is real UDP payload, but we guess wrong so 
> deal it as a RTP header.Trouble comes ! we have to setup 
> context regularly because the so called"RTP head" changes regularly
> with any rule.

RoHC is transparent, so the only "problem" will be that you will not achieve the expected compression, and possibly have a small expension by sending IR packets until the compressor switches from profile 1 to profile 2 (non-RTP UDP compression) for that flow (i.e. for that IP source/destination address and UDP source/destination ports combination -> the STATIC-DEF fields).

Read also this old but still valid text from M. Degermark a long long time ago:

    (As a side note, with RTP header compression, a random
    compressor/decompressor pair does not even know the UDP packets it is
    passing are really RTP at all, so, as long as we are making this
    assumption only heuristically, we have an even stronger requirement
    to maintain bitwise transparency.)

    The compressor can heuristically guess which streams are RTP and
    compress those. There is no problem doing that even if the heuristic
    guesses wrong, as long as bit-wise transparency is maintained.

I hope this helps you somewhat.