On Thu, 2009-07-30 at 19:44 +0000, Scott Lawrence wrote:
> 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).
I can see the value of this when spiraling, that is, attempting to add
several successive Record-Routes for the same proxy. But that's going
to cause trouble if some other proxy has added a Record-Route in
between.
As I see it, the concept is that we are optimizing some situations by
combining adjacent Record-Routes that give the same URI. That doesn't
change the *effect*, but it changes how we talk about it -- instead of
assuming that Record-Routes are combined and then fretting about when
that might have to be suppressed, we identify situations where it is
clearly safe to combine Record-Routes, and only optimize in those cases.
That is a lot less likely to cause problems.
But all of that is different than the question of scoping information.
For instance, (if I understand correctly), we want to have the call pass
once through the proxy for the purpose of gathering CDR data. If we
really want to have only one CDR logging point (even if the call spirals
through an external system), then the logic would be:
if no previous Record-Route for my domain includes value "cdr"
then
add Record-Route for my domain with value "cdr"
fi
That requires that the "cdr" value is globally visible.
Tagging the call with authorization information has similar global
visibility requirements, but in that case the Record-Route has no
protocol purpose, it is only to carry the authorization information.
(Compared to the CDR case, where we need the proxy to remain in the
signaling path.)
On the other hand, NAT traversal is a situation where the information is
specific to the passage. Similar problems happen with any Record-Route
that is needed for routing purposes -- adding a Record-Route is
necessary, and any attached values are specific to this passage. Of
course, the Record-Route URI isn't necessarily an IP address.
OK, I think I'm starting to see the concept -- Record-Routes whose URI
is the SIP domain are intended to carry global data, and are expected to
not have any routing significance other than to assure that signaling
goes through *some* proxy in the domain at least once. Record-Routes
with other URIs are intended to be followed literally, and their data is
intended to be specific to that passage.
> NAT traversal complicates this by adding system specific routes, which
> can't be combined with each other.
When you say "system", do you mean "host"? "System" is usually used to
mean the entire PBX system, with its redundant hosts.
> 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.
The crucial thing is that if the proxy pops all 3 Routes, it has to make
the values attached to them all available to the plugins that process
the message on that passage, so as to trigger all the appropriate
processing.
A messy case is:
Route: <sip:boston.example.com;lr>
Route: <sip:192.168.1.2;lr>
Route: <foo.bar;lr>
Route: <sip:example.com;lr>
Only the first 2 Routes are popped at this point. But the values
attached to the 4th Route need to be available to the processing in this
passage (as they are attached to the SIP domain and so are global), but
we have to be able to see that they aren't attached to a Route for this
passage. E.g., if the 4th Route is marked as the one that does CDR
processing, the current passage has to be able to see that there is a
Route marked for CDR processing (as described above), but also to
determine that this passage isn't responsible for it.
Although in the case you give:
> Route: <sip:example.com;lr>
> Route: <sip:boston.example.com;lr>
> Route: <sip:192.168.1.2;lr>
all three Routes could be combined at creation time because signaling
*must* go through 192.168.1.2, and it can handle processing for the
containing domains.
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/
