> I noticed a problem when reviewing the trace for this issue: > > http://track.sipfoundry.org/browse/XECS-2441 > > (the reported problem is not a proxy issue - ignore that part). > > The problem I see is that the AA sends a REFER and is > (correctly) challenged, provides its identity, and then the > transferee correctly provides that identity in an > X-sipX-Authidentity header in the resulting INVITE, but the > proxy challenges the INVITE anyway. > > There is no logging I can see to see why it's doing that > (which is a problem in itself - at INFO level there should be). > > I'm guessing that the proxy is seeing that the From header > matches a sipXecs identity and is challenging to construct a > PAI header, but it shouldn't - it should just accept the > X-sipX-Authidentity.
I'm pretty sure that you are correct in saying that the challenge is there for PAI. Now, you raise the question of whether or not we should challenge for PAI when the message already contains a X-sipX-Authidentity. My guess is that it depends how we intend our user-based features to work. Currently, the only feature we have that depends on the identity of the caller is 'location-based gateway selection'. If we used X-sipX-Authidentity in lieu of the PAI, this would mean that the call made by the transferred user would *not* be routed based on that user's own location but rather the transferor's. Would that be the behavior that people would expect? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
