On Mon, 2009-04-13 at 15:32 -0400, Robert Joly wrote: > 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.
I've filed that bug report on other phones, but perhaps not these... > 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? We can't compensate for invalid construction/copying - that way lies madness. File the issue against the phone ; it's a Blocker, since _many_ things will be broken by it. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
