Re: [rohc] Generic CSRC List Issue

[Klaus Warnke <klaus.warnke at acticom.de>]

At Wed, 19 Aug 2009 16:16:25 +0530,
Gurushant wrote:
> 
> Hi Klaus,
> Thanks for the quick reply.

You're welcome.

> But we are adding one extra byte ( 0x00) unnecessarily when the CC
> indicates that there is no CSRC value.

This is true. This wastes on octet. But if you are not wasting this
octet, your RoHC will not able to talk "RTP" with other RoHC stacks.

> I think everybody who reads RoHC RFC, they understand that "/" means
> it is variable, how feasible it to mandate to at least one byte for
> the "/" meaning. Specially in this example , isn't the understanding
> differs.

Yes. But this is the reason why this case is extra clearified in the
rfc4815:

    This field is always at least one octet in size, even if the list
    is empty

This was a try to find a explanation why.

> I am wondering, is there any special purpose to add one octet in
> case generic CSRC list. I understand in case of Generic Extension
> Header list one octet makes sense as there is no previous bytes or
> information to indicates its presence.

Fields, which are variable and optional are looking like:

   +---+--- ---+---+---+--- --- ---+
   :                               :
   /    0, 1, or 2 octets of CID   /  1 or 2 octets if (large CIDs)
   :                               :
   +---+---+---+---+---+---+---+---+

or 

   +---+---+---+---+---+---+---+---+
   :             Size              :  if Code = 0
   +---+---+---+---+---+---+---+---+

That means, if Code == 0, Size is present. But 

      +---+---+---+---+---+---+---+---+
      /      Generic CSRC list        /  variable length
      +---+---+---+---+---+---+---+---+

looks different.

This isssues are one of the reasons to define RoHCv2 not with ascii
boxes and text but with a formal notaion.

br
Klaus
> 
> Thanks & Best Regards
> Gurushant.Kotagi
> 
> 
> -----Original Message-----
> From: Klaus Warnke [mailto:klaus.warnke at acticom.de]
> Sent: Wednesday, August 19, 2009 3:54 PM
> To: gurushant at tataelxsi.co.in
> Cc: rohc at ietf.org
> Subject: Re: [rohc] Generic CSRC List Issue
> 
> 
> Gurushant,
> 
> > If I am correct the last line "as opposed to the CSRC list in the
> > uncompressed RTP header, which is not present when the RTP CC field
> > is set to 0" , does it mean that for IR packet , one octet( first
> > byte) of generic scheme need not present.
> 
> No. If the CC field (CSRC count) in the original RTP header is set to
> zero, there is no CSRC item at the end of the original RTP header
> present. Then the CC field at the beginning of the RTP IR dynamic part
> is also set to zero, but you can not omit the first octet of the
> generic CSRC list. Set it simply to 0x00 (ET=0, GP=0, PS=0,
> CC=0). That is, what the RFC4815-5.1. says.
> 
> I think, that the definition of the "/" means at least of octet
> (3095. p 43 (in the diagram, slashes "/" indicate variable length))
> where the ":" is defined (p. 42 (in the diagram, colons ":" indicate
> that the part is optional)) means it can be omitted. But the generic
> CSRC list field is surround by "/".
> 
> br
> Klaus
> 
> At Wed, 19 Aug 2009 14:59:24 +0530,
> Gurushant wrote:
> >
> > Dear All,
> >
> > We have one small issue while understanding the following information from
> > the RTP implementation guidelines. Kind request you clarify on the last
> > sentence mentioned in below paragraph.
> >    Section RFC3095-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 (see section RFC3095-
> >    5.8.6). This field is always at least one octet in size, even if the
> >    list is empty (as opposed to the CSRC list in the uncompressed RTP
> >    header, which is not present when the RTP CC field is set to 0).
> >
> > If I am correct the last line "as opposed to the CSRC list in the
> > uncompressed RTP header, which is not present when the RTP CC field is set
> > to 0" , does it mean that for IR packet , one octet( first byte) of
> generic
> > scheme need not present.
> >
> > Thanks
> > Gurushant