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. >> Similarly, couldn't we put an entry in forwardingrules so >> that it never >> hits the authrule at all? > > There may be cases where someone wants to restrict access to a bransh > site to a limited number of users via permissions. It may be better to > keep authrules in the picture to allow for such cases. > > >> Fixing this cleanly for the first 4.0.x release may well be a problem, >> since any of the ideas so far (except just using a >> distributed cluster) >> would require significant sipXconfig work. > > I will open a tracker against XCF for the feature request and link it to > XECS-2142. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
