On Thu, 2008-07-10 at 13:13 -0400, Robert Joly wrote: > > > > Getting back to X-Sipx-Temp-URI, or as it is now named, > > X-Sipx-Nat-Route: > > > > Looking at only how it functions within the stack, it is > > somewhat like a Route header, in that the message is to be > > sent to the specified URI, rather than the request-URI. > > > > For uniformity's sake, I would expect that: > > > > If X-Sipx-Nat-Route and Route are both present, > > X-Sipx-Nat-Route is where the message is sent. (This allows > > us to send to a Route address that is behind a NAT if we need to.) > > In the current implementation, Route takes precedence over > X-Sipx-Nat-Route; here was my thinking at the time. X-Sipx-Nat-Route is > used to provide a routable public IP address in instances when we are > about to send a request to a non-routable IP address. The NAT Traversal > feature can only distinguish routable from non-routable IP addresses > when requests are sent to endpoints that are registered with it. If a > Route: is present in a request, it means that that the request will be > sent to an arbitrary node (from POV of NAT traversal feature) for which > we have no location information - that means that I cannot determine if > the IP address in the Route is routable meaning that I cannot provide a > X-Sipx-Nat-Route that would be "more routable" than what is already > present in the Route: header. > > I'm hoping that the discussion above convinced you that for the purpose > of NAT traversal we should not have a X-Sipx-Nat-Route when a Route is > present however your observation brings up a valid question which is the > following: where should we enforce that constraint? Should it be a rule > in the Nat Traversal feature code ot in the SIP stack itself. Today, > the answer is both. > > 1- NatTraversalAgent.cpp will refrain from adding a X-Sipx-Nat-Route if > a Route header is found. > 2- In the SIP stack, Route takes precedence over X-Sipx-Nat-Route. > > If we can come up with a valid scenario where it would be useful for > X-Sipx-Nat-Route to take precedence over Route in the SIP stack then we > could enforce the constraint only in NatTraversalAgent.cpp, otherwise > keeping both as a safeguard is probably best IMO.
Re-reading your discussion, I think that the way to look at the combination of X-sipX-Nat-Route with Route is this: Because far-end NAT compensation can only be activated when the request-URI is a registered address of an AOR, the Route can only have arisen from a Path header in a REGISTER. Similarly, the X-sipX-Nat-Route must have come from the x-sipx-pubcontact recorded by the registrar, which must contain the address from which the REGISTER arrived at the proxy. *If* we assume that the REGISTER reaches sipX by the same path as described in its Path header (or rather, the reverse), then when the proxy is sending to the UA, it should obey X-sipX-Nat-Route in preference to Route, as the first Route address (which is the first Path address) is behind a NAT, and the x-sipx-pubcontact address is its public address. If the REGISTER reaches sipX by a different path than its Path header, and yet the last hop of the REGISTER's path came out through a far-end NAT, there is very little we can do to operate successfully. In practice, I believe that in situations where the UA is applying Path headers to describe intermediate proxies, the administrator will ensure that the addresses in the Path arrange for NAT compensation, and x-sipx-pubcontact will not be applied to the REGISTER. So I think that in the long run, we should have X-sipX-Nat-Route take precedence over Route, but it isn't worth implementing now. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
