Hi, I was investigating XECS-2142 (NAT:Blind transfer between the branches fails) where a blind transfer scenario between users of different branches behind NATs fail. After looking closely at the logs, I'm starting to question whether or not the blind transfers work across branches even without NATs.
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. With such a configuration, Ottawa users can call Boston users by calling their 4-digit extension directly and vice versa and all is well. The problem arises when more exotic transfer scenarios are attempted. Consider the following: User 1000 in Ottawa calls user 2000 in Boston. They chat of a while and then user 2000 decides to blind transfer user 1000 to his Ottawa buddy at extension 1001. The resulting transfer will fail as follows: 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. If the phones had not been configured with an outbound proxy, this scenario would have worked just fine however phones need the outbound proxy setting to be able to do call park/call pickup across NATs (see XECS-1293, XECS-1410, XECS-1523, XCF-2600). Cam anybody see a way for this multi-branch blind transfer scenario to work even when outbound proxy settings are used? If not, then I would be forced to conclude that we have only two possible options: 1- declare this multi-site transfer scenario as unsupported; 2- resolve the call pick-up/call park target vs. identity problem once and for all so that we can lift the requirement of configuring outbound proxies. Any comments? Bob
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
