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. Similarly, couldn't we put an entry in forwardingrules so that it never hits the authrule at all? 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. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
