Re: [AVT] RTCP Implementation?

steve.mcrobert@amd.com wrote:

> 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.
> 

Yes.

In what we do, we typically send multiple streams in multiple groups, so
groups as well as ports are communicated with SDP.

(A QT .mov file is a stock SDP file with a header.)

Marshall

> 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:Srikrish@rapid5.com]
>>Sent: Wednesday, May 08, 2002 3:35 PM
>>To: Marshall Eubanks; McRobert, Steve
>>Cc: igor.curcio@nokia.com; jo@informatik.uni-bremen.de;
>>casner@packetdesign.com; avt@ietf.org; csp@isi.edu; jo@ipdialog.com
>>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:tme@multicasttech.com]
>>Sent: May 8, 2002 3:19 PM
>>To: steve.mcrobert@amd.com
>>Cc: igor.curcio@nokia.com; jo@informatik.uni-bremen.de;
>>Srikrish@rapid5.com; casner@packetdesign.com; avt@ietf.org; 
>>csp@isi.edu;
>>jo@ipdialog.com
>>Subject: Re: [AVT] RTCP Implementation?
>>
>>
>>
>>
>>steve.mcrobert@amd.com 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:tme@multicasttech.com]
>>>>Sent: Wednesday, March 27, 2002 4:06 AM
>>>>To: igor.curcio@nokia.com; jo@informatik.uni-bremen.de;
>>>>Srikrish@rapid5.com
>>>>Cc: casner@packetdesign.com; avt@ietf.org; csp@isi.edu;
>>>>jo@ipdialog.com
>>>>Subject: Re: [AVT] RTCP Implementation?
>>>>
>>>>
>>>>On Wed, 27 Mar 2002 08:01:09 +0200
>>>>igor.curcio@nokia.com 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:csp@isi.edu]
>>>>>Sent: Tuesday, March 26, 2002 5:12 PM
>>>>>To: Curcio Igor (NMP/Tampere)
>>>>>Cc: avt@ietf.org
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--> igor.curcio@nokia.com 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:csp@isi.edu]
>>>>>>Sent: Monday, March 25, 2002 9:46 PM
>>>>>>To: Srikrish
>>>>>>Cc: avt@ietf.org
>>>>>>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
>>>>>>avt@ietf.org
>>>>>>https://www1.ietf.org/mailman/listinfo/avt
>>>>>>
>>>>>>_______________________________________________
>>>>>>Audio/Video Transport Working Group
>>>>>>avt@ietf.org
>>>>>>https://www1.ietf.org/mailman/listinfo/avt
>>>>>>
>>>>>>
>>>>>_______________________________________________
>>>>>Audio/Video Transport Working Group
>>>>>avt@ietf.org
>>>>>https://www1.ietf.org/mailman/listinfo/avt
>>>>>
>>>>>
>>>>_______________________________________________
>>>>Audio/Video Transport Working Group
>>>>avt@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/avt
>>>>
>>>>
>>>>
>>>
>>>_______________________________________________
>>>Audio/Video Transport Working Group
>>>avt@ietf.org
>>>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 : 703-293-9624       Fax     : 703-293-9609
>>e-mail : tme@multicasttech.com
>>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
>>
>>
>>
>>
> 

-- 
                                  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 : tme@multicasttech.com
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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt