Subject: RE: [AVT] RTCP Implementation?

From: [email-masked]
Date: Wed, 8 May 2002 10:40:37 -0700

Subject: how is the port number for each RTP stream communicated to the recipient?

AVT: it has been stated in an e-mail to this group that "At least in streaming RTP media, proper RTCP
mplementations are few and far between. At least in this space, RTCP is effectively broken".

RFC 1899 states "Receivers also
             require the CNAME to associate multiple data streams from a
             given participant in a set of related RTP sessions, for
             example to synchronize audio and video."

RTCP does not provide a mechanism to allocate and communicate the port number used by each one of these multiple streams.  To the best of my limited knowledge SDP is used to communicate the port number of each stream in a session to a receiving host.  Given that, it appears that the use of CNAME to associate multiple data streams is redundant.  This would explain why RTP can be successfully implemented without RTCP.

I am not saying that RTCP should not be used.

I am asking the question: if it is not used, is the association performed using SDP in the majority of implementations?

Best regards, Steve

> -----Original Message-----
> From: Marshall Eubanks [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 4:06 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [AVT] RTCP Implementation?
> 
> 
> On Wed, 27 Mar 2002 08:01:09 +0200
>  [email-masked] wrote:
> > 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 :)
> > 
> > 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
> 
> 
> _______________________________________________
> 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, 08 May 2002 18:18:39 -0400

> mplementations are few and far between. At least in this space, RTCP is effectively broken".

I was referring to the lack of proper implementation of receiver reports 
in RTP, and to the lack of a final standard with interoperable 
implementations for unicast rtcp traffic.

> RTCP does not provide a mechanism to allocate and communicate the port number used by each one of these multiple streams.  To the best of my limited knowledge SDP is used to communicate the port nu…

I am not getting something here.
How would you listen to either RTP or RTCP traffic without knowing the 
port ? At least one port has to be transmitted out of band.

Marshall

-- 
                                  Regards
                                  Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html

---

From: "Srikrish" <[email-masked]>
Date: Wed, 8 May 2002 15:35:28 -0700

How will Port information communicated between 2 RTP/RTCP implementations?
If this is your
question then the answer is,

There will be out of band signalling protocols(like MGCP, H.323(not sure
about this)) which has
fields to carry port information.

example: In MGCP there are SDP fields to carry UDP Port information.

These protocols will setup RTP/RTCP sessions before actual bearer path takes
over.

Regards
Sriks

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]]
Sent: May 8, 2002 3:19 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [AVT] RTCP Implementation?

> RTCP does not provide a mechanism to allocate and communicate the port
number used by each one of these multiple streams.  To the best of my
limited knowledge SDP is used to communicate the port number of each stream
in a session to a receiving host.  Given that, it appears that the use of
CNAME to associate multiple data streams is redundant.  This would explain
why RTP can be successfully implemented without RTCP.

Marshall

> I am asking the question: if it is not used, is the association performed
using SDP in the majority of implementations?

--
                                  Regards
                                  Marshall Eubanks

T.M. Eubanks