RE: [AVT] RTCP Implementation?

[[e-mail]]

Marshall: thank you very much for replying.  I do not think that I expressed myself very well.  The question is:

Is SDP used to communicate the port number (s) used by the RTP streams?  It is certainly capable of doing this.  There may be other protocols which can also do it.

I initially thought that RTCP SDES packets were essential to find the various RTP streams which comprise a presentation.  I now think that RTCP is not essential when multiple port numbers I used to multiplex RTP streams.

Is this correct (RTCP is not essential)?

Best regards, Steve

> -----Original Message-----
> From: Srikrish [mailto:[e-mail]]
> Sent: Wednesday, May 08, 2002 3:35 PM
> To: Marshall Eubanks; McRobert, Steve
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [AVT] RTCP Implementation?
> 
> 
> 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:[e-mail]]
> Sent: May 8, 2002 3:19 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail];
> [e-mail]
> Subject: Re: [AVT] RTCP Implementation?
> 
> 
> 
> 
> [e-mail] wrote:
> 
> > 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".
> >
> 
> 
> 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.
> 
> 
> > 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 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
> 
> 
> > 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:[e-mail]]
> >>Sent: Wednesday, March 27, 2002 4:06 AM
> >>To: [e-mail]; [e-mail];
> >>[e-mail]
> >>Cc: [e-mail]; [e-mail]; [e-mail];
> >>[e-mail]
> >>Subject: Re: [AVT] RTCP Implementation?
> >>
> >>
> >>On Wed, 27 Mar 2002 08:01:09 +0200
> >> [e-mail] 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:[e-mail]]
> >>>Sent: Tuesday, March 26, 2002 5:12 PM
> >>>To: Curcio Igor (NMP/Tampere)
> >>>Cc: [e-mail]
> >>>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
> >>>
> >>>
> >>>
> >>>
> >>>--> [e-mail] 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:[e-mail]]
> >>>>Sent: Monday, March 25, 2002 9:46 PM
> >>>>To: Srikrish
> >>>>Cc: [e-mail]
> >>>>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
> >>>>[e-mail]
> >>>>https://www1.ietf.org/mailman/listinfo/avt
> >>>>
> >>>>_______________________________________________
> >>>>Audio/Video Transport Working Group
> >>>>[e-mail]
> >>>>https://www1.ietf.org/mailman/listinfo/avt
> >>>>
> >>>_______________________________________________
> >>>Audio/Video Transport Working Group
> >>>[e-mail]
> >>>https://www1.ietf.org/mailman/listinfo/avt
> >>>
> >>
> >>_______________________________________________
> >>Audio/Video Transport Working Group
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/avt
> >>
> >>
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> 
> 
> --
>                                   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 : [phone]       Fax     : [phone]
> e-mail : [e-mail]
> 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
> 
> 
> 


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