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