> On Fri, 2009-07-10 at 16:49 -0400, Scott Lawrence wrote: > > [hard core internals of proxy follow] > > > > In rev 13475, the RouteState class was modified to handle multiple > > Record-Route headers that include route state. These > changes appear > > to me to clone the state information into multiple copies > of the header. > > > > Based on the comments, I'm pretty confused about what this > was meant > > to support. > > > > I had been looking into changes that would allow one system (or > > multiple systems in the same cluster) to add distinct route state > > information, and use the host identifier in the route to > distinguish > > them. For example, given a proxy whose IP address is 10.1.1.10 and > > whose SIP domain is 'example.com', you might get headers like: > > > > Record-Route: > <sip:example.com;sipXecs-rs=xxxxxxxxxxxxxxxxxxxxxxxxxx> > > Record-Route: > > <sip:10.1.1.10;sipXecs-rs=yyyyyyyyyyyyyyyyyyyyyyyy> > > > > the 'upper' route means "any proxy in example.com" and the > 'lower' one > > means exactly the proxy needed to traverse a NAT, for > example. There > > might even be a third using a different IP address for another NAT > > traversal leg. > > > > It looks as though the changes made in r13475 would force those > > headers to be (in effect): > > > > Record-Route: > <sip:example.com;sipXecs-rs=xxxxxxxxxxxxxxxxxxxxxxxxxxyyyyyyyy yyyyyyyyyyyyyyyy> > > Record-Route: > > > <sip:10.1.1.10;sipXecs-rs=xxxxxxxxxxxxxxxxxxxxxxxxxxyyyyyyyyyyyyyyyyyy > > yyyyyy> > > > > where the state information in each is duplicated into both. This > > seems pretty wasteful (and might cause errors, since we know of > > systems that don't handle very long headers), but more > importantly it > > seems unnecessary. > > The interesting situation is when the route of a dialog > passes through the same proxy more than once. In that case, > do all of the "passages" > through that proxy share the same state, or does each passage > have its own state? I would expect the latter to work more > reliably (as the plugins that read and write the route state > are likely to be written implicitly assuming that a "passage" > through the plugin won't have its state modified by another > "passage" through the same plugin).
I disagree but I guess it really depends on the nature of the plug-in. In the specific case of NAT traversal, on the second pass, it is possible that the location of the called party becomes clearer such that it is in a position to provide better NAT compensation of the call. In this case, I would want all the RouteStates to contain the 'better' information so that it gets used by the plugin regardless of the pass. Generally speaking, given that plug-ins have been created at the time where only one RouteState could ever exist per proxy, the safest thing to do to ensure that they continue to work after we allow multiple RouteStates/proxy is to make sure that they are identical. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
