> 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. > > 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
