Further discussion of this topic: On Mon, 2008-09-22 at 17:35 -0400, Dale Worley wrote: > 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.
There is another case where x-sipx-nat-route can be generated in a request: If a request comes from a UAC behind a NAT, when the request arrives at sipX, its Contact can have an x-sipx-pubcontact applied. This will cause any request that the UAS sends in the dialog to have an x-sipx-pubcontact URI parameter, which will get converted into an x-sipx-nat-route header as it passes through sipX toward the original UAC (the caller). When can this second request have a Route header? The Route header must have been added by the UAS due to a Record-Route header in the initial request, and that Record-Route header must perforce have been added before the initial request reached sipX. As a result, when the second request is passing through sipX on the way to the original UAC, the x-sipx-nat-route header should be obeyed before any Route headers. (Which is the same result as we had in the case of sending a request to a registered UAC, with the Record-Route headers of the initial request supplying the Routes, rather than the Path of the REGISTER.) 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
