On Wed, Feb 4, 2009 at 11:10 AM, M. Ranganathan <[email protected]> wrote: > On Wed, Feb 4, 2009 at 10:55 AM, Robert Joly <[email protected]> wrote: >> 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? > > > Only one that is not going to fly in the near term : > > 1. Make sipxbridge be the glue for multi-branch. > 2. Add the capablity for sipxbridge to handle REFER originating from > the "ITSP" side. > 3. Add multimedia handling capability to sipxbridge. > > If we do things that way, then SipX proxy servers never directly talk > to each other. > > Of course, all this will take a bit of doing (i.e. time). > > Ranga
This problem can be handled using two sipxbridge instances - one for each proxy domain. Actually, one would not need to support REFER from the "ITSP" (i.e. the second branch) if sipxbridge is used to put together the two proxy servers in a multi-branch scenario. Sipxbridge converts the REFER to an INVITE and sends it to the other branch. sipxbridge on the inbound branch sees an inbound INVITE and processes that so REFER never leaves the first branch. What would need to be done, however is to support for multimedia streams. Currently, sipxbridge only handles a single media type as the primary target was ITSP ( PSTN ) support. The other problem would be that we would have two relays - one for each branch. You would not need for a phone to send to a proxy other than its own. ( However, caution -- the solution proposed may well suffer from the "If you have a hammer everything looks like a nail" syndrome. ) Ranga > >> >> 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 >> > > > > -- > M. Ranganathan > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
