Closed GoogleCodeExporter closed 9 years ago
Here is what I find on this issue. it appears if Proxy Challenges Register with
401, then you imsdroid will never send out another register message. Instead,
additional register but without authentication is sent out which may eventually
blacklist the device with SBC. The magic happens in tinySIP JNI code. Inside
tinySIP/src/dialogs/tsip_dialog.c ( function tsip_dialog_update_challenges),
the code will respond with "Failed to handle new challenge".
Tracing this further.. tsip_dialog_update_challenges is being called by
tsip_dialog_update from the same file. where i have found the following code
to deal with 401 response.
Putting debug statement into the code reveals that isRegister = 1, but
self->state == tsip_established is false and therefore making
acceptNewRegister=0.
if(code == 401 || code == 407 || code == 421 || code == 494)
{
tsk_bool_t acceptNewVector;
/* 3GPP IMS - Each authentication vector is used only once.
* ==> Re-registration/De-registration ==> Allow 401/407 challenge.
*/
acceptNewVector = (isRegister && self->state == tsip_established);
return tsip_dialog_update_challenges(self, response, acceptNewVector);
}
Challenge in tsip_dialog_update_challenges will only happen in Stale field in
Register = 1 or acceptNewRegister =1. As they are both 0, Challenge will never
happen.
I did not have a chance to trace where self->state was supposed to change to
tsip_estbalished, but possibly this condition should be removed or changed. I
resolved my problem by hardcoding acceptNewVector=1. However, there are still
issues with the Challenge
In some systems authentication user name could be different then registration
user id. I think that imsdroid should allow Authentication User ID to be
entered in the Identity Options screen and be placed in authentication header
as entered by the user. That would give us most flexibility. For example if the
network requires auth name to be public identity, then let the user creating
the account assign it to that value. Again, in my case i had to make hardcoded
change in tinySIP/src/authentication/tsip_challenge to get it to work. I made a
change to a predefined MACRO (#define TSIP_AUTH_COPY_VALUES(hdr)) that copies
the data into auth header.
Original comment by alex9...@gmail.com
on 30 Sep 2010 at 12:19
Off course the client will respond to a 401/407 by sending another REGISTER
request. "acceptNewVector" is used to force the client to accept new IMS-AKA
vector and you can safely ignore this variable is you are non using an IMS Core.
When the first 401 is received "self->state" is different than
"tsip_established" which means that "acceptNewVector" will be equal to
"tsk_false". When "tsip_dialog_update_challenges" is called it will call
"tsip_challenge_create()" as "isnew" will be equal to "tsk_true".
All free servers listed in the wiki (sip2sip.info, pbxes.org, iptel, ...)
challenge the client by sending 401/407 and all work as expected.
Could you please send me a wireshark capture using the official version?
Original comment by boss...@yahoo.fr
on 30 Sep 2010 at 1:47
I tried the latest uploaded apk 1.0.292 and indeed the code i mention above is
not needed. however, it looks like username in auth header being sent to answer
to challenge is impi. i verified that in the macro i described below. that is
not what my system needs. I still think we need to provide Authname
configuration on Identity screen and use it. I can make the change and pass you
the diffs. Or if you prefer, you can make that change. i attach the trace so
you can see how register->401->register->401 and auth fails actually looks like.
Original comment by alex9...@gmail.com
on 30 Sep 2010 at 3:12
Attachments:
The impi IS the auth name.
According to your capture your impi is equal to
"8146010509@iad01.acndigital.net". This means that you want to use this value
as your auth name. Is it the case?
As mentioned here (http://code.google.com/p/imsdroid/wiki/Quick_Start): "For
those using IMSDroid as a basic SIP client, the IMPI should coincide with their
authentication name"
Original comment by boss...@yahoo.fr
on 30 Sep 2010 at 7:15
yessss... sorry missed it completely. RTFM ;-)I completely withdraw my
comments. works as expected.
Original comment by alex9...@gmail.com
on 30 Sep 2010 at 11:51
Original comment by boss...@yahoo.fr
on 1 Oct 2010 at 1:06
Original issue reported on code.google.com by
Benjamin...@gmail.com
on 28 Sep 2010 at 6:20