Subject: RTP/RTCP

From: Sylvie Brunelle <[email-masked]>
Date: Wed, 01 Mar 2000 17:31:09 +0000

Hi evrybody,

I have just arrived in this mailing list. I read the RFC 1889 and the
RTP FAQ but I still have some questions concerning RTP/RTCP.

I was wondering if the 5 seconds limit for the RTCP transmission
interval is definite. I think so (cf. Annex 7) but I prefer to check.

Otherwise how will that be in the case of the unicast case? Is the limit
of 5 seconds still in use?

RTP and RTCP use different port but what about the multicast address? I
think they have the same one. Is that right?

Cheers,

Sylvie

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Mar 2000 13:52:04 -0500

> interval is definite. I think so (cf. Annex 7) but I prefer to check.

I'm not sure what you mean by "definite". The interval actually depends
on the group size and on the RTCP transmission rate that has been
allocated. Given a 5% allocation, as specified in rfc1889, the minimum
interval is 5 seconds on average. The actual interval is randomly varied
between 1/2 and 3/2 of the 5 seconds.

> of 5 seconds still in use?

The same applies for unicast. 

> think they have the same one. Is that right?

Yes, same multicast address.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Wed, 1 Mar 2000 20:43:06 +0100 (MET)

> > interval is definite. I think so (cf. Annex 7) but I prefer to check.

    jdrosen> I'm not sure what you mean by "definite". The interval
    jdrosen> actually depends on the group size and on the RTCP
    jdrosen> transmission rate that has been allocated. Given a 5%
    jdrosen> allocation, as specified in rfc1889, the minimum interval
    jdrosen> is 5 seconds on average. The actual interval is randomly
    jdrosen> varied between 1/2 and 3/2 of the 5 seconds.

Part 5 of 6.3.1 (RFC 1889) says 
  
      The resulting value of T is divided by e-3/2=1.21828

This seems to mean that in this case the interval is randomly varied between 

     1/(2* (e-3/2)) and 3/((2* (e-3/2)) of 5 seconds

 > > of 5 seconds still in use?

    jdrosen> The same applies for unicast.

I couldn't figure out which parts of sections 6.2 and 6.3 are
mandatory for unicast and which ones aren't. Under 6.3:

       An implementation that allows operation in
       a multicast environment or a multipoint unicast environment 
       MUST meet the scalability goals described in Section 6.2
 [...]
       An implementation which is constrained to two-party unicast 
       operation MAY omit this algorithm.

The hard part is figuring which parts of 6.2 are "scalability goals"
and which parts aren't. 6.3.1 specifies how to calculate the RTCP
transmission interval, but again it seems to be addressing the same
scaleability goals that unicast implementations are allowed to ignore.

I wound up implementing the algorithm for multicast because that
seemed easier than guessing which parts of the spec apply to
unicast and which parts don't, but I'd be interested to hear an
interpretation of the spec which lets me do something simpler.

Matthias

---

From: Stephen Casner <[email-masked]>
Date: Wed, 1 Mar 2000 17:50:51 -0800 (Pacific Standard Time)

> of 5 seconds still in use?

This has been modified in the Internet-Draft which revises RFC 1889,
draft-ietf-avt-rtp-new-06.txt and .ps, though there are still
recommended constraints.

> think they have the same one. Is that right?

Same.  The idea of using different ones for some applications has been
discussed at various points in RTP's development, but to this point,
we have decided not to add that complication.
							-- Steve

---

From: Stephen Casner <[email-masked]>
Date: Wed, 1 Mar 2000 17:59:49 -0800 (Pacific Standard Time)

>      1/(2* (e-3/2)) and 3/((2* (e-3/2)) of 5 seconds

Hmmm, I suppose the 5 second constant should be multiplied by (e-3/2)
to compensate.  Details, details.

>        operation MAY omit this algorithm.

Specifically, "this algorithm" is referring to the "timer
reconsideration" algorithm.

> scaleability goals that unicast implementations are allowed to ignore.

We should make this more clear.

> interpretation of the spec which lets me do something simpler.

I'm glad you did!  I'd like to see all implementations be prepared to
operate in multicast mode because sooner or later somebody is likely
to take an implementation that was not prepared for multicast and use
it with multicast, causing problems.  That's a philosophy we tried to
evoke in the RTP spec without mandating it.
							-- Steve