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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users