RE: [AVT] RTCP Implementation?

["Srikrish" <[e-mail]>]

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