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. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
