Subject: RE: [rohc] ROHC compression ratio

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 30 Jul 2003 15:55:54 +0100

Hi Alan, Remi,

I remember we had problems with this at the first interop (hence there being a section about it in the implementer's guide).  In my understanding and our implementation; for both the CSRC list (and also for the IP extension header list), there is one byte of zero in the dynamic chain if the list is empty.  

Here is the trace of an IR packet from our implementation (showing the 1 byte lists with ^^^^):
 0: FD 01 57 40 11 00 00 00 00 00 00 00 00 33 73 8F : ý.W@.........3s.
16: 59 15 64 96 E0 E0 26 30 EE 20 00 00 00 90 35 C0 : Y.d.àà&0î ....5À
                                 ^^^^
32: 45 5F CA 6A 56 00 04 00 01 02 03 04 05 06 07 50 : E_ÊjV..........P
                  ^^^^
48: 4B 54 3A 20 20 20 31                            : KT:   1

where the original packet is:
 0: 45 E0 00 38 30 EE 00 00 26 11 62 E8 00 00 00 00 : Eà.80î..&.bè....
16: 00 00 00 00 33 73 8F 59 00 24 00 00 80 35 C0 45 : ....3s.Y.$...5ÀE
32: 5F CA 6A 56 15 64 96 E0 00 01 02 03 04 05 06 07 : _ÊjV.d.à........
48: 50 4B 54 3A 20 20 20 31                         : PKT:   1

Alan, I think you are right that the implementer's guide appears to be contradictory and I believe that implementations that have been interop tested follow 4.3.1 and 4.3.2.  

Regards,

Abbie

>-----Original Message-----
>From: Alan Kennington [mailto:[email-masked]]
>Sent: 30 July 2003 15:29
>To: Remi Pelland
>Cc: ROHC mailing list; Alan Kennington
>Subject: Re: [rohc] ROHC compression ratio
>
>
>On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote:
>> 
>> the RTP part of the dynamic context an empty Generic CSRC 
>List is present
>> although the associated CC field is 0.  Section 4.3.3 of the 
>Implementer's
>> Guide says that when the CC field is 0, the Generic CSRC List is not
>> included in the dynamic chain.
>> 
>
>
>Remi,
>
>Well, that's delightful. That's the first time anyone's checked the
>correctness of my encoding.
>
>Now the ROHC implementer's guide, version 3, part 4.3.1, says
>
>===================================================
>   The generic extension header list starts with an octet that 
>is always
>   present, so its length is one octet, at least.  If the 'GP' bit in
>   the first octet is set to 1 then the length of the list is two
>   octets, even if the list is empty.
>===================================================
>
>Then section 4.3.2 says:
>
>===================================================
>   Section 5.7.7.6 defines the static and dynamic parts of the RTP
>   header.  This section indicates a 'Generic CSRC list' field in the
>   dynamic chain, which has a variable length.  This field 
>uses the same
>   encoding rules as the 'Generic extension header list' in the IPv4
>   header, so the same rules apply to its length.
>===================================================
>
>This seems pretty clear to me - the CSRC list must have at 
>least 1 octet
>even if CC equals 0.
>
>Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide:
>
>===================================================
>   Section 5.7.7.6 defines the static and dynamic parts of the RTP
>   header.  In the dynamic part, a 'CC' field indicates the number of
>   CSRC items present in the 'Generic CSRC list'. It should be noted
>   that when the value of this CC field is equal to zero, there is no
>   Generic CSRC list present in the dynamic chain, i.e. the field
>   comment should have said "variable length, present if CC > 
>0". A 'CC'
>   field can also be found within the 'Generic CSRC list' (when
>   present), and these fields would then have the same 
>meaning. In order
>   to decode a compressed packet correctly it's necessary to know the
>   'CC' value because it has serious impact on the packet's length.  In
>   normal case, the values of the fields are equal.
>
>   Proposed behavior if the values are different:
>      Both fields are within the RTP dynamic part but only the second
>      'CC' field resides inside the 'Generic CSRC list' together with
>      the XI items.  Since the 'CC' value determines the number of XI
>      items in the CSRC list and isn't used otherwise, the first CC
>      field should be ignored and only the second field 
>(inside the CSRC
>      list) should be used for incoming packets.  For outgoing packets
>      both fields should be set to the same value.
>===================================================
>
>So this means that if CC == 0, then the CSRC list is not present.
>This is very confusing. It seems to me that even the "clarifications"
>in the Implementer's guide might be contradictory.
>
>So what is the real answer?
>
>Salut aussi,
>Alan Kennington.
>
>--------------------------------------------------------------------
>     nom: Dr. Alan Kennington
> website: http://www.topology.org/
>   ville: Adelaide, Australie Me'ridionale
>  coords: 138.59 E, 34.88 S
>zone UTC: +0930 http://www.topology.org/site/timezone.html
>clef-pgp: http://www.topology.org/ak/key_ak2.asc
>    note: Mon adresse de courriel se change souvent a` cause du spam.
>        : Si votre courriel bounce, visiter SVP 
>topology.org/extra/email.php
>
>_______________________________________________
>Rohc mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rohc
>

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

---

From: Alan Kennington <[email-masked]>
Date: Thu, 31 Jul 2003 00:44:38 +0930

> Alan, I think you are right that the implementer's guide appears to be contradictory and I believe that implementations that have been interop tested follow 4.3.1 and 4.3.2.  

Abigail,

Hellelujah! I can't believe I got this right considering that I'm working
in isolation in the deserts of South Australia with only the RFCs to go by.
(Well, to be honest, it's been pouring with rain here for the last 3 days...)

Cheers and thanks,
Alan Kennington.