> On Wed, 2009-04-08 at 19:14 -0400, Joly, Robert (CAR:9D30) wrote: > > > > > > On Wed, 2009-04-08 at 15:31 -0400, M. Ranganathan wrote: > > > > Hello, > > > > > > > > Attached is a call flow for consultative transfer after > call pickup. > > > > This time I am getting a 407 from the proxy again when I > > > send out an > > > > INVITE in Frame 110 ( see attached merged.xml) but the > > > difference is > > > > I don't have x-sipx-auth-identity header that I can use > for this > > > > generated INVITE after the REFER for the transfer. So the > > > question is > > > > > > > > 1. should I use a From header something like > > > > [email protected] so the proxy will not > > > generate the > > > > challenge. I am not too happy about changing the From > > > Header mid call. > > > > Not sure if this is the right thing to do. > > > > 2. What would be the appropriate x-sipx-auth-identity to > > > attach to the INVITE? > > > > > > No - an INVITE with a Replaces should not be challenged - > this is a > > > proxy bug. > > > > The auth plug-ins indeed do not challenge an INVITE with > replaces (c.f. > > TransferControl) but the PAI will continue to challenge any > > dialog-forming INVITE that appears to originate from a user with > > credentials. That PAI is a building block that enables reliable > > user-based features which 'location-based gateway selection' is the > > first embodiment. Exempting INVITEs-with-Replaces requests > from being > > challenged for the purposes of adding a PAI header will make them > > unable to participate in any user-based feature. IMO, this is less > > than desirable. > > > > I was wondering if we could deal with this issue some other way and > > provide sipXbridge with an identity the same way we already do for > > park, media, acd, config, sipXrls and registrar. This > would allow it > > to reply to challenges which would solve the problem at hand. > > But it would be the _wrong_ identity. This is a consultative > transfer - the security has already been dealt with when the > two call legs were created, and in fact the routing (which is > what those user features are all about) has also been dealt > with - this request is going to a specific phone, not an AOR. > > This needs to work just the way it is (consultative transfer > is quite complex enough without adding any more steps), and > not have its routing messed with based on an identity-based > calculation. > > Perhaps we need to reorder the decision-making here...
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. I'll propose a potential solution shortly to get your feedback. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
