Subject: [AVT] FW: Draft Notes from AVT port mapping session

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 25 Mar 2010 22:19:10 +0100

For information, these are the unofficial notes from the AVT port mapping ad-hoc.

We will be tidying these up, and posting the revised version. 

The slides referred to will be posted on the meeting materials site, but the version used in the ad-hoc are not there at the moment.

regards

Keith

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 10:01 PM
To: Cullen Jennings; Robert Sparks; Gonzalo Camarillo; DRAGE, Keith (Keith); Roni Even
Cc: Ali C. Begen (abegen)
Subject: Draft Notes from AVT port mapping session

Here are my notes - sent to chairs and ADs.

You need to get the slides from Tom. 

Cullen

-----------

We need to specify how to put the port for the FB, RTCP RR in the SDP. This should not be a problem to specify in SDP but do need to make it clear in the draft. (FB = Feedback Target)

On next version of draft, In figure 4, add -> style arrows between src, dst addresses

Question is about how to find the nat mapped address of the RTP port on the client?

Questions, should we use STUN instead of RTCP to get the port mapping?

Question how to do the keep alive?

In the single port model, we need to MUX RTCP and RTP on the client.

In the two port model, still need to be able to MUX enough to get the STUN or RTCP on the client RTP port so that one can receive the Cookie. 

Another idea, is to define a new RTP payload type to use to do the cookie request. 

RTP/RTCP MUX results in a solution that is faster, less brittle, more reliable, less complex.

Alternative 2 port solution, still needs muxing but at a different place. EIther mux STUN from RTP, or mux RTP from RTCP, or mux two types of RTP

Conclusion: We agreed that port mux approach looks best and plan to ask WG if they are OK with that. 

----------------

Question about cookie generation. We probably need a nonce to in cookie request / response to protect from DOS attack. 

------------

Tom presented alternative solution to discover the mapping. It uses RTCP and RTP port muxing on both sides. This would work by using the same port/IP for the RS and FT. Tom can sends his slide on cross symmetric muxing that has this.

Issues raised there may be problem with some OS in doing this. Advantage is no port mapping requests. 

A symmetric NAT will cause the packets to come from different cases. It does mean you can't demux based on the the source of the packet. You need to demux the session using SSRC and CNAME. 

This saves 1/2 to 1 to RTT. 

Having hard time trying see how to make this consistent with RTP architecture. 

In the context of could we do both cookies and cross symmetric multiplexing... Several people spoke against having multiple ways to do things and optional optimizations. 

Conclusion: There are concern with the cross symmetric approach: In the unicast stream, it has two session on the same port. 

------------

Discussion about SDP example in draft and what is the port in m=video 41002 RTP/AVPF 99 

Magnus said you need to explain to this in either the ports or rams draft so people understand what port number they should use and what it means. 

Need to look at how rtcpmux works with the SDP and 

----------------------