Subject: RE: [AVT] Doubts in RTCP

From: Stephen Casner <[email-masked]>
Date: Thu, 19 Dec 2002 17:01:08 -0800 (PST)

I'm preparing the set of "RFC Editor notes" to accompany the RTP spec
and RTP A/V Profile drafts so they can get final approval from the
IESG.

    draft-ietf-avt-rtp-new-11.txt
    draft-ietf-avt-profile-new-12.txt

Reaching quite a while back in time here, one of the item to be fixed
was the problem identified in the message below.

At the time, I agreed that this was a bug.  I have now figured out
that it is not.  The text in Appendix A.1 that precedes the C code
says (in words) that the following initialization is to be done when a
new source is first heard:

    s->max_seq = seq - 1;
    s->probation = MIN_SEQUENTIAL;

I think Michel Lépine assumed instead that the initialization was
accomplished just by calling init_seq() which sets max_seq = seq.  It
might be reasonable to make that call first to initialize other
variables, but that is not a complete initialization because it does
not set s->probation (besides not setting max_seq to the needed
value).

So, I think the problem is just that some of the initialization was
not sufficiently apparent because it was written inline in the text.
My proposal is to extract the two lines of code above from the text so
they stand out better, and precede them with a call to init_seq() to
set the other variables:

OLD:
   When a new source is heard for the first time, that is, its SSRC
   identifier is not in the table (see Section 8.2), and the per-source
   state is allocated for it, s->probation should be set to the number
   of sequential packets required before declaring a source valid
   (parameter MIN_SEQUENTIAL ) and s->max_seq initialized to seq-1 s-
   >probation marks the source as not yet valid so the state may be
   discarded after a short timeout rather than a long one, as discussed
   in Section 6.2.1.

NEW:
   When a new source is heard for the first time, that is, its SSRC
   identifier is not in the table (see Section 8.2), and the per-source
   state is allocated for it, s->probation should be set to the number
   of sequential packets required before declaring a source valid
   (parameter MIN_SEQUENTIAL) and other variables are initialized:

       init_seq(s, seq);
       s->max_seq = seq - 1;
       s->probation = MIN_SEQUENTIAL;

   A non-zero s->probation marks the source as not yet valid so the
   state may be discarded after a short timeout rather than a long one,
   as discussed in Section 6.2.1.

Does that sound like a reasonable solution?  (Note that I also fixed a
glitch in the processing from LaTeX to nroff that lost a few words.)

                                                        -- Steve

p.s. In case you noticed that MIN_SEQUENTIAL is defined with scope
local to update_seq() so it would be undefined for the initialization
above, well, maybe we'll just consider that an exercise for the
reader.

On Thu, 7 Mar 2002, Michel Lépine wrote:

>
> Hi all,
> I think there is one thing that still need to be clarified
> about the packet lost algorithm in 1.
>
> Reading draft-ietf-avt-rtp-new-11.txt and looking to the
> example below, computing packet lost seems right but....
>
> Considering an example similar to the one given bellow,
> if there was 0 (zero) packet received, max_seq would be
> equal to base_seq and cycles equal to 0. Then the number
> of packet lost would be 1 which is impossible since we
> didn't receive any packet...
>
> Is that ok ?
>
> Anybody think that particular case should be documented ?
>
>
> _______________________________________
> Michel Lépine
> Software Designer
> Mediatrix Telecom, Inc.
> 4229 Garlock Street
> Sherbrooke (Quebec)
> Canada J1L 2C8
> Tel...: (819) 829-8749 EXT. 264
> Fax...: (819) 829-5100
> Email.: <mailto:[email-masked]>
>
>
>
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:[email-masked]]
> > Sent: Thursday, September 06, 2001 12:04 PM
> > To: Angai
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [AVT] Doubts in RTCP
> >
> >
> > Hi,
> >
> > Have you also looked in
> > http://search.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-10.txt
> > This clarifies a lot of things much better than RFC 1889
> >
> > Anyway, the answers to your questions is:
> > 1.
> > If you don't add the one, you will miss counting the first packet.
> > example
> > max_seq = 9
> > cycles = 0
> > base_seq = 4
> >
> > You should have received all packets from seq nr 4 to 9
> > which is 6 packets
> >
> > 9-4 = 5, i.e. you need to add for the first packet.
> >
> > 2. It is in 1/65536 fractions, which looks similar to NTP 32
> > bits but DLSR
> > is an relative time
> > not an absolute one. Yes, the high 16 bits will be seconds, the low
> > fractions of a second.
> > See also figure 2 in the RTP-new draft.
> >
> > 3.  If CC has an value you know that CC*4 bytes are used for
> > CSRC's in a
> > valid packet. Also the payload type can give at least minimum sizes
> > possible for it. Some audio codecs only have certain valid
> > increments of
> > size. If the sum of the RTP header+CC*4+min payload is larger than the
> > received packet, than it can't be a valid packet.
> >
> > Regards
> >
> > Magnus Westerlund
> >
> > Angai wrote:
> >
> > > Hi  all ,
> > >
> > > Doubts regarding implementation of rtcp :
> > >
> > > 1.In  algorithm  A.3  of rfc 1889
> > >    extended_max = s->cycles + s->max_seq  ;
> > >    expected = extended_max - s->base_seq + 1 ; --> Why this
> > 1 is added
> > > here ?
> > >
> > > 2.Regarding calculation of DLSR :
> > >      I have 64 bits of NtpTime  format .When i find that
> > difference the
> > > value is 64 bits 32 bit secs and 32bit fractions .
> > >       In Rfc it is given " expressed in units of  1/65536 seconds ".
> > >       Whether i should take MidNtp( i.e 16 bit of secs and
> > 16 bits of
> > > frac as i do for last SR )
> > >
> > > 3.In RTP Data Header Validity check what does this statement means :
> > >     "The length of the packet must be consistent with CC and payload
> > > type "
> > >
> > > Thanks in advance
> > > Regards
> > > Angai

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt