> Robert Joly wrote: > >> On Wed, 2009-02-04 at 13:31 -0500, Robert Joly wrote: > >> > >>>> The purpose of this e-mail is to socialize a pathological > >>>> multi-branch call transfer scenario leaving NATs aside to > >> hopefully > >>>> come up with a solution. First, the scenario: > >>>> > >>>> Set-up > >>>> ====== > >>>> Two branches, one in Ottawa and the other in Boston. > >> Both branches > >>>> are part of the same big, happy network without NATs. > >>>> > >>>> - Ottawa branch has SIP domain ott.example.com and has user > >>>> extensions in the range of 1000-1999 > >>>> - Boston branch has SIP domain bos.example.com and has user > >>>> extensions in the range of 2000-2999 > >>>> - Ottawa branch has a dialplan rule to route any call to 2XXX to > >>>> bos.example.com > >>>> - Boston branch has a dialplan rule to route any call to 1XXX to > >>>> ott.example.com > >>>> - ott.example.com and bos.example.com are resolvable > through DNS. > >>>> - All Ottawa phones are configured to use ott.example.com > >> as their > >>>> outbound proxy for XECS-1523 (see also XCF-2600) > >>>> - All Boston phones are configured to use bos.example.com > >> as their > >>>> outbound proxy. > >>>> > >>>> When user 2000 wants to blind transfer 1000 to 1001, it > will send > >>>> to 1000 a REFER with a Refer-To of [email protected]. > >>>> Because user 1000 is configured with ott.example.com as its > >>>> outbound proxy, it will send an INVITE > sip:[email protected] to > >>>> ott.example.com. The Ottawa server analyzes the request and > >>>> realizes that it is not authoritative for the requested > domain and > >>>> decides to route the SIP request after running it through its > >>>> authorization plug-ins. The EnforceAuthRules plug-in > will see that > >>>> the request is aimed at a configured gateway > (bos.example.com) but > >>>> the user part '1001' does not match the user parts that > the gateway > >>>> is configured to handle based on the dialplan (indeed > dialplan is > >>>> for user parts '2XXX'). This will cause the EnforceAuthRules to > >>>> deny the call based on missing permission 'NoAccess" > resulting in a > >>>> failed transfer. > >> > >>>> 1- declare this multi-site transfer scenario as unsupported; > >> Well, it needn't be quite that bad. Even if we make no other > >> changes, you could solve this by deploying this as a single system > >> with redundant proxies at both sites rather than two > systems. With > >> the new location-based gateway routing, most of the rest of the > >> system is unaffected and this authorization issue disappears. > >> > >>> I have additional information about the problem which > forces me to > >>> revise my list of possible options. The more recent SMC > >> clients always > >>> send INVITEs to their configured proxy or domain which > >> means that for > >>> these phones, even if we "lift the requirement of > >> configuring outbound > >>> proxies", blind transfers across branches will remain broken. In > >>> general the transfer scenario across branches will fail for > >> all phone > >>> models that always send all dialog-forming requests to > their proxy > >>> first. > >> That behavior is pretty common. > >> > >>> One of the elements of the problem is that the authrules.xml file > >>> includes a catch-all 'NoAccess' clause that will deny a call to a > >>> configured gateway if the userpart does not match the > dialplan. One > >>> possible way to solve the problem would be to introduce a > >> new type of > >>> gateway called something like "remote sipXecs" which > behaves like an > >>> unmanaged gateway with the exception that it is not added to the > >>> 'NoAccess' clause of the authrules.xml. With such an > arrangement, a > >>> remote branch would be configured as 'remote sipXecs' > (which from a > >>> usability POV, is better than unmanaged gateway) and would > >> not be added > >>> to the 'NoAccess' clause which would allow the transfer > to succeed. > >> That's a good idea. If we were to have that special type, > it could > >> be even simpler - it could just not include the user part in the > >> authrule, and the call would be accepted by that rule. > > > > Right - that may indeed be simpler. > > > > Let's try to understand all the implications. > Implementing a gateway type that would generate authrules > matching any dialed number severly limits the permission checking. > At the moment if you use a gateway in 2 different rules and > if those rules require different permission authrules > generated by sipXconfig will handle it correctly. > > If we introduce gateways that skip user part you'll get into > situations that calls are restricted or allowed based on the > permissions of the first rule that is using that gateway > which in many cases will be incorrect.
I think your observations are correct and although one could perhaps question the need for having multiple dialplans to a remote sipXecs in real life deployments, given that it is a theoretical possibility, we should deal with the situation if we can afford it. Perhaps the best way to deal with the situation is to go back to my initial proposal which is to keep the authrules the same but simply exclude the gateway from the 'NoAccess' clause. That way, permission checking for multiple diaplans to the same remote sipXecs gateway will continue to work as they do today. The only difference is that if a userpart does not fall into the range of any configured dialplan using the gateway, the request will be allowed and routed to that gateway. The expectation is that the remote gateway, being a sipXecs, will be configured with the proper permissions to restrict access its protected resources and challenge requests as required. 8< _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
