Subject: RE: [AVT] RTCP question

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Sep 2001 14:37:39 -0400

RTCP is also useful as a rapid keepalive for the media sessions. It
therefore comes in handy for any fault tolerant and reliable systems.

-Jonathan R.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 2:14 PM
> To: [email-masked]
> Cc: Mistler, Art; [email-masked]
> Subject: Re: [AVT] RTCP question 
> 
> 
> Correct. My note was intended to clarify that you need to send RTCP if
> you're intending to do lip-sync, and may want to send it in order to
> get recepetion quality feedback.
> 

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Mistler, Art" <[email-masked]>
Date: Tue, 4 Sep 2001 14:53:01 -0400

Turns out I did receive a copy of the 'RTCP Optional' thread directly
from Brian.

FYI to the list maintainer, although the list archive starts at April
4th, there is a single startup message there, then nothing till June
25th.  There was no subject thread matching that discussion.  That's the
IETF based archive, I didn't try to find any mirror sites.

But I got that thread archive, and today there's been some feedback as
well, so I'm not overly concerned about the condition of the archive.
I'll leave that up to the administrator to resolve if they feel it has
merit.

- RT

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 2:36 PM
To: Mistler, Art
Cc: [email-masked]; Colin Perkins; [email-masked]
Subject: Re: [AVT] RTCP question

"Mistler, Art" wrote:

> Brian had actually suggested that I refer to an earlier discussion
close
> to this exact topic.  However when I check the archive, it only goes
> back to April 4th of this year.  There are some messages that discuss
> dissolution of another list "rem-conf", I can't seem to find that.
>
> So I'd be happy to read the historical discussion on the topic of RTCP
> necessity in a unicast environment, however I need some assistance on
> either a subject thread name, a pointer to a more extensive archive,
or
> some other solution.
>
> This way I won't force a discussion about a topic that has already
been
> covered.
> Regards,
> - RT
> From: Brian Hagar [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 1:07 PM
> To: Colin Perkins
> Colin,
> My understand from previous discussions on this mailing list is that
it
> is
> mandatory to implement but not mandatory to send except for multi-cast
> environments.
>
> Brian
>
> Colin Perkins wrote:
>
> > RTCP is necessary for lip-sync, and useful for other purposes (e.g.
> you may
> > be interested in the reception quality feedback). I would strongly
> urge you
> > to implement it.
> >
> > Colin
> >
> > --> "Mistler, Art" writes:
> > >Hello All,
> > >
> > >I'm working on integrating RTP into a media server.  And the
> engineering
> > >team continues to flip-flop on opinions as to whether RTCP is
really
> a
> > >mandatory requirement for the solution.  We will not be using IP
> > >multicast in the product, but realize that it is still recommended
> for
> > >all environments. (Section 6 of RFC1889, just after the 4 function
> > >descriptions for RTCP)
> > >
> > >People here have received private comments, from customer feedback
> and
> > >engineering peers, that RTCP is not such a stringent requirement,
and
> > >that it is highly dependent on the actual real time media that is
> being
> > >transferred.  I was wondering if anyone had any recommendations how
I
> > >might get closer to an answer.  For instance, what types of
> application
> > >areas most definitely need RTCP and what types of application areas
> can
> > >benefit from it, but live without it.
> > >
> > >Regards,
> > >- RT
> > >
> > >RT Mistler
> > >ThinkEngine Networks, Inc.
> > >175 Maple Street
> > >Marlboro, MA  01752
> > >(508) 597-0464
> > >mailto:[email-masked]
> > >The Network Listens, Understands and Responds
> > >
> > >

The thread is called

            RTCP optional ?

And it started on 4/25/2001 and petered out by the end of the month.

My summary / recollection is that the consensus was that RTCP should
become a MUST,
however I do not see this reflected in the current draft.

If you can't find the archives I believe that I have the entire thread
saved.

                                 Regards
                                 Marshall Eubanks

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.on-the-i.com

Test your network for multicast : http://www.multicasttech.com/mt/
 Check the status of multicast in real time :
 http://www.multicasttech.com/status/index.html

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 4 Sep 2001 16:24:24 -0400

To point out the obvious, it takes two to tango.
Just because YOU don't want any of the advantages of RCTP,
the device you connect to (the point of standards
is interoperability, right?), may want RTCP.

Implement it, it's the Right Thing To Do (tm)

Brian

> Sent: Tuesday, September 04, 2001 3:50 PM
> To: Ping Pan
> --> Ping Pan writes:
> >Just trying to be a devil's advocate for a moment:
> >
> >A while ago, someone was telling me the reason why not 
> implementing RTCP
> >in their "box": rtp encapsulation is very simple to be done at data
> >forwarding level (given all the coding information, etc. are fixed).
> >RTCP is a different matter. It must be done by the control processor.
> >Now, each RTP session must be closely tracked, and per-session data
> >information must be collected accurately. To support a large 
> number of
> >RTP sessions, some timer tricks are needed as well... The 
> question is:
> >if the guy does not want to support multicast, does not care 
> about fast
> >timeout and does not want to see the QoS feedback, is there 
> any reason
> >to implement RTCP?
> 
> Yes, if he wants to synchronise multiple streams.
> 
> Colin
>