Re: Generic CSRC List Issue
Klaus Warnke <[email protected]> Wed, 19 Aug 2009 12:24:10 +0200
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <umy5wp0dx.wl%[email protected]> |
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