On Thu, 2009-07-30 at 13:37 -0400, Dale Worley wrote: > On Thu, 2009-07-16 at 13:44 -0400, Scott Lawrence wrote: > > My current thinking is that there are two circumstances for any given > > item of route state information: > > > > A. Position in the route set matters. > > > > This is clearly the case with the NAT traversal data - > > the state that identifies the path to the NATed peer > > must be in the route that specifies the particular proxy > > that established the NAT mapping and added it to the > > route state. > > > > B. Position in the route set does not matter, so long as the state > > is somewhere in the set. > > > > This is related to another aspect of the route set that has been a > > design goal previously but not exploited: that some state information is > > specific to a particular proxy, and other state information could be > > applied by any proxy in the same domain. > > I fear that I don't understand the distinction you're making here. > Basically, any route state information attached to the Route for a > particular passage is specific to what is happening within that passage. > If we use domain names in Route's, then any of a number of proxies might > perform that passage's operation. But the operation will be done by the > same plugin, using the same data, to accomplish the same ends. Using a > domain name doesn't cause the data to cease being specific to that > passage, and other passages using the same domain name in the Route will > need separate route state.
That would be true under a different set of assumptions than the ones we've been using until now. The current behavior (when not using NAT traversal, which complicates things a bit) is that no matter how many times a dialog-forming request passes through the proxies, there is only 1 Record-Route added. This means that the route set for the dialog does _not_ exactly match the path taken by the INVITE. This was a deliberate design decision taken when RouteState was first implemented - it means that only the dialog-forming request does all the spiraling; the in-dialog messages pass through the proxy only once (which we need for CDRs). NAT traversal complicates this by adding system specific routes, which can't be combined with each other. My thinking at this point is that system specific routes still can't be combined (obvious), but that domain routes can be as long as they are the same domain value (more on that below). It means that the operations performed by any plugin on a domain route may be set up (the initial state added) on different passes through the proxy, but so long as no system route is added between them, they all end up in the same domain route and are thus used on the single pass through a domain proxy for all in-dialog messages. It may be that in the multi-branch configurations we use different domain-scoped routes for different purposes: some plugins may work on any example.com route, while others are branch specific so they must be on a boston.example.com route. If those routes end up adjacent in the route set, they all end up being pulled out at once when the proxy reads the route set (because the proxy extracts routes from the set based on matching any alias for the host); this applies to system routes as well. So this route set: Route: <sip:example.com;lr> Route: <sip:boston.example.com;lr> Route: <sip:192.168.1.2;lr> pops all three routes if the proxy at 192.168.1.2 is a branch proxy for the boston office of example.com, and any state in any route is available. I don't think we need to worry about collisions, since route state parameter names include the plugin name and any given plugin should always put its state in the same route type. But this route set at the same system: Route: <sip:example.com;lr> Route: <sip:72.195.3.7;lr> Route: <sip:boston.example.com;lr> only pops the 'example.com' route, and any state in the 'boston.example.com' route is not available to it until its been through the 72.195.3.7 system. _______________________________________________ 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/
