Subject: Re: [AVT] RTP unicast address for retransmssion of multicastsesssion or using RTCP to negotitaion of RTP adddresses

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 3 Jun 2009 13:57:37 -0400

I am reluctant to recommend a STUN-specific approach to convey the RTCP
port mappings. There are other mechanisms to open pin-holes in NAT.
"UPnP NAT Traversal" is one example.
 
You could also envision cases when we need to signal RTP/RTCP port
numbers even when there is no NAT between the RTP receiver and the
feedback target.
 
In my mind, this drives us towards a generic RTCP mechanism to signal
port mappings. We would include that RTCP message in the RAMS-R
transaction.
 
Bill VerSteeg

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Colin Perkins
Sent: Monday, May 25, 2009 5:08 PM
To: Marshall Eubanks
Cc: Dave Oran (oran); [email-masked]; Roni Even
Subject: Re: [AVT] RTP unicast address for retransmssion of
multicastsesssion or using RTCP to negotitaion of RTP adddresses

On 25 May 2009, at 20:25, Marshall Eubanks wrote:

	On Sun, May 24, 2009 at 2:51 PM, Roni Even
<[email-masked]> wrote:

		One of the issues discussed in Rapid Acquisition of
Multicast RTPSessions (RAMS) has to do with the specific architecture
where the media is sent to an announced multicast  address where there
is no offer answer negotiation between the sender and the receivers.  In
the proposed solution  receivers may ask using RTCP for unicast
retransmission of the RTP stream. The current draft has as part of the
announcement a port number that the receiver should use to receive the
unicast RTP stream.  This port is specified by the retransmission server
and not by the receiver and it assumes that the IP address will be the
same as the one from where the RTCP message came from.

		The problem we encounter is that this retransmission
stream is flowing from the retransmission server to the receiver who may
be behind a FW/NAT. The simple case is if the RTP and RTCP streams are
multiplexed on the RTCP port since in this case there is an RTCP message
going from the receiver to the retransmission server which will open a
pin hole in the NAT/FW enabling RTP to flow back to the receiver (Will
need some keep alive mechanism)

		The case we are trying to discuss here is when we want
to have a separate RTP channel (not multiplexed with RTCP). In this case
we will need some mechanism to convey an address from the receiver to
the retransmission server. 

		We would like to ask if this should be part of RAMS or
do we want a general RTCP message to covey such information.

	I would say that this should be a general RTCP message. This is
a general technique now for getting through firewalls (rfc 5138). H.460
/18 and /19 use it, ICE uses it, it should be made general for RTP.

I agree that a general mechanism should be defined, rather than
something that's narrowly focussed on the RAMS problem. It's not clear
that RTCP is the right place for such an extension, though. RTCP has
focussed on media level issues to date, leaving transport layer
configuration to protocols like STUN. This seems like more of a STUN
extension, than something that should be in RTCP. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Roni Even <[email-masked]>
Date: Wed, 03 Jun 2009 22:36:18 +0300

Bill,

My major concern is with the RTP port on the RR that according to the
proposal is declared by the RS.  This will not work when there is a NAT in
the middle and will require an outbound packet to establish and keep the
binding. The recommended IETF solution is STUN and other methods like UPnP
may be mentioned

Roni

From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 8:58 PM
To: Colin Perkins; Marshall Eubanks
Cc: Dave Oran (oran); [email-masked]; Roni Even
Subject: RE: [AVT] RTP unicast address for retransmssion of
multicastsesssion or using RTCP to negotitaion of RTP adddresses

I am reluctant to recommend a STUN-specific approach to convey the RTCP port
mappings. There are other mechanisms to open pin-holes in NAT. "UPnP NAT
Traversal" is one example.

You could also envision cases when we need to signal RTP/RTCP port numbers
even when there is no NAT between the RTP receiver and the feedback target.

In my mind, this drives us towards a generic RTCP mechanism to signal port
mappings. We would include that RTCP message in the RAMS-R transaction.

Bill VerSteeg

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin
Perkins

On Sun, May 24, 2009 at 2:51 PM, Roni Even <[email-masked]> wrote:

One of the issues discussed in Rapid Acquisition of Multicast RTPSessions
(RAMS) has to do with the specific architecture where the media is sent to
an announced multicast  address where there is no offer answer negotiation
between the sender and the receivers.  In the proposed solution  receivers
may ask using RTCP for unicast retransmission of the RTP stream. The current
draft has as part of the announcement a port number that the receiver should
use to receive the unicast RTP stream.  This port is specified by the
retransmission server and not by the receiver and it assumes that the IP
address will be the same as the one from where the RTCP message came from.

The problem we encounter is that this retransmission stream is flowing from
the retransmission server to the receiver who may be behind a FW/NAT. The
simple case is if the RTP and RTCP streams are multiplexed on the RTCP port
since in this case there is an RTCP message going from the receiver to the
retransmission server which will open a pin hole in the NAT/FW enabling RTP
to flow back to the receiver (Will need some keep alive mechanism)

The case we are trying to discuss here is when we want to have a separate
RTP channel (not multiplexed with RTCP). In this case we will need some
mechanism to convey an address from the receiver to the retransmission
server. 

We would like to ask if this should be part of RAMS or do we want a general
RTCP message to covey such information.

I would say that this should be a general RTCP message. This is a general
technique now for getting through firewalls (rfc 5138). H.460 /18 and /19
use it, ICE uses it, it should be made general for RTP.

I agree that a general mechanism should be defined, rather than something
that's narrowly focussed on the RAMS problem. It's not clear that RTCP is
the right place for such an extension, though. RTCP has focussed on media
level issues to date, leaving transport layer configuration to protocols
like STUN. This seems like more of a STUN extension, than something that
should be in RTCP. 

-- 

Colin Perkins

http://csperkins.org/