> 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 tried to add detailed comments regarding how the NAT traversal feature makes use of this RouteState::addCopy() mechanism in http://code.sipfoundry.org/browse/sipXecs/main/sipXproxy/lib/authplugins /NatTraversalAgent/CallTracker.cpp?r=14168 starting at line 104-147 and then 176-195. > > 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=xxxxxxxxxxxxxxxxxxxxxxxxxxyyyyyyyyyy yyyyyyyyyyyyyy> > > 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. In order to accommodate the scenario that is detailed in the comments I pointed you to above, I had to create a precedent and allow a proxy to place two routes with RouteState to itself in the Record-Route set that a request carries. Prior to my change, it was not possible to have more than one routes with RouteState per proxy in the Record-Route set. When I opened the door to allow a proxy that add more than one route with RouteState to itself in the Record-Route set, I thought it would be expected that if a plug-in adds or modifies a RouteState parameter, that it would be automatically propagated in all the RouteStates belonging to the proxy so that a plug-in always gets the latest-and-greatest representation of its RouteState parameter no matter which one of the Record-Routes to the proxy it happens to be looking at. This appeared to me as being the way to make my change as unintuitive as possible to the existing plugins that had been built expecting that only a single instance of a RouteState can ever be found in a given request. Having said that, I do not believe that the NAT traversal relies in the 'automatic propagation' properly in its logic so that we could consider pulling it out (or making it optional) if it can be proven that other plugins would be equally unaffected. _______________________________________________ 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/
