Re: [AVT] Port mappings, NAT, and RAMS

[Roni Even <Even.roni at huawei.com>]

Tom,
What bothering me is that I do not want to make RTCP as a general mechanism
to provide addressing information. 

I still do not see this a a general problem. The case you described (SSM
with retransmission), except for the RAMS case there is no other application
that requires that, it requires co-location of the FT and retransmission
source, you send the retransmission request to the feedback target and not
to the retransmission server. 


If this was a general problem it should be addressed in the context of
retransmission or SSM.

Roni



 

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> VAN CAENEGEM Tom
> Sent: Friday, June 26, 2009 11:52 AM
> To: Roni Even; Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen
> (abegen); avt at ietf.org
> Subject: Re: [AVT] Port mappings, NAT, and RAMS
> 
> Hi Roni,
> 
> The problem I see here is that this is broader than RAMS: if an RTP
> receiver in an SSM session does not make use of RAMS, but wants to
> receive retransmissions, then integrating the "pub-port" functionality
> in the RAMS-R will not help here. That is why it makes most sense to
> define a dedicated RTCP "pub-port" message that can be combined with an
> RAMS-R or with a NACK.. Or with any other future RTCP request message
> that may be defined and relies on the same ssm with feedback target
> architecture..
> And I also think that we should consider a "default" case that when an
> RTP receiver does not signal its ports, the retransmission server
> understands the RTP receiver expects the retransmission/burst on the
> port, that was used by the RTP receiver as source port to request the
> retransmission and burst. But that should imply that the "pub-port"
> MUST
> always be sent in a single compound together with the NACK and/or the
> RAMS-R message (either of these) that triggers the retransmission
> session.
> 
> Tom
> 
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: vrijdag 26 juni 2009 10:31
> To: 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C. Begen (abegen)';
> VAN
> CAENEGEM Tom; avt at ietf.org
> Subject: RE: Port mappings, NAT, and RAMS
> 
> Hi Bill,
> I think I was the one who started this discussion but it looks to me
> like it is going too far since some of this work are not in the AVT
> charter.
> 
> The RAMS solution is based on SSM and Retransmission and if there is a
> problem with NATs in these drafts it should be discussed there. My
> concern was different. The AVT solution is using SDP for specifying
> address information. In the case of both SSM and retransmission, the
> server can provide their address (which they may have obtained by using
> any method they
> chose) in the SDP. This works both for offer/answer and declarative
> SDP.
> I see no reason to address this topic in the RAMS draft
> 
> The RAMS draft need to provide other addresses which are the RR RTP and
> RTCP receive addresses. In the case of offer answer this is clear by
> for
> declarative SDP the RR does not sent an SDP so cannot provide receive
> addresses.
> 
> 
> In the case of RFC 4588 the retransmission can be based on session or
> SSRC multiplexing and defines how to use SDP to provide the addresses.
> The difference is that RFC 4588 do not address a unicast retransmission
> for a multicast stream which is the special case described here.  In
> the
> current case the SSRC multiplexing mode of RFC 4588 is not relevant so
> there MUST be a way for the RR to provide its receiving addresses to
> the
> RS.
> 
> Since this solution do not work in offer/answer but is based on
> declarative SDP there need to be other way for the RR to provide the
> addressed
> 
> 
> My view based on the text above about SSM and RFC 4588 is that this is
> a
> special case and not a general case and this is why I suggested to add
> the address information to the RAMS-R message.
> 
> Roni Even
> 
> 
> > -----Original Message-----
> > From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> > Sent: Wednesday, June 24, 2009 3:37 PM
> > To: Zeev Vax; Ali C. Begen (abegen); Roni Even; VANCAENEGEM Tom;
> > avt at ietf.org
> > Subject: Port mappings, NAT, and RAMS
> >
> >
> > There has been some discussion around the requirement for a NAT
> > section in the latest RAMS draft. This note is an attempt to clarify
> > the requirement to signal RAMS port mappings. Once we come to a
> > consensus as to the desired behavior, we can update the draft.
> >
> > This text refers to a ppt document that can be found at
> > ftp://ftpeng.cisco.com/abegen/PubPorts.pdf
> >
> > When using RAMS to accelerate acquisition of a multicast flow, there
> > are two sessions - the primary multicast session and the acceleration
> > session. These sessions may have multiple socket contexts, depending
> > on the use of RTP/RTP port muxing. However, the primary multicast
> > session and the retransmission session are always distinct.
> >
> > 1- The primary multicast session - two logical flows defined by the
> > Source address, Destination Multicast Address, RTP port (P1) and RTCP
> > port(P2). This set of flows is shown in RED in the diagram.
> > 2- The retransmission/acceleration session, shown in BLUE in the
> > diagram. In the most general non-port-muxed, non-NATed case, this
> > stream consists of 2 flows. The first (RTP) flow is defined by the
> > 5-tuple of UDP, IP address of the FT, RTP port configured by SDP
> (P3),
> 
> > the IP address of the client and the RTP port dynamically chosen by
> RR
> 
> > (c3).
> > The second (RTCP) flow is defined by the 5-tuple of UDP, FT address,
> > the RTCP port defined by SDP (P4), the IP address of the client and
> > the RTCP port dynamically chosen by RR (c4). When RTP/RTCP port
> muxing
> 
> > is used, the retransmission session is collapsed onto a single
> > 5-tuple.
> >
> > Note that the feedback target for the primary session is P2 on FT/RS.
> > Note that the acceleration burst must flow from FT P3/P4 to C c3/c4.
> > In other words, the first desired data flow on the retransmission
> > session is "downstream".
> >
> > When we introduce NAT, we need to map c3 to c3' (and in the absence
> of
> 
> > port muxing, also c4 to c4') through the NAT device. This diagram
> > shows the use of STUN in YELLOW to setup the port mappings, but other
> > methods could be used.
> >
> >
> >
> > In summary, the ppt describes 4 options-
> >
> > Drawing 1 - No muxing - Stun request, bind for two ports and send
> > PubPorts with RAMS-R to signal both, followed by the burst.
> > Drawing 2 - Muxing - Stun request, bind for one port and send
> PubPorts
> 
> > with RAMS-R to signal a single port, followed by the burst.
> > Drawing 3 - Muxing - No explicit STUN request/bind. Send PubPorts
> with
> 
> > RAMS-R to signal RS to use the src port of the incoming RTCP packet
> as
> 
> > the destination for both RTP and RTCP in the ret session (We do this
> > by putting 0's in the pubports messages). Note that this does not
> work
> 
> > through all NAT variants. The RAMS-R/PubPorts message is sent from c4
> > to P2. The burst is sent from P4 to c4', and certain NATs will not
> > pass this traffic.
> > Drawing 4 - Muxing - No explicite STUN request/bind. Send PubPorts
> > from
> > c4 to P4, initializing NAT bindings. Send RAMS-R, followed by the
> > burst.
> > This works through all NAT types. There is concern about the
> > decoupling of the PubPorts from the RAMS-R, as dropped messages may
> > cause problems.
> >
> > Hopefully this note clarifies the need to signal the ports.
> >
> > Inputs on ths problem are desired. We need to decide if the PubPorts
> > is the right way to go, and if the transaction is RAMS specific or is
> > a generic RTP/RTCP message. Once we make that determination, we need
> > to lay out the details of the message format.
> >
> > Based on the feedback - we will abandon the idea, keep it in the
> > draft, or write a separate draft for it.
> >
> > Bill VerSteeg (with extensive input from Ali Begen and Dan Wing)
> >
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> > Zeev Vax
> > Sent: Thursday, June 18, 2009 5:58 PM
> > To: Ali C. Begen (abegen); Roni Even; Bill Ver Steeg (versteb);
> > VANCAENEGEM Tom; avt at ietf.org
> > Subject: Re: [AVT] comments on
> > section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> >
> > If we assume all entities are one, why would you need to signal the
> > retransmission port separately ?
> >
> > Zeev
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt