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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Mar 2000 17:42:04 -0500

Actually, this is a discussion more for rem-conf than SIP.

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

Subject: Re: INVITE with RTP RR's to a different address ...
From: Francois Menard List Account <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Mon, 6 Mar 2000 15:46:32 -0500 (EST)

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
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Mar 2000 18:19:58 -0500

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.

---

From: Dirk Pranke <[email-masked]>
Date: Mon, 06 Mar 2000 15:40:52 -0800

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