Subject: RE: [Fwd: INVITE with RTP RR's to a different address ...]

From: "Strahm, Bill" <[email-masked]>
Date: Mon, 6 Mar 2000 15:57:46 -0800

The first problem that you will run into is there are actually very few
endpoints that are Multicast aware (I know of very few consumer ISPs that
implement Multicast, and none that will work over a standard modem
connection, most corporate connections are not multicast either) making a
multicast feedback path problematic.  It wouldn't be that hard for the
endpoints to implement the RTP MIB allowing generic SNMP managers to get at
the session information that they need to monitor the stream.

You are right about third party monitors for Unicast RTP flows, we only
envisioned third-party monitors being used for multicast flows, not the
unicast RTP flows that are common in point-point conferencing.

Bill

______________________________________________
Bill Strahm        Programming today is a race between
bill.strahm@      software engineers striving to build
intel.com           bigger and better idiot-proof programs,
(503) 264-4632   and the Universe trying to produce
            bigger and better idiots.  So far, the
                        Universe is winning.--Rich Cook
I am not speaking for Intel.  And Intel rarely speaks for me

> -----Original Message-----
> From: Dirk Pranke [mailto:[email-masked]]
> Sent: Monday, March 06, 2000 3:41 PM
> To: [email-masked]
> Subject: Re: [Fwd: INVITE with RTP RR's to a different address ...]
> 
> 
> It would seem like a more useful modification would be to allow
> RRs to be multicast while the data stream was unicast; this would
> allow the end-to-end application feedback, but also allow a 
> third-party
> MIB to be built. More generally, I would be in favor of allowing
> RTCP to be multicast while RTP is unicast. Any reason why this 
> would be a bad idea?
> 
> -- Dirk
> 
> Jonathan Rosenberg wrote:
> > 
> > There are several reasons why I'm not sure this is the best 
> approach:
> > 
> > 1. RRs are needed end to end to enable application adaptation
> > 2. If you want centralized access to the feedback, then have the end
> > system implement the RTP MIB, and collect the data through that.
> > 3. RRs must be end to end for multicast. I don't like special casing
> > unicast.
> > 
> > -Jonathan R.
> > 
> > Francois Menard wrote:
> > > Does anybody oppose the idea of designing a specific way 
> to do this ... I
> > > know that RTCP has to be managed end-to-end, but there 
> are good instances
> > > where capturing the RTCP feedback in a central repository 
> is better
> > > than doing Netflow analysis ...
> > >
> > > -=Francois=-
> > >
> > > On Sun, 5 Mar 2000, Jonathan Rosenberg wrote:
> > >
> > > > You can easily have both the RTP and RTCP go to one IP address,
> > > > different than the SIP originator (media will go to the 
> address listed
> > > > in the SDP). However, there is no way to have the RTP 
> and RTCP go to
> > > > different addresses.
> > > >
> > > > -Jonathan R.
> > > >
> > > > Francois Menard List Account wrote:
> > > > >
> > > > > Is there a quick way to require the RTP RR's to go to 
> a different IP
> > > > > address than the originating party through a SIP INVITE ?
> > > > >
> > > > > -=Francois=-
> > > >
> > > > --
> > > > Jonathan D. Rosenberg                       200 Executive Drive
> > > > Chief Scientist                             Suite 120
> > > > dynamicsoft                                 West 
> Orange, NJ 07052
> > > > [email-masked]                     FAX:   
> (732) 741-4778
> > > > http://www.cs.columbia.edu/~jdrosen         PHONE: 
> (732) 741-7244
> > > > http://www.dynamicsoft.com
> > > >
> > 
> > --
> > Jonathan D. Rosenberg                       200 Executive Drive
> > Chief Scientist                             Suite 120
> > dynamicsoft                                 West Orange, NJ 07052
> > [email-masked]                     FAX:   (732) 741-4778
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > http://www.dynamicsoft.com
> 
>

---

From: Dirk Pranke <[email-masked]>
Date: Mon, 06 Mar 2000 16:23:34 -0800

I think the problem is that one can easily imagine a distributed 
point-to-point system, where there are many endpoints; possibly
including many endpoints on a single host (think one process or
thread per stream from a video server, for example). And, you certainly
don't want your monitoring system to have monitor every single endpoint.
So, either your SNMP agents or subagents need to be able to gather 
information from the endpoint through an ad-hoc API, or each endpoint
implements the MIB directly as a subagent. Both of these situations
strike me as bad (especially since implementing SNMP subagents is usually
complicated, awkward, and non-portable even with a good SNMP toolkit). 
However, if the RTCP was being multicast, you could trivially implement a 
third-party subagent or agent that did the right thing.

Of course, as pointed out in a separate note, the privacy concerns
might easily offset the advantages of this ...

-- Dirk