ASTERISK-01710: Failed SIP md5 REGISTER in two simultaneous requests

[Home]

Summary: ASTERISK-01710: Failed SIP md5 REGISTER in two simultaneous requests

Reporter: lvazquez (lvazquez) Labels:

Date Opened: 2004-05-27 12:39:15 Date Closed: 2011-06-07 14:04:39

Priority: Major Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) sip.patch.txt

Description: Trying registering two extensions (sip clients) from a SIP gateway into Asterisk using md5 authenticatiion the first one is rejected because Asterisk is using the nonce sent to the second one to validate the hash from the first one.
ATENTION: This is not easy of reproduce because depends on the order an maybe timing of the requests, don't close the bug report simply because YOU are not able to reproduce it!
Follow the logic in the sip session example and apply the patch to chan_sip.c in order to see the debug messages in aterisk console.

****** STEPS TO REPRODUCE ******

1 - Configure a two fxs ports sip gateway (VIP 450 in this case) to register two sip numbers (sip clients) with diferent usernames (configured in sip.conf).
2 - Insert ast_log() calls in register_verify() an check_auth() functions in chan_sip.c
2 - Restart the gateway an look the logs in:
- VIP console
- ngrep SIP port 5060 and host ....
- Asterisk console

****** ADDITIONAL INFORMATION ******

I guess I found a bug in the register logic in chan_sip

I'm trying of registering two extensions from a SIP gateway into Asterisk.
I have defined two user entries in sip.conf as follows:
[0191]
type = friend
auth=md5
username=0191
secret=planet
disallow=all
allow=ulaw
dtmfmode=inband
host = dynamic
default = 192.168.2.183

[0192]
type = friend
auth=md5
username=0192
secret=planet
disallow=all
allow=ulaw
dtmfmode=inband
host = dynamic
default = 192.168.2.183

And configured the gateway to register to asterisk (192.168.2.175) both numbers with these username and passwords.
***************************
reg_num: 0191
Registrar_ID 1: UnRegistered
registrar: 192.168.2.175 5060 expires: 600
name: 0191 passwd: planet
reg_num: 0192
Registrar_ID 2: Registered
registrar: 192.168.2.175 5060 expires: 600
name: 0192 passwd: planet
***************************

When I reset the gateway I see the first sip user (0191) FAILS to register, but the second one (0192) registers OK.
I first thought there was a problem with the digest response from the gateway but after logging the SIP headers, and
reading the RFC's and use md5sum to check the digest values I realiced the values from the cliente where OK.

In inserted some ast_log(LOG_NOTICE, "..") into the chan_sip.c 's register_verify() and check_auth() functions
and found the problem is in Asterisk.
As you can see It seems for some reason when Asterisk receives both REGISTER request messages one after the other,
he is mixing the nonce value (called randdata into chan_sip.c) for one peer with the other.
So he ends evaluating the digest for the first register (0191) using the nonce value from the second one (0192) and It fails.
For some reason (I think It is because the randdata is resetted to '' after 0191 fails) the second register (0192) gets a second "407 Proxy Authentication Required" with a third randdata and this time It is registered OK because the right nonce value is used.

I'm using Asterisk CVS version from 2004/05/19.
Here follow the console log (with my LOG_NOTICE debug messages) and the corresponding ngrep SIP capture. Look specially the randdata values used in check_auth (nonce value) and the (not) corresponding values sent in the SIP responses for each REGISTER.

Everyone can check the response="..." sent by the gateway are ok using something like this:

A1=$(echo -n '0192:asterisk:planet'|md5sum|awk '{print $1}')
A2=$(echo -n 'REGISTER:sip:192.168.2.175'|md5sum|awk '{print $1}')
NONCE=17e63cd4
$(echo -n "$A1:$NONCE:$A2"|md5sum|awk '{print $1}')

*****************************************
*****************************************
Asterisk Console Logs
*****************************************
May 26 16:56:47 NOTICE[196621]: chan_sip.c:3861 register_verify: Checking Auth: randata= name=0191 secret=planet uri=sip:192.168.2.175
May 26 16:56:47 NOTICE[196621]: chan_sip.c:3861 register_verify: Checking Auth: randata=17e63cd4 name=0192 secret=planet uri=sip:192.168.2.175
May 26 16:56:47 NOTICE[196621]: chan_sip.c:3861 register_verify: Checking Auth: randata=49760cde name=0191 secret=planet uri=sip:192.168.2.175
May 26 16:56:47 WARNING[196621]: chan_sip.c:3764 check_auth: A1='0191:asterisk:planet'
May 26 16:56:47 WARNING[196621]: chan_sip.c:3769 check_auth: resp_uri='sip:192.168.2.175' uri='sip:192.168.2.175'
May 26 16:56:47 WARNING[196621]: chan_sip.c:3770 check_auth: A2='REGISTER:sip:192.168.2.175'
May 26 16:56:47 WARNING[196621]: chan_sip.c:3778 check_auth: resp='160723a2f5a8dcf360271903c6818b63:49760cde:c70c5186f40f678679f57680d2a4390d' resp_hash='267b05f67388676fcffb6bd3ee381b2e'
May 26 16:56:47 WARNING[196621]: chan_sip.c:3781 check_auth: Client response='406d89d8d15ba1c9753b5bef95931934'
May 26 16:56:47 NOTICE[196621]: chan_sip.c:5691 handle_request: Registration from '<sip:0191@192.168.2.175>' failed for '192.168.2.183'
May 26 16:56:48 NOTICE[196621]: chan_sip.c:3861 register_verify: Checking Auth: randata= name=0192 secret=planet uri=sip:192.168.2.175
May 26 16:56:48 NOTICE[196621]: chan_sip.c:3861 register_verify: Checking Auth: randata=23b5124b name=0192 secret=planet uri=sip:192.168.2.175
May 26 16:56:48 WARNING[196621]: chan_sip.c:3764 check_auth: A1='0192:asterisk:planet'
May 26 16:56:48 WARNING[196621]: chan_sip.c:3769 check_auth: resp_uri='sip:192.168.2.175' uri='sip:192.168.2.175'
May 26 16:56:48 WARNING[196621]: chan_sip.c:3770 check_auth: A2='REGISTER:sip:192.168.2.175'
May 26 16:56:48 WARNING[196621]: chan_sip.c:3778 check_auth: resp='c04abf6412f4f786ba81daddb46a82ee:23b5124b:c70c5186f40f678679f57680d2a4390d' resp_hash='c370755ec882aafa390ff867d1a99449'
May 26 16:56:48 WARNING[196621]: chan_sip.c:3781 check_auth: Client response='c370755ec882aafa390ff867d1a99449'

********************************************************************
interface: eth0 (192.168.2.0/255.255.255.0)
filter: ip and ( port 5060 and host 192.168.2.183 )
#
U 192.168.2.183:5060 -> 192.168.2.175:5060
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d30-3ba-7cab
Max-Forwards: 70
Contact: <sip:0191@192.168.2.183:5060>
Expires: 600
Content-Length:0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d30-3ba-7cab
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>;tag=as46f74385
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0191@192.168.2.175>
Content-Length: 0
..

#
U 192.168.2.183:5060 -> 192.168.2.175:5060
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 2 REGISTER
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d30-3e0-3887
Max-Forwards: 70
Contact: <sip:0192@192.168.2.183:5060>
Expires: 600
Content-Length:0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d30-3ba-7cab
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>;tag=as46f74385
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0191@192.168.2.175>
Proxy-Authenticate: Digest realm="asterisk", nonce="17e63cd4"
Content-Length: 0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d30-3e0-3887
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as46f74385
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0192@192.168.2.175>
Content-Length: 0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d30-3e0-3887
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as46f74385
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0192@192.168.2.175>
Proxy-Authenticate: Digest realm="asterisk", nonce="49760cde"
Content-Length: 0

#
U 192.168.2.183:5060 -> 192.168.2.175:5060
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 3 REGISTER
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-64a-7bdd
Max-Forwards: 70
Contact: <sip:0191@192.168.2.183:5060>
Expires: 600
Proxy-Authorization: Digest username="0191", realm="asterisk", nonce="17e63cd4", uri="sip:192.168.2.175", response="406d89d8d15ba1c9753b5bef95931934", algorithm=MD5
Content-Length:0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-64a-7bdd
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>;tag=as46f74385
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 3 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0191@192.168.2.175>
Content-Length: 0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-64a-7bdd
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>;tag=as46f74385
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 3 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0191@192.168.2.175>
Content-Length: 0

#
U 192.168.2.183:5060 -> 192.168.2.175:5060
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 4 REGISTER
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-694-5623
Max-Forwards: 70
Contact: <sip:0192@192.168.2.183:5060>
Expires: 600
Proxy-Authorization: Digest username="0191", realm="asterisk", nonce="49760cde", uri="sip:192.168.2.175", response="267b05f67388676fcffb6bd3ee381b2e", algorithm=MD5
Content-Length:0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-694-5623
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as2bac3737
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 4 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0192@192.168.2.175>
Content-Length: 0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-694-5623
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as2bac3737
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 4 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0192@192.168.2.175>
Proxy-Authenticate: Digest realm="asterisk", nonce="23b5124b"
Content-Length: 0

#
U 192.168.2.183:5060 -> 192.168.2.175:5060
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 5 REGISTER
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-722-78d9
Max-Forwards: 70
Contact: <sip:0192@192.168.2.183:5060>
Expires: 600
Proxy-Authorization: Digest username="0192", realm="asterisk", nonce="23b5124b", uri="sip:192.168.2.175", response="c370755ec882aafa390ff867d1a99449", algorithm=MD5
Content-Length:0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-722-78d9
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as2bac3737
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 5 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:0192@192.168.2.175>
Content-Length: 0

#
U 192.168.2.175:5060 -> 192.168.2.183:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-722-78d9
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as2bac3737..Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 5 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Expires: 600
Contact: <sip:0192@192.168.2.175>;expires=600
Date: Wed, 26 May 2004 19:56:48 GMT
Content-Length: 0
*************************************************

Comments: By: Olle Johansson (oej) 2004-05-27 14:02:35

In this packet, your client tries to register 0192 with Digest username 0191.
That will indeed break the authentication :-)
Please confirm that the copy you made is correct and that this is the problem.
------------------------------

U 192.168.2.183:5060 -> 192.168.2.175:5060
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
CSeq: 4 REGISTER
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-694-5623
Max-Forwards: 70
Contact: <sip:0192@192.168.2.183:5060>
Expires: 600
Proxy-Authorization: Digest username="0191", realm="asterisk", nonce="49760cde", uri="sip:192.168.2.175", response="267b05f67388676fcffb6bd3ee381b2e", algorithm=MD5
Content-Length:0
By: Olle Johansson (oej) 2004-05-27 14:04:21

Also, please set your realm= - this is not related to this bug, but good behaviour in a SIP world :-)
By: lvazquez (lvazquez) 2004-05-27 15:05:40

Let me check it, but it seems you are right!! I suppose it must be a bug in the firmware of this gateway (planet vip 450).
I will write you again to comfirm.
The realm is not a problem by now, this is the testing/development installation, and only running testings into a private network.
Bye
By: khb (khb) 2004-05-27 15:28:59

I don't know if you saw my response on the board. Indeed I couldn't duplicate your error and asked you to repeat my check with a different agent with dual registration capability.
It seems to me that your gateway is sending the same call id for both requests and therefore Asterisk has to assume the second request is just a resend of the first. It has no way of knowing which register request goes with which nonce.
So, rather than Asterisk mixing up the requests, I think it's your gateways that is confused.

"default" should be "defaultip"
and "auth=" has been removed.
By: lvazquez (lvazquez) 2004-05-27 15:46:36

I just checked again, but it is strange. You are partially right, but the username not registered is 0191, and the first authenticated register from 0191 is correct, with the correct nonce and asterisk reject this.
Let's look this resumed sip secuence showing only the challenge-response sip packets taken from my post:
------------------

.......
SIP/2.0 407 Proxy Authentication Required
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>;tag=as46f74385
Proxy-Authenticate: Digest realm="asterisk", nonce="17e63cd4"
.....
SIP/2.0 407 Proxy Authentication Required
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as46f74385
Proxy-Authenticate: Digest realm="asterisk", nonce="49760cde"
........

So here we have the nonces: 0191=>17e63cd4 0192=>49760cde
Now comes the auth register from 0191 and it seems ok!:

REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>
Proxy-Authorization: Digest username="0191"(OK!!), realm="asterisk", nonce="17e63cd4", uri="sip:192.168.2.175", response="406d89d8d15ba1c9753b5bef95931934", algorithm=MD5

**** Observer it is all right! Correct nonce, and correct response. But the response from asterisk is:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.183:5060;branch=z9hG4bK-5d31-64a-7bdd
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>;tag=as46f74385

And then comes the wrong SIP REGISTER request for username 0192 as you ponted, but it's AFTER Asterisk responds rejecting 0191, maybe the gateway "gets crazy" after the previous not expected 401???

REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Proxy-Authorization: Digest username="0191"(WRONG!!), realm="asterisk", nonce="49760cde", uri="sip:192.168.2.175", response="267b05f67388676fcffb6bd3ee381b2e", algorithm=MD5

After this Asterisk gives a second change to 0192 and he registers ok:

SIP/2.0 407 Proxy Authentication Required
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as2bac3737
Proxy-Authenticate: Digest realm="asterisk", nonce="23b5124b"
..........
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Proxy-Authorization: Digest username="0192"(OK!!), realm="asterisk", nonce="23b5124b", uri="sip:192.168.2.175", response="c370755ec882aafa390ff867d1a99449", algorithm=MD5
...........
SIP/2.0 200 OK
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>;tag=as2bac3737..Call-ID: c0a802b7-13c4-5d30-212-68f

---------------------------
With those REGISTER requests:
No auth
1) 0191@asterisk
2) 0192@asterisk
Auth
3) 0191@asterisk with username => '0191' nonce => 17e63cd4 (OK)
4) 0192@asterisk with username => '0191' nonce => 49760cde (BAD)
.....
No auth
5) 0192@asterisk
6) 0192@asterisk with username => '0192' nonce => 23b5124b (OK)

I don't understand how register_verify is called only 5 times and with these values:

1)NO randdata: register_verify: Checking Auth: randata= name=0191 secret=planet uri=sip:192.168.2.175
This is wrong but do not corresponds with any of the requests:
2)randdata(WRONG): register_verify: Checking Auth: randata=17e63cd4(0191's) name=0192 secret=planet uri=sip:192.168.2.175
3)randdata(WRONG AGAIN) register_verify: Checking Auth: randata=49760cde(0192's) name=0191 secret=planet uri=sip:192.168.2.175

4)NO randata: register_verify: Checking Auth: randata= name=0192 secret=planet uri=sip:192.168.2.175
5)randata(OK): register_verify: Checking Auth: randata=23b5124b name=0192 secret=planet uri=sip:192.168.2.175

The log in register_verify() is before check_auth() is called, and shows the values used by Asterisk to check the registering, before the values sent by the client in Proxy-Authorization: are parsed!

THE END (by now) :)
By: Olle Johansson (oej) 2004-05-27 15:53:37

Just checking: Are you using latest CVS head?
There's been quite a lot of changes to chan_sip recently in regards to how we handle registrations.
By: Olle Johansson (oej) 2004-05-27 16:01:33

Check the CAll-id's:
----
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0191@192.168.2.175>;tag=c0a802b7-13c4-5d30-3b8-4efa
To: <sip:0191@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
----
REGISTER sip:192.168.2.175 SIP/2.0
From: <sip:0192@192.168.2.175>;tag=c0a802b7-13c4-5d30-3de-60c6
To: <sip:0192@192.168.2.175>
Call-ID: c0a802b7-13c4-5d30-212-68f
-----
Using the same call-ID for two different requests. I think this
UA's firmware needs some testing...

Ok to close now, since we've detected two major flaws in the
clients software? :-)

I'm not saying that chan_sip works perfect, but it's very hard to find and correct errors based on communication with an UA with problems like
this.
By: lvazquez (lvazquez) 2004-05-27 16:03:24

>and "auth=" has been removed.
Hello Klaus. If you are right (and I'm sure you are ;) someone should update this page in the asterisk wiki:
http://www.voip-info.org/wiki-Asterisk+sip+channels

On the other side I saw your post but I didn't understand to much what you said.
It is clear now with your observation about the call-id, obvioulsy it is wrong!!
May be it is fooling asterisk.
It seems the Planet folks are doing something wrong with their firmware.
Anyway, Asterisk is mixing up the requests, it's only It seems you found the reason :)
By: lvazquez (lvazquez) 2004-05-27 16:04:58

Ok, lets close it, lets call the chinese folks to get a new firmware an try again
:)
Cheers
By: khb (khb) 2004-05-27 16:11:36

You can try and use the
pedanticsipchecking=yes
option to do extra tag matching if I recall.
It might just work.
By: Olle Johansson (oej) 2004-05-27 16:15:16

Thank you for all your testing, I'm happy this wasn't an error on Asterisks behalf. And I'll update the wiki :-)