Subject: RE: [AVT] RTCP Implementation?

From: [email-masked]
Date: Wed, 27 Mar 2002 08:01:09 +0200

Hi,

thanks Colin, Steve and Joerg for your clarifications. In general I agree that it is always more useful to use RTCP than not using it :)

However, I would like to get a better understanding on the following statement:

draft-ietf-avt-rtp-new-11.ps Page 19, Section 6.2 and 
draft-ietf-avt-rtcp-bw-05.txt, Section 1:
"Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. This may be appropriate for systems operating on unidirectional links or for sessions that don't require feedback on the quality of reception."

I have the impression that if one tries to implement the above text, then there is the risk to break the RTP spec in another place.

Can the above text be clarified in both specs telling that

1. In general, it is NOT RECOMMENDED to turn off RTCP report; or/and
2. Specify more clearly in which cases the text is applicable?

Thanks.

Regards,

Igor

-----Original Message-----
From: ext Colin Perkins [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 5:12 PM
To: Curcio Igor (NMP/Tampere)
Cc: [email-masked]
Subject: Re: [AVT] RTCP Implementation? 

Hi,

Section 6 of draft-ietf-avt-rtp-new-11.txt has a long explanation of why
RTCP "SHOULD be used". I strongly recommend that all implementations use
RTCP, for the reasons described there, and to aid forward compatibility
with more advanced uses of RTP. 

An RTCP implementation is not especially complex, and there is open source
example code which can help (contact me off-list for details).

Colin

--> [email-masked] writes:
>Hi,
>
>my understanding is that you have to implement RTCP, but not use it if you
>don't need it. For example, using SDP BW modifiers you can set the receiver
>BW to zero and turn off the receiver reports. Now, since no lip synch is
>needed on a single voice media flow, probably also SRs can be turned off,
>in a point-to-point connection.
>
>So, the issue here is: you implement RTCP, but you don't use it. And if
>you don't use it, you would not need to implement it. Or did I miss
>anything?
>
>Regards,
>
>Igor Curcio
>
>
>-----Original Message-----
>From: ext Colin Perkins [mailto:[email-masked]]
>Sent: Monday, March 25, 2002 9:46 PM
>To: Srikrish
>Cc: [email-masked]
>Subject: Re: [AVT] RTCP Implementation? 
>
>
>--> "Srikrish" writes:
>>Hello,
>>
>>  I have a question on RTCP implementation.
>>  Will appreciate answers/suggestions on this regard.
>>
>>  Is it common trend to implement RTCP
>>  in all RTP implementation?
>>
>>  In otherwords, if the solution needs
>>  only realtime voice and have enough
>>  bandwidth, is it mandatory to implement
>>  RTCP?
>
>Yes.
>
>Colin
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

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

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 27 Mar 2002 07:05:58 -0500

> Hi,

Hello;

   I am going to give my own viewpoint, from out in the
field.

   1.) Many RTP implementations are for streaming media,
where you have one or a few sources and (hopefully) many
receivers. In the classic RTCP scenario, all of those
receivers are also sources, in that they send receiver
reports (and maybe source reports, and maybe APP traffic as
well).

    Many people are dubious about the amount of multicast
state that this requires, which is I believe what motivates
the text you quote below.

    2.) SSM will require (and point # 1 above will motivate
for ASM) sending of receiver reports unicast back to the
source. There is a draft concerning this, and at least two
implementations (ours, and Cisco's IPTV), that do this now.

There are some serious security implications with this that
have yet to be fully worked out.

    3.) At least in streaming RTP media, proper RTCP
implementations are few and far between. At least in this
space, RTCP is effectively broken.

The best proof  I can give of this is that I don't know the
size of my groups to better than one or even two orders of
magnitude, and I have spent a lot of time and effort trying
to figure this out. (The _reporting_ audience for On-the-I
audio at Cisco.com, for example, dropped by two orders
of magnitude when IPTV defaults changed from multicast RTCP
to unicast or no RTCP, for example.)

In addition, about 1/2 of the actual receiver reports we
do receive are improper or incomplete in some fashion.

So, I highly recommend that you implement the RTCP specs,
but you cannot assume that others have.

Regards
Marshall Eubanks

> 
> thanks Colin, Steve and Joerg for your clarifications. In
> general I agree that it is always more useful to use RTCP
> than not using it :)
> 
> "Using two parameters allows RTCP reception reports to be
> turned off entirely for a particular session by setting
> the RTCP bandwidth for non-data-senders to zero while
> keeping the RTCP bandwidth for data senders non-zero so
> that sender reports can still be sent for inter-media
> synchronization. This may be appropriate for systems
> operating on unidirectional links or for sessions that
> don't require feedback on the quality of reception."
> 
> I have the impression that if one tries to implement the
> above text, then there is the risk to break the RTP spec
> in another place.
>

---

From: Orion Hodson <[email-masked]>
Date: Wed, 27 Mar 2002 09:11:30 -0800

/-- "Marshall Eubanks" wrote:
| 
| So, I highly recommend that you implement the RTCP specs,
| but you cannot assume that others have.

Alternatively, since it's hard to implement RTCP correctly you might save a 
lot of time and effort by re-using existing code.  There are several libraries 
out there you can use in a range of languages and under assorted licensing 
agreements, eg, see list at:
	http://www.cs.columbia.edu/~hgs/rtp/

Cheers
- Orion

---

From: Chuck Harrison <[email-masked]>
Date: Wed, 27 Mar 2002 16:47:16 -0800

FYI.

News, links to companies active in field, etc.

http://www.streamingmedialand.com/

Cheers,
  Chuck Harrison
  Far Field Associates, LLC