> On Thu, 2009-04-09 at 13:02 -0400, Joly, Robert (CAR:9D30) wrote: > > > > Your comments made me think that we may have a larger > problem on our > > hands and it has to do with interactions between the > 'location-based > > gateway selection' feature and consultative transfers. > > > > The way consultative transfers go in our system, calls from the > > transferred party to the transferred-to party are *not* to > a specific > > phone but rather to an AOR. Looking at the REFER, one can see that > > the transferred party is referred to the AOR of the transferred-to > > party and sipXproxy *will* fork that request to all the users that > > have registered for that AOR. All but one phone will reject the > > INVITE on the basis that the Replaces header does not map > to a known > > dialog and the right phone will accept it. > > > > Having said that, let's consider a consultative transfer > that *must* > > use some form 'user-based gateway' selection in order to work. > > > > * Bos_1 is a user in Boston location > > * Ott_1 is a user in Ottawa location > > > > * GW_Bos is a gateway in Boston > > * GW_Ott is a gateway in Ottawa > > > > * A long-distance dialplan uses location-based routing so that > > Boston-based users use GW_Bos and Ottawa-based users use GW_Ott. > > > > With that setup in mind, let's assume that Bos_1 calls > Ott_1 and then > > does a consultative transfer to a long-distance number. > The dialplan > > will make sure that the consultation call will be established via > > GW_Bos but when Bos_1 actually completes the transfer, it > will send an > > REFER-with-replaces to Ott_1 with a Refer-To of the form > > xxxx...@localsipdomain. This will prompt Ott_1 to send an > > INVITE-with-replaces to sipXecs which will route the call > according to > > the dialplan. This will cause the INVITE-with-replaces to be > > presented to GW_Ott which will reject the call on the basis that it > > cannot find the dialog being replaced. In order for this > transfer to > > succeed, the call from Ott_1 should have been routed using Bos_1's > > location. That would have routed the call over to GW_Bos where the > > dialog being replaced exists. > > > > So, in summary, I think we have three problems on our hands > which I'm > > summarizing here: > > > > 1- Blind transfers get challenged for PAI and sipXbridge cannot > > respond to the challenge > > 2- Consultative transfers also get challenged for PAI and > sipXbridge > > cannot respond to the challenge > > 3- Consultative transfers should be routed using the transferor's > > identity to get around the problem exposed in this e-mail. > > Good problem summary. You've used sipXbridge above as > something that can't answer a challenge, which in these cases > is certainly true - it's worth pointing out that the same is > true of any gateway. > > Before commenting on the rest, I'd like to reflect on the > fact that much of this the result of the fact that we're not > really doing location-based routing, we're doing user-based > routing, inferring location from the user. If each location > had a record-routing proxy that forced any invite back to > itself, and then resolved the addresses using it's own rules, > then the problem scenario doesn't happen. But let's leave > exploring that for the next release... > > > In order to address the 3 problems stated above, as series of small > > modifications could be made that would produce the expected outcome. > > Let consider them one-by-one. > > > > Problem 1- Blind transfers get challenged for PAI and sipXbridge > > cannot respond to the challenge. > > Solution: > > [SipRouter] Do not add PAI to dialog-forming INVITEs that carry a > > sipX-auth-identity. This will eliminate the need for the challenge. > > I believe that's correct. > > > Problem 2- Consultative transfers also get challenged for PAI and > > sipXbridge cannot respond to the challenge. > > Solution: > > [SipRouter] Do not add PAI dialog-forming INVITEs that carry a > > Replaces header. This will eliminate the need for the challenge. > > Good. > > > Problem 3- Consultative transfers should be routed using the > > transferor's identity to get around the problem exposed in this > > e-mail. > > Solution: > > [TransferControl] Challenge REFERs even though they carry a > Replaces > > header. This will have the side-effect of adding a > sipX-auth-Identity > > to the INVITE generated as a result of processing the REFER > [Fallback > > redirector] Use identity captured in sipX-auth-Identity for > user-based > > gateway selection feature. If not present, fall back to current > > scheme and look for PAI. > > This one has more implications - I'm thinking that we can > probably get away with not doing it for at least the first > 4.0 release. I say this because I suspect that in most cases > the gateways will be set up as fallbacks - in your example, > the Ottawa user will have the Ottawa gateway as the first > choice for a PSTN call, but the Boston gateway as the second > choice. If that's true, then the transfer actually does work > because the Ottawa gateway returns a 481 No Matching Call > response and the proxy falls back to the Boston gateway where > the call is matched and connected. > > If something like your third problem case turns out to be > common and we need a fix, I _suspect_ that you've got it > right, but I'd rather have more testing time between putting > in that change and releasing something than I hope we have left.
Thank your for your detailed comments. I'll go ahead with elements #1 and #2 and I've created XECS-2487 to track the remaining problem. I had most of it implemented - I'll attach my work-in-progress to the tracker so that it can be resumed post-4.0. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
