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=xxxxxxxxxxxxxxxxxxxxxxxxxxyyyyyyyyyyyyyyyyyyyyyyyy> > Record-Route: > <sip:10.1.1.10;sipXecs-rs=xxxxxxxxxxxxxxxxxxxxxxxxxxyyyyyyyyyyyyyyyyyyyyyyyy> > > 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). 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 sipXecs IP PBX -- http://www.sipfoundry.org/
