Subject: RE: [AVT] Doubts in RTCP

From: Michel Lépine <[email-masked]>
Date: Thu, 7 Mar 2002 11:12:18 -0500

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]
> > http://www1.ietf.org/mailman/listinfo/avt
> 
> --
> 
> Magnus Westerlund
> 
> Audio Technology, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: 
> [email-masked]
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/avt
> 

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

---

From: Stephen Casner <[email-masked]>
Date: Mon, 18 Mar 2002 12:19:48 -0800 (PST)

> didn't receive any packet...

You are right.  This is a bug.  I have not figured out the right
solution yet, though.
							-- Steve

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 18 Mar 2002 17:22:47 -0500

I am reviewing this draft, but I wanted to pass this
comment along before the meeting  :

On Tue, 12 Mar 2002 14:04:55 +0000
 Colin Perkins <[email-masked]> wrote:
> 
> Well, for those applications that can work with unicast
> RTCP, there's
> draft-ietf-avt-rtcpssm-00.txt which describes exactly
> that. Comments
> would be appreciated, before it goes to last call in AVT.
> 
> Colin
> 

Dear Colin; 

   This comment surprised me, as this draft makes reference
to not being complete - particularly in the security 
section :

11.6 Overview of existing security solutions 
    
   This section addresses some existing group security
mechanisms and 
   identifies which aspects of the security requirements
they might 
   provide. This security analysis is a work in progress,
and these 
   options will be explored in more detail in subsequent
versions of 
   the draft. 

and later

 " These options will be considered individually in later
releases of 
   the draft. "

This does not sound like a last call ready document to me.

More will follow.

Regards
Marshall Eubanks

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Mar 2002 11:35:10 -0600

Marshall,

My comment was not meant to imply that the draft is complete. Rather, that
comments were solicited to prepare it for last call. 

Colin