Author |
|
juice Vetran
Joined: December 05 2006 Location: United States Posts: 139
|
Posted: June 18 2007 at 8:34pm | IP Logged
|
|
|
Sorry, but I still have not been able to provide much stress testing related to the other posts. However, I'm back again with a new issue (I promise to provide feedback very soon). But, today's tests showed a couple issues with registering multiple user accounts.
First thing which appeared very odd, was that EnableSipRegisterServer, when called multiple times, or called once with a list of two different names - gateway IP/port always the same. And, credentials were added successfully before making the call. The same CallID is always used for each REGISTER sip message generated. First user gets authenticated successfully, then the next user requests REGISTER, and the call id is identical. Always. The call-id should be different for each registration session right?
Second issue, more serious, and causes the second authentication to fail. The second REGISTER sip method looks good (To, From, URI, etc) besides two things. Of course, the Call ID (mentioned above) and then one small line in the Authorization header:
Authorization: Digest algorithm=md5,cnonce="00970605",nc=00000001,nonce="113418d77 06",opaque="5732c8113418d7706",qop=auth,realm="127.0.0.1",re sponse="ec9261ce2a21c7ac1d0a4a0e7606492b",uri="sip:127.0.0.1 ",username="whatever"
The username="whatever" is the same user name that successfuly had registered previously, but should not be in this sip method. As, the username that is attempting to register is "somebody". The To, From, Uri, and contact all have the correct username. However, the username in the auth header is wrong and causes the Sip Registrar to fail to authenticate.
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: June 19 2007 at 3:23pm | IP Logged
|
|
|
Hi juice,
Got that support contract in place yet??? :)
Item 1:
The call-id should be different for each registration session right?
No. As far as we know via RFC3261 and other inter-op with other SIP devices, the call ID is the same for a UA that registers – even if the UA wants to add multiple bindings in the registrar. The CSeq value increments to allow ordering of registrar received REGISTER requests but that’s about it. See section 10 of the RFC for more info.
However, on the other hand, we have been fooled before. If there is something the media engine is not doing or doing improperly regarding REGISERing, make sure to point it out to us.
Item 2:
Possible wrong “username=" in secondary registrations.
Interesting. You have hit something. We performed a test here and we see what you are saying. In this case, we tested against our SIP proxy (which does not care about the “username=” portion of the authentication). Here is the log registering a single media engine as extension 222 and 333:
Code:
************* Log Opened (Jun 19 15:17:13) *************
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#7, 507750 Ms, To: 192.168.1.2:5060) >>>>
REGISTER sip:ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:6060;rport;branch=z9hG4bK00af582d
From: <sip:222@ps>;tag=af1255
To: <sip:222@ps>
Call-Id: de3eaab7-3d94-42db-9d8b-a5e203c6395c-00000f4c@192.168.1.2
CSeq: 10968395 REGISTER
Expires: 36000
Max-Forwards: 70
Contact: <sip:222@192.168.1.2:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.4.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-222: "This is a modified transmitted SIP message."
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#7, 507750 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.2:6060;rport=6060;branch=z9hG4bK00af582d;received= 192.168.1.2
From: <sip:222@ps>;tag=af1255
To: <sip:222@ps>
Call-ID: de3eaab7-3d94-42db-9d8b-a5e203c6395c-00000f4c@192.168.1.2
CSeq: 10968395 REGISTER
WWW-Authenticate: Digest realm="ps", nonce="c9f65010783d064624b8beec0ff41591", opaque="2036a9758c7e73c1736486652205213a"
Server: LanScape Centrex Proxy/3.42.1.10 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#8, 0 Ms, To: 192.168.1.2:5060) >>>>
REGISTER sip:ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:6060;rport;branch=z9hG4bK00af450f
From: <sip:222@ps>;tag=af4ed1
To: <sip:222@ps>
Call-Id: de3eaab7-3d94-42db-9d8b-a5e203c6395c-00000f4c@192.168.1.2
CSeq: 10968396 REGISTER
Authorization: Digest algorithm=md5,nonce="c9f65010783d064624b8beec0ff41591",opaqu e="2036a9758c7e73c1736486652205213a",realm="ps",response="b2 36145399ccc1f6fcac688a7c06ec00",uri="sip:ps",username="222"
Expires: 36000
Max-Forwards: 70
Contact: <sip:222@192.168.1.2:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.4.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-222: "This is a modified transmitted SIP message."
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#8, 0 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:6060;rport=6060;branch=z9hG4bK00af450f;received= 192.168.1.2
From: <sip:222@ps>;tag=af4ed1
To: <sip:222@ps>;tag=15724
Call-ID: de3eaab7-3d94-42db-9d8b-a5e203c6395c-00000f4c@192.168.1.2
CSeq: 10968396 REGISTER
Contact: <sip:222@192.168.1.2:6060>;user=phone;expires=36000
Expires: 36000
Server: LanScape Centrex Proxy/3.42.1.10 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#9, 0 Ms, To: 192.168.1.2:5060) >>>>
REGISTER sip:ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:6060;rport;branch=z9hG4bK00af5370
From: <sip:333@ps>;tag=aefbc8
To: <sip:333@ps>
Call-Id: de3eaab7-3d94-42db-9d8b-a5e203c6395c-00000f4c@192.168.1.2
CSeq: 10968397 REGISTER
Authorization: Digest algorithm=md5,nonce="c9f65010783d064624b8beec0ff41591",opaqu e="2036a9758c7e73c1736486652205213a",realm="ps",response="b2 36145399ccc1f6fcac688a7c06ec00",uri="sip:ps",username="222"
Expires: 36000
Max-Forwards: 70
Contact: <sip:333@192.168.1.2:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.4.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-222: "This is a modified transmitted SIP message."
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#9, 0 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:6060;rport=6060;branch=z9hG4bK00af5370;received= 192.168.1.2
From: <sip:333@ps>;tag=aefbc8
To: <sip:333@ps>;tag=11478
Call-ID: de3eaab7-3d94-42db-9d8b-a5e203c6395c-00000f4c@192.168.1.2
CSeq: 10968397 REGISTER
Contact: <sip:333@192.168.1.2:6060>;user=phone;expires=36000
Expires: 36000
Server: LanScape Centrex Proxy/3.42.1.10 (www.LanScapeCorp.com)
Content-Length: 0
************* Log Closed (Jun 19 15:17:25) *************
|
|
|
What should be happening is the media must not try to use authenticated credentials from a previous REGISTER that was authenticated when the user agent name being registered changes. This is definitely a subtle issue. Good eye.
What SIP registrar server are you trying to REGISTER with? Before we make a fix for a later release, we would like to verify your setup.
Support
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: June 19 2007 at 7:48pm | IP Logged
|
|
|
Hi juice,
After performing the needed changes, we have the behavior we want. The media engine was told to register 222 and 333. Here is the Sip log for the REGISTER cycles:
Code:
************* Log Opened (Jun 19 19:37:21) *************
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#1, 0 Ms, To: 192.168.1.2:5060) >>>>
REGISTER sip:ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:6060;rport;branch=z9hG4bK019d7273
From: <sip:222@ps>;tag=19d5483
To: <sip:222@ps>
Call-Id: 91be777f-8820-472f-a412-87626fecc0a0-00001e5c@192.168.1.2
CSeq: 10318832 REGISTER
Expires: 36000
Max-Forwards: 70
Contact: <sip:222@192.168.1.2:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.4.2 (www.LanScapeCorp.com)
x-CustomHeader-Extension-222: "This is a modified transmitted SIP message."
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#1, 0 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.2:6060;rport=6060;branch=z9hG4bK019d7273;received= 192.168.1.2
From: <sip:222@ps>;tag=19d5483
To: <sip:222@ps>
Call-ID: 91be777f-8820-472f-a412-87626fecc0a0-00001e5c@192.168.1.2
CSeq: 10318832 REGISTER
WWW-Authenticate: Digest realm="ps", nonce="f08da2069fb50d9aabdaf6cd4c1af89b", opaque="873f813472ade354aa9fbb943fec36cb"
Server: LanScape Centrex Proxy/3.42.1.10 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#2, 16 Ms, To: 192.168.1.2:5060) >>>>
REGISTER sip:ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:6060;rport;branch=z9hG4bK019d54a2
From: <sip:222@ps>;tag=19d7309
To: <sip:222@ps>
Call-Id: 91be777f-8820-472f-a412-87626fecc0a0-00001e5c@192.168.1.2
CSeq: 10318833 REGISTER
Authorization: Digest algorithm=md5,nonce="f08da2069fb50d9aabdaf6cd4c1af89b",opaqu e="873f813472ade354aa9fbb943fec36cb",realm="ps",response="62 9465189d730d5cec5d9b8d1d1e5994",uri="sip:ps",username="222"
Expires: 36000
Max-Forwards: 70
Contact: <sip:222@192.168.1.2:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.4.2 (www.LanScapeCorp.com)
x-CustomHeader-Extension-222: "This is a modified transmitted SIP message."
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#2, 16 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:6060;rport=6060;branch=z9hG4bK019d54a2;received= 192.168.1.2
From: <sip:222@ps>;tag=19d7309
To: <sip:222@ps>;tag=15141
Call-ID: 91be777f-8820-472f-a412-87626fecc0a0-00001e5c@192.168.1.2
CSeq: 10318833 REGISTER
Contact: <sip:222@192.168.1.2:6060>;user=phone;expires=36000
Expires: 36000
Server: LanScape Centrex Proxy/3.42.1.10 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#3, 0 Ms, To: 192.168.1.2:5060) >>>>
REGISTER sip:ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:6060;rport;branch=z9hG4bK019d6246
From: <sip:333@ps>;tag=19d6fc5
To: <sip:333@ps>
Call-Id: 91be777f-8820-472f-a412-87626fecc0a0-00001e5c@192.168.1.2
CSeq: 10318834 REGISTER
Authorization: Digest algorithm=md5,nonce="f08da2069fb50d9aabdaf6cd4c1af89b",opaqu e="873f813472ade354aa9fbb943fec36cb",realm="ps",response="fa ed880d1f9e41700f461ead6d034688",uri="sip:ps",username="333"
Expires: 36000
Max-Forwards: 70
Contact: <sip:333@192.168.1.2:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.4.2 (www.LanScapeCorp.com)
x-CustomHeader-Extension-222: "This is a modified transmitted SIP message."
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#3, 0 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:6060;rport=6060;branch=z9hG4bK019d6246;received= 192.168.1.2
From: <sip:333@ps>;tag=19d6fc5
To: <sip:333@ps>;tag=7711
Call-ID: 91be777f-8820-472f-a412-87626fecc0a0-00001e5c@192.168.1.2
CSeq: 10318834 REGISTER
Contact: <sip:333@192.168.1.2:6060>;user=phone;expires=36000
Expires: 36000
Server: LanScape Centrex Proxy/3.42.1.10 (www.LanScapeCorp.com)
Content-Length: 0
************* Log Closed (Jun 19 19:37:28) *************
|
|
|
Note: Ignore the “x-CustomHeader-Extension-222:” headers.
Support
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: June 20 2007 at 2:53pm | IP Logged
|
|
|
juice,
Before we can close out this issue, we need to know the following:
What SIP registrar server are you trying to REGISTER with?
We want to confirm a few test scenarios before we commit the code changes.
By the way, the original behavior of the media engine may seem weird at first but it is perfectly normal. The username and password in the "Authorization:" response headers do not have to match the name of the "user" in the "To:" and "From" SIP headers. It is more appropriate to think of authentication reams as having "login names" and passwords. More that one user (phone) can use the same "login name" and password for either calls or multiple registrations for more than one registrar binding.
The changes you point out however make it a clearer for someone looking at a SIP log. So we will probably keep the latest code changes that generated the above SIP logs.
Thanks,
Support
|
Back to Top |
|
|
juice Vetran
Joined: December 05 2006 Location: United States Posts: 139
|
Posted: June 20 2007 at 5:44pm | IP Logged
|
|
|
First of all, thanks for identifying the issue and making the usernames match.
As for the Call-ID, it seems to me that each registration attempt is a different dialog. Or at least each different user's registration throughout the whole application lifetime are seperate dialogs. Which would require different CallID's for each dialog. However, we can live with the same call id's for all registration attempts coming out of the Media Engine... I mean, call id's are hardly always unique among all devices anyway, where some user agents simply present a number as the Call id.
As for issue two username matching, it may not be required as you say that both match. However, it is indeed confusing to see that, as it could be trying to register to a different Proxy domain I imagine and using some odd username there. The problem was that the proxy we were trying to register to was using that name (for some reason) as a match to a session, and was causing confusing within the proxy. So, as long as you leave that fix (as posted by the last sip message transaction) in the proxy will allow registrations from this media engine.
Thanks.
|
Back to Top |
|
|
|
|