Guys, I was performing some final tests on my fix for XECS-2487 when I noticed that things were not quite how I would expect them to be. Basically, I was not getting the behavior I was expecting, so I started digging around. This led me to the realization that blind transferring an LG phone to external numbers may not work (yes, this is the old XECS-401). To make sure it is not something that we broke lately, I tried such a transfer using a 3.10 sipXecs and an LG 1.2.38sp and observed the same broken result. Here are the details of what I found.
When a phone gets blind transferred the TransferControl auth plug-in challenges the REFER. When a new REFER with a proper challenge response is received, it adds a X-sipX-authidentity as a header parameter to the Refer-To: message. The Refer-To header as it appears on the wire is of the following form: Refer-To: <sip:[email protected]?x-sipx-authidentity=%3csip%3a2277%40domain.ca%3b signature%3D49E37ECD%253A%253Ab978df7c25946c8e0a6122eba1c51c61%3E> When a REFER with such a Refer-To header is received by an LG phone, the resulting INVITE will contain a X-Sipx-Authidentity header of the following form: X-Sipx-Authidentity: <sip%[email protected];signature=49E37ECD%253A%253Ab978df7c25946c8e0a6122 eba1c51c61> The problem appears to be that the X-Sipx-Authidentity header that LG puts in its INVITE hasn't been unescaped which causes the SipXAuthIdentity::decode() to report an invalid signature. As a result, the LG phone is challenged when it should simply inherit the permissions of the transferor. When I observe Polycom and IPDIalog phones under the same circumstances, I see that the X-Sipx-Authidentity header they put in their INVITE is unescaped and is properly decoded by sipX. Their header looks like this: X-Sipx-Authidentity: <sip:[email protected];signature=49E37ECD%3A%3Ab978df7c25946c8e0a6122eba1c5 1c61> All this escaping business leaves me perplexed so I have to ask. Should sipXecs be expected to handle the unescaped X-SipxAuthidentity header that LG sends or is the phone at fault for sending an invalid header? I'll create a tracker according to the response. Cheers, bob _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
