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

From: Roni Even <[email-masked]>
Date: Sun, 24 May 2009 21:51:56 +0300

Hi,

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.

We would like to get some other scenarios not for RAMS that have similar
requirements.

Looking at previous work

RFC 4588 when discussing retransmission for multicast channel is using a
multicast group for the retransmission for small groups. It does not address
the above problem. For the unicast case it is suing offer answer to
negotiate addresses. The discussion in RFC 4588 as well as RFC 2887 do not
address the same application requirement where each user that joins the
multicast group wants to get a unicast stream with synchronization
information and not a regular retransmission due to information loss.

http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18 does not address
retransmission but has as part of the RSI message from the distribution
source a way to suggest a different feedback target transport address that
overrides the one announced in the SDP.

In RTSP the setup request from the receiver carries the transport
initialization information enabling the receiver to specify a transport
address for the stream.

Thanks

Roni Even

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 25 May 2009 15:25:51 -0400

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

Regards
Marshall

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 May 2009 22:08:03 +0100

On 25 May 2009, at 20:25, Marshall Eubanks 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: David R Oran <[email-masked]>
Date: Tue, 26 May 2009 08:34:58 -0400

On May 25, 2009, at 5:08 PM, Colin Perkins wrote:

> 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.
>
Possibly. We considered just relying on STUN (you need something like  
it anyway to force open the ports), but there are two issues:
1. The need to keep state on the server side, which potentially opens  
up state-based attacks, if you want to open up the ports "in advance"  
and then use them later (for retransmission).
2. An extra round trip during the critical path for RAMS unless we can  
find a way to piggyback both STUN and RTCP on a single datagram.

It might be "interesting" to see if there's a way to in fact piggyback  
STUN and RTCP in a single UDP packet.

That leaves the questions around TURN that Roni raised for the case  
where both hosts are behind NATs. I'm somewhat at a loss to think of  
an efficient scheme for that case; given that TURN needs rendezvous  
state anyway and may need to be set up in advance, I'm afraid the  
extra round trip is unavoidable in that case and we might as well use  
ICE.

DaveO.

---

From: Xavier Marjou <[email-masked]>
Date: Tue, 26 May 2009 14:43:43 +0200

Hi,

> mechanism to convey an address from the receiver to the retransmission

My undertsanding is that this problem (RTP packets can not traverse a
NAT from the public side to the private side) was tackled by the avt
wg and solved by the draft-ietf-avt-rtp-and-rtcp-mux. Why this
solution would now not be used for the rapid-acquisition draft? Is
there anything missing in rtp-and-rtcp-mux?

> We would like to get some other scenarios not for RAMS that have similar

If there's addional work on "yet" another NAT traversal solution, I
anticipate that we'll end up with additional bandwidth and delays with
solutions like "symmetric+keepalive rtp", "tunnelling protocol", or
"upnp", which will reduce the optimization expected from the
rapid-acquisition draft.

So my opinion is to keep it simple by mandating rtp-rtcp-mux only and
avoid any new work related to NAT traversal for this draft.

Cheers,
Xavier

---

From: David R Oran <[email-masked]>
Date: Tue, 26 May 2009 08:57:00 -0400

On May 26, 2009, at 8:43 AM, Xavier Marjou wrote:

>> flowing from
>> separate
This reduces the problem from 2 ports to 1, but doesn't eliminate it.  
The core problem is that retransmission (and RAMS) are on a separate  
RTP session which does not exist until an action on a different  
session (the SSM session in the case of unicast repair of multicast  
sessions or RAMS) occurs. Since the initial packets of the  
retransmission session go through the NAT outside->inside, the server  
has no idea what the public port is to send the packets to unless it  
is told, either in advance, or as part of the NAK/RAMS operation. See  
my earlier message for some more thoughts on the subject.

> "upnp", which will reduce the optimization expected from the
Right - this is why it's tricky. The stuff we (Cisco) have deployed  
today uses a non-standard RTCP method to communicate the pubic port  
for the unicast session. It works well, but it may be we can do better  
by putting our heads together.

> avoid any new work related to NAT traversal for this draft.
Ah, if only that alone would solve the problem!

---

From: Roni Even <[email-masked]>
Date: Tue, 26 May 2009 17:41:57 +0300

Dave,
I think that we can ignore a TURN solution (or relay) since I assume that if
the RTCP will work with no relay for RAMS then we will not need one for the
RTP either, so port should be enough
Roni 

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Tuesday, May 26, 2009 3:35 PM
To: Colin Perkins
Cc: Marshall Eubanks; Roni Even; [email-masked]
Subject: Re: [AVT] RTP unicast address for retransmssion of multicast
sesssion or using RTCP to negotitaion of RTP adddresses

DaveO.

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 27 May 2009 09:40:03 +0200

On Tue, May 26, 2009 at 2:57 PM, David R Oran <[email-masked]> wrote:
> This reduces the problem from 2 ports to 1, but doesn't eliminate it. The
> core problem is that retransmission (and RAMS) are on a separate RTP session
> which does not exist until an action on a different session (the SSM session
> in the case of unicast repair of multicast sessions or RAMS) occurs. Since
> the initial packets of the retransmission session go through the NAT
> outside->inside, the server has no idea what the public port is to send the
> packets to unless it is told, either in advance
>

I better understand now. However even with 2 sessions, rtp-rtcp-mux
can still make it work; The RTP packets for retransmission should have
associated RTCP packets as well. If rtp-rtcp-mux is used, a first RTCP
packet can be sent from the RR to the RS, which will "naturally" open
the NAT pin-hole for the retransmission packets RTP.