Subject: RTCP Interval calculations

From: Rafiq Shaikh <[email-masked]>
Date: Wed, 18 Aug 1999 13:01:31 +0530 (IST)

Hi all,

In Section A.7/RFC 1889, consider the following lines:
1) "we_sent: Flag that is true if we have sent data during the last two
    RTCP intervals. If the flag is true, the compound RTCP packet just
    sent contained an SR packet."

If in the last Interval there is no data sent then in that case the
compound RTCP packet just sent will NOT contain the SR. Because, in my
opinion the compound packet is created based on the statistics of last 
interval(NOT last two intervals). So, I think this flag does not
neccessarily indicate whether the last RTCP compound packet contained 
a SR or not.
Please correct me if I am wrong.

2) "members: The estimated number of session members, including ourselves. 
   ..........
   On the first call, this parameter should have the value 1.

If at the first call this parameter should contain the value 1, and
at later stages we have to use the actual number of members in that
session. I could not get in which case we have to use the estimated
value. 
Any clarification?

thanks in advance.

Regards,
-Rafiq.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Aug 1999 09:04:50 -0400

> Please correct me if I am wrong.

No. When the user sends an RTP packet, it sets we_sent to true. Then, it
uses the normal timeout rule for senders to change we_sent back to zero
if no more RTP packets are sent. According to section 6.3.5 of the new
RTP spec, this timeout interval is TWICE the RTCP interval. As a result,
we_sent remains true for 2 RTCP intervals since the last RTCP packet.
Thus, if in the last interval there was no RTP, but in the one before
that there was, the next RTCP packet does contain an SR, as specified.

> 2) "members: The estimated number of session members, including ourselves.

What you are calling "actual number of members" IS the estimate. The
actual number of members is not known definitively by anyone at all
times. This information is completely distributed; the algorithms in the
spec provide ways estimate it reasonably well. However, its an estimate
nonetheless.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Rafiq Shaikh <[email-masked]>
Date: Wed, 18 Aug 1999 20:20:59 +0530 (IST)

Hi Jonathan,

Please see in lines with *** in them:

Regards,
-Rafiq.

> that there was, the next RTCP packet does contain an SR, as specified.

*** Agreed. Does it mean that two consequtive RTCP compound packet will
contain the SR packets, eventhough there was NO RTP transmission during
(let's say) last RTCP interval, because "we_sent" flag is TRUE during two
RTCP Intevals? 

I am refering to the RFC 1889, is it the latest one?
Where can I get the new RTP specs?

---

From: Stephen Casner <[email-masked]>
Date: Wed, 18 Aug 1999 11:12:30 -0700 (Pacific Daylight Time)

On Wed, 18 Aug 1999, Rafiq Shaikh wrote:
> interval(NOT last two intervals).

Your opinion does not match the intention of the RTP spec.  Perhaps
you did not see my message in the earlier phase of this discussion
last week:

    RFC 1890 says:

       The SR is issued if a site has
       sent any data packets during the interval since issuing the last
       report or the previous one, otherwise the RR is issued.

    The reason for "or the previous one" is to give some redundancy in
    case one SR is lost and, if both SR's after the end of data are
    received, to allow the receiver to see that in fact the source has
    stopped sending.

So, I contend that the quote from RFC 1889 is accurate.  However, as I
think about this a bit more, the algorithm doesn't do exactly what one
would want.  If the SR just sent was the second one after the end of
data, then at this point we are acting as a receiver and (unless we
start sending data again) the next RTCP we send will be RR.
Therefore, the next interval we are about to calculate should be based
the receiver fraction, not the sender fraction.

The flipside is that if we have not sent data for a while and we are
sending RR's, then when we start sending data it may be quite a while
before the first SR is sent.  Any receivers that have just joined will
not have a previous SR from us and will not be able to accurately do
inter-media synchronization (e.g., on our audio and video) until it
receives our SRs for those streams.  Perhaps a change in the state of
we_sent from false to true should trigger a "reverse reconsideration"
recalculation of the RTCP interval.

One could say that the first of these problems helps avoid the second
in the case that silences are fairly short (less than two intervals).
Maybe this is not worth worrrying about.

To answer your later question, the RFC spec is being revised for
advancement to Draft Standard status.  The revised spec is in

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-04.ps

The .ps version has changebars.
							-- Steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Aug 1999 23:56:42 -0400

> recalculation of the RTCP interval.

Its a good point, actually. I agree completely that reverse
reconsideration is the right solution, and that this is something worth
worrying about. The first problem you describe is already handled by
forward reconsideration. When the participant goes to send the SR, he
recomputes the interval (now as a receiver), and it will be farther in
the future, delaying transmission of the packet. 

-Jonathan R.