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

From: "Strahm, Bill" <[email-masked]>
Date: Mon, 6 Mar 2000 16:34:08 -0800

Actually it isn't all that bad.  Basically you can implement an RTP SNMP
Agent in the context of either a subagent, or extension agent (depending on
your environment) then have a simple API to pass data between the RTP stack
implementation and the RTP SNMP agent.  This API is rather simple in our
environment boiling down to simply calls to get RTCP information directly
from the stack.  Yes this is a proprietary API, but so is the API between
RTP and the applications that live on top of it, etc. etc. etc.

Basically it boils down to using tools that are appropriate, SNMP management
tools are appropriate for managing devices on the network

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 4:24 PM
> To: Strahm, Bill
> Cc: [email-masked]
> Subject: Re: [Fwd: INVITE with RTP RR's to a different address ...]
> 
> 
> 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
> 
> "Strahm, Bill" wrote:
> > 
> > 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
> > >
> > >
>