Subject: [AVT] New Port Mapping draft

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 4 Feb 2010 19:10:12 -0800

Hi everyone,

The port mapping draft is now a normative reference for the RAMS draft.
Since the port mapping problem is not specific to RAMS, we decided to
address it in a separate draft.

Here is the new revision:
http://www.ietf.org/id/draft-begen-avt-ports-for-ucast-mcast-rtp-02.txt

The RAMS draft and this draft should be reviewed together. The current
port mapping draft offers two alternative approaches and we would like
to hear WG's input on them.

Thanks,
-acbegen

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 5 Feb 2010 17:38:44 +0100

Ali,

these are some comments to the port mapping draft, especially on the
server-generated cookie solution.

In the SDP description, in my understanding, the port P3 is meant to be
the destination port for the retransmission session (cfr definition in
SDP RFC 4566:  <port> is the transport port to which the media stream is
sent). Because in a retransmission session coupled with a SSM, the RTP
packets can only flow from retransmission server to client, there is in
fact no P3 port at the server side  to which a client can send (RTP)
packets.  I think we should simply have in this proposal that the RTCP
port mapping request messages are sent to the RTCP port P4, which is
declared with the
 a:rtcp atribute for the retransmission session in the SDP example. This
is the most logical thing to do. Having the portmapping req/response
messaging crossing this port (see further), fulfills the goal of the
draft: allowing an RTP receiver to choose the RTP/RTCP destination ports
for the RTP and RTCP packets sent by the RS in the retransmission
session.

If on top of that, we also want this solution to work across a NAPT
sitting in between RS and RTP Rx, where we want the port mapping request
messages to open the NAPT for the RTP and RTCP packets sent in the
retransmission session, this results in the fact that the source port
chosen by the RS for RTP and RTCP packets in the retransmission session
must match this port P4.  

I understand and realise that eventually this is what is depicted in the
scheme on fig 4 (P3 = P4), but as explained above, I prefer this
different (and more "correct" IMHO) way of explaining and motivating the
port mapping solution.

I also think that in principle only one cookie must be exchanged even in
the case when the RTP RX does not implement port muxing (i.e. it wants
to receive RTP and RTCP in the retransmission session on a different
port). When receiving the one cookie in the NACK or RAMS-R, this cookie
will link the RS to the two ports (or one port if the RTP-RX indicated
it wanted port muxing) of the retransmission session (this is session
information). A possible solution to accomplish this is by having the
RTP-RX sending two port mapping request messages  each on a distinct
port (or one port if it wants session muxing) to the one RTCP port of
the RS, and where the port mapping request message contains a flag which
indicates whether this port mapping request message pertains to the RTP
flow, the RTCP flow, or both (one message in this case). 
When two messages are sent by the RTP Rx (i.e. it does not support or
want port muxing for the retransmission session), these messages must be
somehow "linked". In your proposal you do this by including the response
"cookie" from the 1st port mapping response (for the RTCP flow) in the
2nd port mapping request. I suggest to include in the (two) port mapping
request message(s) a single client-generated cookie, which hence must be
the same across the two port mapping request messages . The server can
then associate the two port mapping requests and the RS responds with a
single port mapping response, which either includes the client generated
cookie or a server generated cookie. In either case, this is the cookie
that must be used by the client in subsequent NACK or RAMS-R messages to
the FT. This requires one message exchange less compared to the current
draft proposal. It can also be seen as a kind of hybrid between client
and server generated cookie process, but still requiring a dedicated
port mapping response message from the RS.

Then I have one question which is indirectly linked to the SDP example
used in this draft: is it possible to signal with (declarative) SDP to
an RTP receiver two different RTCP ports, where one port is the one to
which an RTCP receiver should send its RTCP packets (destination port of
RTCP messages transmitted by RTP Rx to the RS), and the other port is
the port on which the RTCP receiver will receive the RTCP messages
(destination port in RTCP messages transmitted by RS to the RTP Rx).

Thx and Regards
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: vrijdag 5 februari 2010 4:10
To: IETF AVT WG
Subject: [AVT] New Port Mapping draft

Hi everyone,

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 5 Feb 2010 09:06:30 -0800

Hi Tom,

Thanks for the quick review.

> fact no P3 port at the server side  to which a client can send (RTP)

Right. 

>  a:rtcp atribute for the retransmission session in the SDP example.
This

Since the draft motivates that the server must support port muxing,
P3=P4. I agree, though, in the text we could use P4 instead of P3.

> chosen by the RS for RTP and RTCP packets in the retransmission
session

Right, the packets from the server must come from the port that the
client sent its cookie requests to.
 
> different (and more "correct" IMHO) way of explaining and motivating
the

OK.
 
> flow, the RTCP flow, or both (one message in this case).

Right.

> somehow "linked". In your proposal you do this by including the
response

Exactly.

> the same across the two port mapping request messages . The server can

OK, this boils down to a hybrid approach, where the client initially
generates a random cookie to correlate (or link) the requests, but
eventually the server generates the main cookie that will be used in the
rest of the unicast session.

> cookie or a server generated cookie. In either case, this is the
cookie

It should use a server-generated cookie.

But, what if two clients sharing the same public address also generated
the same random cookie and are trying to request a server cookie (from
the same feedback target)? Don't we still have a failure case?

As the draft mentions, the probability of having this could be
negligibly small. And we might prefer speed over reliability. I suppose
we should list this approach, too in the draft and discuss it.

> draft proposal. It can also be seen as a kind of hybrid between client

Yes, the current solution is not very delay-wise expensive provided that
the NAT behaves nicely.

> port mapping response message from the RS.

Agreed.
 
> (destination port in RTCP messages transmitted by RS to the RTP Rx).

We already have the first one. For the second one, my understanding is
that no one can declaratively tell the client to use a specific port in
a unicast application. But, I will let SDP experts comment on this.

Cheers, acbegen.