Re: [AVT] Token draft rev'ed (other than security)

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Jonathan Lennox [mailto:[e-mail]]
> Sent: Tuesday, November 09, 2010 11:26 AM
> To: Ali C. Begen (abegen)
> Cc: [e-mail]
> Subject: Re: [AVT] Token draft rev'ed (other than security)
> 
> 
> On Nov 9, 2010, at 11:06 AM, Ali C. Begen (abegen) wrote:
> 
> >> This is a failure case that clients may need to be prepared to deal with.  If this happens, the client needs to send a new
> port
> >> mapping request.  It might be a good idea to say that in this case the client SHOULD send the new port mapping request
> from
> >> *c1, and use it before *c1's NAT bindings expire.  (Essentially, behind an Arbitrary Address Pooling NAT, the client will end
> up
> >> behaving as though Tokens were really Cookies, as a fallback mechanism following failures.)
> >
> > Rather than saying like this, we encouraged to have ct=c0=c1. Is not this a better approach? It deals with this problem in
> the first place.
> 
> I think "send the port mapping request from c1" and "ct=c1" are two ways of saying the same thing.  The one tricky thing is
> that if you got your (now-expired) Token from a previous session with the same server, your new c0=c1 is different than your
> old c0=c1, I think.

C0, c1 and ct are up to you to choose. You can stick with the same values (if you know how to handle undesired RTP packets in case you receive something from an old session).

> 
> The other issue that for fully BEHAVE-compliant NATs, ct=c0=c1 is simply good practice in order to reduce the number of
> NAT bindings; however, for non- or conditionally-BEHAVE compliant NATs, there are cases where it's actually required.  It's
> possibly worth explicating this in the draft, probably in terms of the RFC 4787 language.

This looks like something Dan or you can propose some text for. And I will be happy to just insert it ;)
 
> 
> >> If your NAT has both Arbitrary Address Pooling and Address and Port-Dependent Mapping, though, this still may not work
> if
> >> PT != P3.  (Such a NAT is not BEHAVE-compliant, since Endpoint-Independent Mapping is a MUST in RFC 4787.)  Does PT =
> P3
> >> therefore need to be SHOULD strength, rather than MAY?  At any rate, this should probably be pointed out.
> >
> > I am fine with making it SHOULD, but if the NAT is not compliant, who knows what other stupid things it will do. One thing
> we need to note is that P3 is (often) different for different unicast sessions (the feedback target on the server), so in this case,
> the port in the "a=portmapping-req" line will be equal to the port in the "a=rtcp:" line for the SSM session (which is fine of
> course).
> 
> I don't quite follow this, but I guess your point is that (at least in some architectures) different sessions should have different
> P3 values, but share the same PT value?  I see how that complicates things.

The feedback port may need to be different (see the RAMS for discsussion). It is largely because if the source SSRCs cannot be guaranteed to be unique, you gotta choose different feedback targets.
 
> Fair point about stupid NATs.
> 
> I think that this draft achieves the goal of "simple topologies with well-behaved NATs work well; broken NATs or overly-
> complicated architectures work no worse than Cookies."  So that's good.

Yup.
-acbegen
 
> --
> Jonathan Lennox
> [e-mail]
>