18 Sep
2012
18 Sep
'12
7:58 p.m.
Hello,
we are testing the new version of Kamailio, 3.3 and are getting
authentication error when trying to register a sip account. We have a db
backend in which we used kamctl to add the user to the db. We are using
the kamailio.cfg script created during the install with changes for our
environment. Is there some other changes required besides the normal. I
can see in the logs where everything looks ok except for when it
compares the calculated values. I have doubled check the subscriber
table and password but to no avail.
11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560) result set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed
Thanks
Nathaniel
19 Sep
19 Sep
11:45 a.m.
Hello,
can you paste the module parameters for auth and auth_db module? Or
check the combination of password column and calculate_ha1 are ok.
I guess you are using your custom configuration file, maybe you can give
a quick test with default configuration just to see if the passwords match.
Cheers,
Daniel
On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
Hello,
we are testing the new version of Kamailio, 3.3 and are getting
authentication error when trying to register a sip account. We have a
db backend in which we used kamctl to add the user to the db. We are
using the kamailio.cfg script created during the install with changes
for our environment. Is there some other changes required besides the
normal. I can see in the logs where everything looks ok except for
when it compares the calculated values. I have doubled check the
subscriber table and password but to no avail.
11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
result set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed
Thanks
Nathaniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
21 Sep
21 Sep
5:35 a.m.
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP address,
port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
Hello,
can you paste the module parameters for auth and auth_db module? Or
check the combination of password column and calculate_ha1 are ok.
I guess you are using your custom configuration file, maybe you can
give a quick test with default configuration just to see if the
passwords match.
Cheers,
Daniel
On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
Hello,
we are testing the new version of Kamailio, 3.3 and are getting
authentication error when trying to register a sip account. We have a
db backend in which we used kamctl to add the user to the db. We are
using the kamailio.cfg script created during the install with changes
for our environment. Is there some other changes required besides the
normal. I can see in the logs where everything looks ok except for
when it compares the calculated values. I have doubled check the
subscriber table and password but to no avail.
11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
result set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed
Thanks
Nathaniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:21 p.m.
Hello,
this requires the plain text password to be in the column 'password' of
the subscriber table, do you have it? I am asking because many people
keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hello,
can you paste the module parameters for auth and auth_db module? Or
check the combination of password column and calculate_ha1 are ok.
I guess you are using your custom configuration file, maybe you can
give a quick test with default configuration just to see if the
passwords match.
Cheers,
Daniel
On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
we are testing the new version of Kamailio, 3.3 and are getting
authentication error when trying to register a sip account. We have
a db backend in which we used kamctl to add the user to the db. We
are using the kamailio.cfg script created during the install with
changes for our environment. Is there some other changes required
besides the normal. I can see in the logs where everything looks ok
except for when it compares the calculated values. I have doubled
check the subscriber table and password but to no avail.
11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
result set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed
Thanks
Nathaniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:43 p.m.
Yes, the password column of the subscriber's table contains the plain
text password. Should the calculated HA1 string match the HA1 value in
the database?
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
Hello,
can you paste the module parameters for auth and auth_db module? Or
check the combination of password column and calculate_ha1 are ok.
I guess you are using your custom configuration file, maybe you can
give a quick test with default configuration just to see if the
passwords match.
Cheers,
Daniel
On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
we are testing the new version of Kamailio, 3.3 and are getting
authentication error when trying to register a sip account. We have
a db backend in which we used kamctl to add the user to the db. We
are using the kamailio.cfg script created during the install with
changes for our environment. Is there some other changes required
besides the normal. I can see in the logs where everything looks ok
except for when it compares the calculated values. I have doubled
check the subscriber table and password but to no avail.
11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
result set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
failed
Thanks
Nathaniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:15 p.m.
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's table
contains the plain
text password. Should the calculated HA1 string match the HA1 value in
the database?
no, if clear text password is used, the ha1 column is not important
at all.
If you work with default config, it's really strange, I tested and all
goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
Hello,
can you paste the module parameters for auth and auth_db module? Or
check the combination of password column and calculate_ha1 are ok.
I guess you are using your custom configuration file, maybe you can
give a quick test with default configuration just to see if the
passwords match.
Cheers,
Daniel
On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
> Hello,
>
> we are testing the new version of Kamailio, 3.3 and are getting
> authentication error when trying to register a sip account. We
> have a db backend in which we used kamctl to add the user to the
> db. We are using the kamailio.cfg script created during the
> install with changes for our environment. Is there some other
> changes required besides the normal. I can see in the logs where
> everything looks ok except for when it compares the calculated
> values. I have doubled check the subscriber table and password but
> to no avail.
>
> 11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
> result set
> 11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
> e13d569284e76a33ca63e4d6203f844a
> 11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
> '18210b5da2b3d27e6ba50977072599ea'
> 11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
> failed
>
>
> Thanks
>
> Nathaniel
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
22 Sep
22 Sep
1:31 a.m.
I added a test account and I am still getting the same error. It seems
like I am missing something somewhere. Here is the table entry for the
test account:
3 | test | akanvoice.com | test1234 | |
b6c6087ad9e897d2e871169e0eac9398 | 8cee4856976732a5cfce7c23a19bfe59 |
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's
table contains the plain
text password. Should the calculated HA1 string match the HA1 value
in the database?
no, if clear text password is used, the ha1 column is not
important at
all.
If you work with default config, it's really strange, I tested and all
goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> can you paste the module parameters for auth and auth_db module?
> Or check the combination of password column and calculate_ha1 are ok.
>
> I guess you are using your custom configuration file, maybe you
> can give a quick test with default configuration just to see if
> the passwords match.
>
> Cheers,
> Daniel
>
>
> On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
>> Hello,
>>
>> we are testing the new version of Kamailio, 3.3 and are getting
>> authentication error when trying to register a sip account. We
>> have a db backend in which we used kamctl to add the user to the
>> db. We are using the kamailio.cfg script created during the
>> install with changes for our environment. Is there some other
>> changes required besides the normal. I can see in the logs where
>> everything looks ok except for when it compares the calculated
>> values. I have doubled check the subscriber table and password
>> but to no avail.
>>
>> 11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
>> result set
>> 11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string
>> calculated: e13d569284e76a33ca63e4d6203f844a
>> 11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
>> '18210b5da2b3d27e6ba50977072599ea'
>> 11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
>> failed
>>
>>
>> Thanks
>>
>> Nathaniel
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:46 a.m.
New subject: Fwd: Re: Registration Authentication Error
-------- Original Message --------
Subject: Re: [SR-Users] Registration Authentication Error
Date: Fri, 21 Sep 2012 15:31:20 -0500
From: Nathaniel L Keeling III <keeling(a)akan-tech.com>
To: miconda(a)gmail.com
CC: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List <sr-users(a)lists.sip-router.org>
I added a test account and I am still getting the same error. It seems
like I am missing something somewhere. Here is the table entry for the
test account:
3 | test | akanvoice.com | test1234 | |
b6c6087ad9e897d2e871169e0eac9398 | 8cee4856976732a5cfce7c23a19bfe59 |
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's
table contains the plain
text password. Should the calculated HA1 string match the HA1 value
in the database?
no, if clear text password is used, the ha1 column is not
important at
all.
If you work with default config, it's really strange, I tested and all
goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> can you paste the module parameters for auth and auth_db module?
> Or check the combination of password column and calculate_ha1 are ok.
>
> I guess you are using your custom configuration file, maybe you
> can give a quick test with default configuration just to see if
> the passwords match.
>
> Cheers,
> Daniel
>
>
> On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
>> Hello,
>>
>> we are testing the new version of Kamailio, 3.3 and are getting
>> authentication error when trying to register a sip account. We
>> have a db backend in which we used kamctl to add the user to the
>> db. We are using the kamailio.cfg script created during the
>> install with changes for our environment. Is there some other
>> changes required besides the normal. I can see in the logs where
>> everything looks ok except for when it compares the calculated
>> values. I have doubled check the subscriber table and password
>> but to no avail.
>>
>> 11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
>> result set
>> 11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string
>> calculated: e13d569284e76a33ca63e4d6203f844a
>> 11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
>> '18210b5da2b3d27e6ba50977072599ea'
>> 11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
>> failed
>>
>>
>> Thanks
>>
>> Nathaniel
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:43 a.m.
here is the output from the log file of the test user:
2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok: 10046f6d0
(7) - [select password from subscriber where username='test' AND
domain='akanvoice.com']
2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result set
at 10049a018
2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from the
query
2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
names at 100499f28
2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
types at 100499f40
2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
RES_NAMES[0] at 100499f58
2(2744) DEBUG: db_postgres [km_res.c:133]:
RES_NAMES(100499f58)[0]=[password]
2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns 8
bytes in row buffer at 100499f78
2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows at
100499f90
2(2744) DEBUG: db_postgres [km_res.c:243]:
PQgetvalue(10046f6d0,0,0)=[test1234]
2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
Column[password]=[test1234]
2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row values
at 100499fb0
2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]: freeing
row buffer at 100499f78
2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50) result set
2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
'1793af7ca4c2a2feb31410fb6c113695'
2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 100499f58
2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at 100499f28
2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at 100499f40
2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234' at
100499fe0
2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
2(2744) ERROR: *** cfgtrace:
c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27 n=auth_challenge
2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
realm='akanvoice.com'
2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate: Digest
realm="akanvoice.com", nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's
table contains the plain
text password. Should the calculated HA1 string match the HA1 value
in the database?
no, if clear text password is used, the ha1 column is not
important at
all.
If you work with default config, it's really strange, I tested and all
goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> can you paste the module parameters for auth and auth_db module?
> Or check the combination of password column and calculate_ha1 are ok.
>
> I guess you are using your custom configuration file, maybe you
> can give a quick test with default configuration just to see if
> the passwords match.
>
> Cheers,
> Daniel
>
>
> On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
>> Hello,
>>
>> we are testing the new version of Kamailio, 3.3 and are getting
>> authentication error when trying to register a sip account. We
>> have a db backend in which we used kamctl to add the user to the
>> db. We are using the kamailio.cfg script created during the
>> install with changes for our environment. Is there some other
>> changes required besides the normal. I can see in the logs where
>> everything looks ok except for when it compares the calculated
>> values. I have doubled check the subscriber table and password
>> but to no avail.
>>
>> 11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
>> result set
>> 11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string
>> calculated: e13d569284e76a33ca63e4d6203f844a
>> 11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
>> '18210b5da2b3d27e6ba50977072599ea'
>> 11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
>> failed
>>
>>
>> Thanks
>>
>> Nathaniel
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:46 a.m.
New subject: Fwd: Re: Registration Authentication Error
-------- Original Message --------
Subject: Re: [SR-Users] Registration Authentication Error
Date: Fri, 21 Sep 2012 15:43:52 -0500
From: Nathaniel L Keeling III <keeling(a)akan-tech.com>
To: miconda(a)gmail.com
CC: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List <sr-users(a)lists.sip-router.org>
here is the output from the log file of the test user:
2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok: 10046f6d0
(7) - [select password from subscriber where username='test' AND
domain='akanvoice.com']
2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result set
at 10049a018
2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from the
query
2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
names at 100499f28
2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
types at 100499f40
2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
RES_NAMES[0] at 100499f58
2(2744) DEBUG: db_postgres [km_res.c:133]:
RES_NAMES(100499f58)[0]=[password]
2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns 8
bytes in row buffer at 100499f78
2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows at
100499f90
2(2744) DEBUG: db_postgres [km_res.c:243]:
PQgetvalue(10046f6d0,0,0)=[test1234]
2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
Column[password]=[test1234]
2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row values
at 100499fb0
2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]: freeing
row buffer at 100499f78
2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50) result set
2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
'1793af7ca4c2a2feb31410fb6c113695'
2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 100499f58
2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at 100499f28
2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at 100499f40
2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234' at
100499fe0
2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
2(2744) ERROR: *** cfgtrace:
c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27 n=auth_challenge
2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
realm='akanvoice.com'
2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate: Digest
realm="akanvoice.com", nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's
table contains the plain
text password. Should the calculated HA1 string match the HA1 value
in the database?
no, if clear text password is used, the ha1 column is not
important at
all.
If you work with default config, it's really strange, I tested and all
goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> can you paste the module parameters for auth and auth_db module?
> Or check the combination of password column and calculate_ha1 are ok.
>
> I guess you are using your custom configuration file, maybe you
> can give a quick test with default configuration just to see if
> the passwords match.
>
> Cheers,
> Daniel
>
>
> On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
>> Hello,
>>
>> we are testing the new version of Kamailio, 3.3 and are getting
>> authentication error when trying to register a sip account. We
>> have a db backend in which we used kamctl to add the user to the
>> db. We are using the kamailio.cfg script created during the
>> install with changes for our environment. Is there some other
>> changes required besides the normal. I can see in the logs where
>> everything looks ok except for when it compares the calculated
>> values. I have doubled check the subscriber table and password
>> but to no avail.
>>
>> 11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
>> result set
>> 11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string
>> calculated: e13d569284e76a33ca63e4d6203f844a
>> 11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
>> '18210b5da2b3d27e6ba50977072599ea'
>> 11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
>> failed
>>
>>
>> Thanks
>>
>> Nathaniel
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
24 Sep
24 Sep
1:21 p.m.
Hello,
all seems ok from the logs, have you checked the realm in the
authorization header, is it the right one? Maybe you can just paste the
trace for a registration that fails.
I can think of anything else that could go wrong, this part of the code
is used a lot. I assume it is a well known user agent/phone that can't
have a broken implementation.
Cheers,
Daniel
On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
here is the output from the log file of the test
user:
2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
10046f6d0 (7) - [select password from subscriber where username='test'
AND domain='akanvoice.com']
2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result
set at 10049a018
2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
the query
2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
names at 100499f28
2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
types at 100499f40
2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
RES_NAMES[0] at 100499f58
2(2744) DEBUG: db_postgres [km_res.c:133]:
RES_NAMES(100499f58)[0]=[password]
2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns 8
bytes in row buffer at 100499f78
2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows at
100499f90
2(2744) DEBUG: db_postgres [km_res.c:243]:
PQgetvalue(10046f6d0,0,0)=[test1234]
2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
Column[password]=[test1234]
2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
values at 100499fb0
2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]: freeing
row buffer at 100499f78
2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
result set
2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
'1793af7ca4c2a2feb31410fb6c113695'
2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 100499f58
2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at 100499f28
2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at 100499f40
2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234' at
100499fe0
2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
2(2744) ERROR: *** cfgtrace:
c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
n=auth_challenge
2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
realm='akanvoice.com'
2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
Digest realm="akanvoice.com",
nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's
table contains the
plain text password. Should the calculated HA1 string match the HA1
value in the database?
no, if clear text password is used, the ha1 column is not
important
at all.
If you work with default config, it's really strange, I tested and
all goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
[...]
27 Sep
27 Sep
7:26 a.m.
I am using the Jitsi sip client and tried the X-Lite sip client. I am
not able to authenticate with either. I am including a text with the sip
messages and some of kamailio logs.
Thanks
Nathaniel
On 9/24/12 3:21 AM, Daniel-Constantin Mierla wrote:
Hello,
all seems ok from the logs, have you checked the realm in the
authorization header, is it the right one? Maybe you can just paste
the trace for a registration that fails.
I can think of anything else that could go wrong, this part of the
code is used a lot. I assume it is a well known user agent/phone that
can't have a broken implementation.
Cheers,
Daniel
On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
here is the output from the log file of the test
user:
2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
10046f6d0 (7) - [select password from subscriber where
username='test' AND domain='akanvoice.com']
2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result
set at 10049a018
2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
the query
2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
names at 100499f28
2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
types at 100499f40
2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
RES_NAMES[0] at 100499f58
2(2744) DEBUG: db_postgres [km_res.c:133]:
RES_NAMES(100499f58)[0]=[password]
2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns 8
bytes in row buffer at 100499f78
2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows at
100499f90
2(2744) DEBUG: db_postgres [km_res.c:243]:
PQgetvalue(10046f6d0,0,0)=[test1234]
2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
Column[password]=[test1234]
2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
values at 100499fb0
2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]:
freeing row buffer at 100499f78
2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
result set
2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
'1793af7ca4c2a2feb31410fb6c113695'
2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 100499f58
2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at 100499f28
2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at 100499f40
2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234'
at 100499fe0
2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
2(2744) ERROR: *** cfgtrace:
c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
n=auth_challenge
2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
realm='akanvoice.com'
2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
Digest realm="akanvoice.com",
nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
Yes, the password column of the subscriber's
table contains the
plain text password. Should the calculated HA1 string match the HA1
value in the database?
no, if clear text password is used, the ha1 column is not
important
at all.
If you work with default config, it's really strange, I tested and
all goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
[...]
8:12 p.m.
Can you sent the attachment in text format so it can be read from any
device? It should be just text content anyhow.
Cheers,
Daniel
On 9/27/12 4:26 AM, Nathaniel L Keeling III wrote:
I am using the Jitsi sip client and tried the X-Lite
sip client. I am
not able to authenticate with either. I am including a text with the
sip messages and some of kamailio logs.
Thanks
Nathaniel
On 9/24/12 3:21 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hello,
all seems ok from the logs, have you checked the realm in the
authorization header, is it the right one? Maybe you can just paste
the trace for a registration that fails.
I can think of anything else that could go wrong, this part of the
code is used a lot. I assume it is a well known user agent/phone that
can't have a broken implementation.
Cheers,
Daniel
On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
here is the output from the log file of the test
user:
2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
10046f6d0 (7) - [select password from subscriber where
username='test' AND domain='akanvoice.com']
2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result
set at 10049a018
2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
the query
2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
names at 100499f28
2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
types at 100499f40
2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
RES_NAMES[0] at 100499f58
2(2744) DEBUG: db_postgres [km_res.c:133]:
RES_NAMES(100499f58)[0]=[password]
2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns 8
bytes in row buffer at 100499f78
2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows at
100499f90
2(2744) DEBUG: db_postgres [km_res.c:243]:
PQgetvalue(10046f6d0,0,0)=[test1234]
2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
Column[password]=[test1234]
2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
values at 100499fb0
2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]:
freeing row buffer at 100499f78
2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
result set
2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
'1793af7ca4c2a2feb31410fb6c113695'
2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 100499f58
2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at 100499f28
2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at 100499f40
2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234'
at 100499fe0
2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
2(2744) ERROR: *** cfgtrace:
c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
n=auth_challenge
2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
realm='akanvoice.com'
2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
Digest realm="akanvoice.com",
nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
> Yes, the password column of the subscriber's table contains the
> plain text password. Should the calculated HA1 string match the
> HA1 value in the database?
no, if clear text password is used, the ha1 column is not important
at all.
If you work with default config, it's really strange, I tested and
all goes fine. Can you add a temporary account with a simple
username/password to be sure no typo can happen and test again?
Cheers,
Daniel
[...]
28 Sep
28 Sep
2:36 a.m.
Sorry, I thought I had saved it in plain text format. I have included
the right file.
Thanks
Nathaniel
On 9/27/12 10:12 AM, Daniel-Constantin Mierla wrote:
Can you sent the attachment in text format so it can
be read from any
device? It should be just text content anyhow.
Cheers,
Daniel
On 9/27/12 4:26 AM, Nathaniel L Keeling III wrote:
I am using the Jitsi sip client and tried the
X-Lite sip client. I am
not able to authenticate with either. I am including a text with the
sip messages and some of kamailio logs.
Thanks
Nathaniel
On 9/24/12 3:21 AM, Daniel-Constantin Mierla wrote:
Hello,
all seems ok from the logs, have you checked the realm in the
authorization header, is it the right one? Maybe you can just paste
the trace for a registration that fails.
I can think of anything else that could go wrong, this part of the
code is used a lot. I assume it is a well known user agent/phone
that can't have a broken implementation.
Cheers,
Daniel
On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
here is the output from the log file of the test
user:
2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
10046f6d0 (7) - [select password from subscriber where
username='test' AND domain='akanvoice.com']
2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result
set at 10049a018
2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
the query
2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
names at 100499f28
2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
types at 100499f40
2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
RES_NAMES[0] at 100499f58
2(2744) DEBUG: db_postgres [km_res.c:133]:
RES_NAMES(100499f58)[0]=[password]
2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns
8 bytes in row buffer at 100499f78
2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows
at 100499f90
2(2744) DEBUG: db_postgres [km_res.c:243]:
PQgetvalue(10046f6d0,0,0)=[test1234]
2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
Column[password]=[test1234]
2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
values at 100499fb0
2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]:
freeing row buffer at 100499f78
2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
result set
2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
'1793af7ca4c2a2feb31410fb6c113695'
2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at
100499f58
2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at
100499f28
2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at
100499f40
2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234'
at 100499fe0
2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
2(2744) ERROR: *** cfgtrace:
c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
n=auth_challenge
2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
realm='akanvoice.com'
2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
Digest realm="akanvoice.com",
nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
Thanks
Nathaniel
On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
>> Yes, the password column of the subscriber's table contains the
>> plain text password. Should the calculated HA1 string match the
>> HA1 value in the database?
> no, if clear text password is used, the ha1 column is not
> important at all.
>
> If you work with default config, it's really strange, I tested and
> all goes fine. Can you add a temporary account with a simple
> username/password to be sure no typo can happen and test again?
>
> Cheers,
> Daniel
> [...]
11:57 a.m.
Hi,
I have not been that much in Kamailio yet, but I can see the following
messages:
UAC UAS
REGISTER -----> (CSeq=1)
401 Unauth. <--
REGISTER -----> (CSeq=1)
401 Unauth. <--
I am missing the answer from the UAC where it solves the challange and
sends another Register with CSeq=2.
But maybe I just missunderstand the logfiles, so correct me if I'm wrong.
greeetz moritz
Am 27.09.2012 23:36, schrieb Nathaniel L Keeling III:
Sorry, I thought I had saved it in plain text format.
I have included
the right file.
Thanks
Nathaniel
On 9/27/12 10:12 AM, Daniel-Constantin Mierla wrote:
--
Freundliche Grüße
Moritz Graf, B.Sc.
Betrieb NGN-Plattform
G-FIT GmbH & Co. KG
Greflingerstr. 26, 93055 Regensburg
Telefon +49 (9 41) 69 85 - 1 86
Telefax +49 (9 41) 69 85 - 2 86
mailto:moritz.graf@g-fit.de
http://www.g-fit.de
G-FIT Gesellschaft für innovative Telekommunikationsdienste mbH & Co.
KG, Kommanditgesellschaft, Sitz Regensburg, Registergericht Regensburg,
HRA 7626; Geschäftsführer: Dipl.Inf. (FH) Alfred Rauscher
Can you sent the attachment in text format so it
can be read from any
device? It should be just text content anyhow.
Cheers,
Daniel
On 9/27/12 4:26 AM, Nathaniel L Keeling III wrote:
I am using the Jitsi sip client and tried the
X-Lite sip client. I am
not able to authenticate with either. I am including a text with the
sip messages and some of kamailio logs.
Thanks
Nathaniel
On 9/24/12 3:21 AM, Daniel-Constantin Mierla wrote:
Hello,
all seems ok from the logs, have you checked the realm in the
authorization header, is it the right one? Maybe you can just paste
the trace for a registration that fails.
I can think of anything else that could go wrong, this part of the
code is used a lot. I assume it is a well known user agent/phone
that can't have a broken implementation.
Cheers,
Daniel
On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
> here is the output from the log file of the test user:
>
> 2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
> 10046f6d0 (7) - [select password from subscriber where
> username='test' AND domain='akanvoice.com']
> 2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result
> set at 10049a018
> 2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
> PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
> 2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
> the query
> 2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
> names at 100499f28
> 2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
> types at 100499f40
> 2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
> RES_NAMES[0] at 100499f58
> 2(2744) DEBUG: db_postgres [km_res.c:133]:
> RES_NAMES(100499f58)[0]=[password]
> 2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
> 2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns
> 8 bytes in row buffer at 100499f78
> 2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows
> at 100499f90
> 2(2744) DEBUG: db_postgres [km_res.c:243]:
> PQgetvalue(10046f6d0,0,0)=[test1234]
> 2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
> Column[password]=[test1234]
> 2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
> values at 100499fb0
> 2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
> 2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
> STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]:
> freeing row buffer at 100499f78
> 2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
> result set
> 2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
> '1793af7ca4c2a2feb31410fb6c113695'
> 2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
> 2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
> 2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at
> 100499f58
> 2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at
> 100499f28
> 2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at
> 100499f40
> 2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
> 2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234'
> at 100499fe0
> 2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
> 2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
> 2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
> 2(2744) ERROR: *** cfgtrace:
> c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
> n=auth_challenge
> 2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
> realm='akanvoice.com'
> 2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
> Digest realm="akanvoice.com",
nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
>
> Thanks
>
> Nathaniel
> On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
>>> Yes, the password column of the subscriber's table contains the
>>> plain text password. Should the calculated HA1 string match the
>>> HA1 value in the database?
>> no, if clear text password is used, the ha1 column is not
>> important at all.
>>
>> If you work with default config, it's really strange, I tested and
>> all goes fine. Can you add a temporary account with a simple
>> username/password to be sure no typo can happen and test again?
>>
>> Cheers,
>> Daniel
>> [...]
>
1 Oct
1 Oct
12:30 a.m.
The sequence is not changing and the authorization header is not being
sent in the subsequent registrar request. This is why I can not
authenticate. My question would be why would this occurring?
Thanks
Nathaniel
On 9/28/12 1:57 AM, Moritz Graf wrote:
Hi,
I have not been that much in Kamailio yet, but I can see the following
messages:
UAC UAS
REGISTER -----> (CSeq=1)
401 Unauth. <--
REGISTER -----> (CSeq=1)
401 Unauth. <--
I am missing the answer from the UAC where it solves the challange and
sends another Register with CSeq=2.
But maybe I just missunderstand the logfiles, so correct me if I'm wrong.
greeetz moritz
Am 27.09.2012 23:36, schrieb Nathaniel L Keeling III:
Sorry, I thought I had saved it in plain text
format. I have included
the right file.
Thanks
Nathaniel
On 9/27/12 10:12 AM, Daniel-Constantin Mierla wrote:
> Can you sent the attachment in text format so it can be read from any
> device? It should be just text content anyhow.
>
> Cheers,
> Daniel
>
> On 9/27/12 4:26 AM, Nathaniel L Keeling III wrote:
>> I am using the Jitsi sip client and tried the X-Lite sip client. I am
>> not able to authenticate with either. I am including a text with the
>> sip messages and some of kamailio logs.
>>
>> Thanks
>>
>> Nathaniel
>>
>> On 9/24/12 3:21 AM, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> all seems ok from the logs, have you checked the realm in the
>>> authorization header, is it the right one? Maybe you can just paste
>>> the trace for a registration that fails.
>>>
>>> I can think of anything else that could go wrong, this part of the
>>> code is used a lot. I assume it is a well known user agent/phone
>>> that can't have a broken implementation.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
>>>> here is the output from the log file of the test user:
>>>>
>>>> 2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
>>>> 10046f6d0 (7) - [select password from subscriber where
>>>> username='test' AND domain='akanvoice.com']
>>>> 2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for
result
>>>> set at 10049a018
>>>> 2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
>>>> PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
>>>> 2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
>>>> the query
>>>> 2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for
result
>>>> names at 100499f28
>>>> 2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for
result
>>>> types at 100499f40
>>>> 2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
>>>> RES_NAMES[0] at 100499f58
>>>> 2(2744) DEBUG: db_postgres [km_res.c:133]:
>>>> RES_NAMES(100499f58)[0]=[password]
>>>> 2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
>>>> 2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns
>>>> 8 bytes in row buffer at 100499f78
>>>> 2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows
>>>> at 100499f90
>>>> 2(2744) DEBUG: db_postgres [km_res.c:243]:
>>>> PQgetvalue(10046f6d0,0,0)=[test1234]
>>>> 2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
>>>> Column[password]=[test1234]
>>>> 2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
>>>> values at 100499fb0
>>>> 2(2744) DEBUG: <core> [db_val.c:117]: converting STRING
[test1234]
>>>> 2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory
for
>>>> STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]:
>>>> freeing row buffer at 100499f78
>>>> 2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
>>>> result set
>>>> 2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
>>>> '1793af7ca4c2a2feb31410fb6c113695'
>>>> 2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
>>>> 2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
>>>> 2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at
>>>> 100499f58
>>>> 2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at
>>>> 100499f28
>>>> 2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at
>>>> 100499f40
>>>> 2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
>>>> 2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0]
'test1234'
>>>> at 100499fe0
>>>> 2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at
100499fb0
>>>> 2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
>>>> 2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at
10049a018
>>>> 2(2744) ERROR: *** cfgtrace:
>>>> c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
>>>> n=auth_challenge
>>>> 2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
>>>> realm='akanvoice.com'
>>>> 2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
>>>> Digest realm="akanvoice.com",
nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
>>>>
>>>> Thanks
>>>>
>>>> Nathaniel
>>>> On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
>>>>>> Yes, the password column of the subscriber's table contains
the
>>>>>> plain text password. Should the calculated HA1 string match the
>>>>>> HA1 value in the database?
>>>>> no, if clear text password is used, the ha1 column is not
>>>>> important at all.
>>>>>
>>>>> If you work with default config, it's really strange, I tested
and
>>>>> all goes fine. Can you add a temporary account with a simple
>>>>> username/password to be sure no typo can happen and test again?
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>> [...]
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
22 Sep
22 Sep
1:45 a.m.
New subject: Fwd: Re: Registration Authentication Error
-------- Original Message --------
Subject: Re: [SR-Users] Registration Authentication Error
Date: Fri, 21 Sep 2012 07:43:14 -0500
From: Nathaniel L Keeling III <keeling(a)akan-tech.com>
To: miconda(a)gmail.com
CC: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List <sr-users(a)lists.sip-router.org>
Yes, the password column of the subscriber's table contains the plain
text password. Should the calculated HA1 string match the HA1 value in
the database?
Thanks
Nathaniel
On 9/21/12 2:21 AM, Daniel-Constantin Mierla wrote:
Hello,
this requires the plain text password to be in the column 'password'
of the subscriber table, do you have it? I am asking because many
people keep only ha1/ha1b.
Cheers,
Daniel
On 9/21/12 2:35 AM, Nathaniel L Keeling III wrote:
Here is the parameters for auth_db:
modparam("auth_db", "db_url", DBURL)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "")
modparam("auth_db", "use_domain", MULTIDOMAIN)
This is the default config file with just setting the DBURL, IP
address, port and the defines.
Thanks
Nathaniel
On 9/19/12 1:45 AM, Daniel-Constantin Mierla wrote:
Hello,
can you paste the module parameters for auth and auth_db module? Or
check the combination of password column and calculate_ha1 are ok.
I guess you are using your custom configuration file, maybe you can
give a quick test with default configuration just to see if the
passwords match.
Cheers,
Daniel
On 9/18/12 4:58 PM, Nathaniel L Keeling III wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
we are testing the new version of Kamailio, 3.3 and are getting
authentication error when trying to register a sip account. We have
a db backend in which we used kamctl to add the user to the db. We
are using the kamailio.cfg script created during the install with
changes for our environment. Is there some other changes required
besides the normal. I can see in the logs where everything looks ok
except for when it compares the calculated values. I have doubled
check the subscriber table and password but to no avail.
11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560)
result set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization
failed
Thanks
Nathaniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
19 Sep
19 Sep
3:32 p.m.
On 09/18/2012 04:58 PM, Nathaniel L Keeling III wrote:
11(28548) DEBUG: db_postgres [km_dbase.c:393]:
PQclear(1008b8560) result
set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed
What realm do you use for proxy_challenge? Does it match the realm
configured in the client?
You can calculate and check the digest response yourself by using a
simple script like
http://code.google.com/p/variman/source/browse/website/trunk/docroot/suppor…
20 Sep
20 Sep
7:46 p.m.
The realm is the same as the client. I was using the $fd variable but
then switch it to the actual domain name and I still do not
authenticate. It seems like the HA1 calculation is different. Our setup
is for multi-domain and we've placed the domain name in the domain
table. Is there something else that needs to be done. The user was added
using the kamclt add user command.
Thanks
Nathaniel
On 9/19/12 5:32 AM, Andrew Pogrebennyk wrote:
On 09/18/2012 04:58 PM, Nathaniel L Keeling III
wrote:
11(28548) DEBUG: db_postgres [km_dbase.c:393]:
PQclear(1008b8560) result
set
11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated:
e13d569284e76a33ca63e4d6203f844a
11(28548) DEBUG: auth [api.c:211]: check_response: Our result =
'18210b5da2b3d27e6ba50977072599ea'
11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed
What realm
do you use for proxy_challenge? Does it match the realm
configured in the client?
You can calculate and check the digest response yourself by using a
simple script like
http://code.google.com/p/variman/source/browse/website/trunk/docroot/suppor…
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4236
days inactive
4248
days old
18 comments
5 participants
participants (5)
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
Moritz Graf -
Nathaniel L Keeling III -
Nathaniel L Keeling III