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