02-01-2011 01:05 PM - edited 03-21-2019 03:36 AM
Hi,
I've discovered by doing some tests that the Cisco SPA50x (firmware SIP 7.4.4) were able to resynchronize their configuration files by sending them a SIP NOTIFY with event 'check-sync'.
The thing is, by default, if you send such a request, the phone answer with a 401 Unauthorized response. You can then send it another SIP NOTIFY, this time with a valid 'Authorization' header, and the phone will accept your request and answer you with a 200 OK, and resynchronize its configuration files. Now, the problem is that you need to wait at least 10 seconds (20 seconds seems to work for me) before sending the second request, else you receive another 401 Unauthorized, even if the content of the Authorization header either is right.
Now, my question is: is this a bug ? a feature ? Is there any more info about this ?
Tests were on a Cisco SPA508G with SIP firmware 7.4.4.
Thanks
02-08-2011 01:00 PM
Hi Yvan;
I suggest you upgrade to the latest firmware and try again. I have not heard of any issue like this. What kind of protocol the resync is using?
Regards
Alberto
02-09-2011 06:49 AM
Hi,
I'll retry with the newest firmware today or tomorrow. And for information, profile files are downloaded via HTTP (i.e. the profile rules starts with 'http://').
03-15-2011 07:29 AM
Hi,
sorry for the long delay, I was kinda busy recently.
I've done some new tests with firmware 7.4.8 on a SPA508G. The results are the same; if the delay between the first SIP NOTIFY request, which return a 401 from the SPA, and the second NOTIFY, with an Authorization header in it, is too short (i.e. less than maybe 15 seconds; I know it does work fine when using 20 seconds as the delay), then the phone returns a 401 Unauthorized instead of a 200 OK,
Here's some trace (I've changed the domain names):
Correct behavior:
10:08:07.535635 IP (tos 0x0, ttl 64, id 39378, offset 0, flags [DF], proto UDP (17), length 407)
demo-provd.example.com.37242 > 192.168.32.202.sip: SIP, length: 379
NOTIFY sip:4052@192.168.32.202:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.32.104:37242;branch=z9hG4bK474783b419323237
Max-Forwards: 70
To: <4052>
From: <192.168.32.104:37242>;tag=7cb9822
Call-ID: 531904491b682b6fc62682b7959a6cf6
CSeq: 1 NOTIFY
Contact: <192.168.32.104:37242>
Subscription-State: active
Event: check-sync
Content-Length: 0
10:08:07.548232 IP (tos 0x68, ttl 64, id 19, offset 0, flags [none], proto UDP (17), length 430)
192.168.32.202.sip > demo-provd.example.com.37242: SIP, length: 402
SIP/2.0 401 Unauthorized
To: <4052>;tag=2e422a1bf432247fi0
From: <192.168.32.104:37242>;tag=7cb9822
Call-ID: 531904491b682b6fc62682b7959a6cf6
CSeq: 1 NOTIFY
Via: SIP/2.0/UDP 192.168.32.104:37242;branch=z9hG4bK474783b419323237
Server: Cisco/SPA508G-7.4.8
WWW-Authenticate: Digest realm="xivo_proxies", nonce="ab8da357", qop="auth", algorithm=md5
Content-Length: 0
10:08:27.554843 IP (tos 0x0, ttl 64, id 39379, offset 0, flags [DF], proto UDP (17), length 620)
demo-provd.example.com.37242 > 192.168.32.202.sip: SIP, length: 592
NOTIFY sip:4052@192.168.32.202:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.32.104:37242;branch=z9hG4bKaf9405a385d3af75
Max-Forwards: 70
To: <4052>
From: <192.168.32.104:37242>;tag=7cb9822
Call-ID: 531904491b682b6fc62682b7959a6cf6
CSeq: 1 NOTIFY
Contact: <192.168.32.104:37242>
Subscription-State: active
Event: check-sync
Authorization: Digest username="4052", realm="xivo_proxies", nonce="ab8da357", uri="sip:4052@192.168.32.202:5060", response=b96172643782a966461e26a53e31dce8, algorithm=MD5, cnonce="cc7543", qop=auth, nc=00000001
Content-Length: 0
10:08:27.569083 IP (tos 0x68, ttl 64, id 20, offset 0, flags [none], proto UDP (17), length 328)
192.168.32.202.sip > demo-provd.lan-quebec.avencall.com.37242: SIP, length: 300
SIP/2.0 200 OK
To: <4052>;tag=2e422a1bf432247fi0
From: <192.168.32.104:37242>;tag=7cb9822
Call-ID: 531904491b682b6fc62682b7959a6cf6
CSeq: 1 NOTIFY
Via: SIP/2.0/UDP 192.168.32.104:37242;branch=z9hG4bKaf9405a385d3af75
Server: Cisco/SPA508G-7.4.8
Content-Length: 0
192.168.32.104:37242>4052>192.168.32.104:37242>192.168.32.104:37242>4052>192.168.32.104:37242>4052>192.168.32.104:37242>192.168.32.104:37242>4052>
Incorrect behaviour:
10:07:33.945918 IP (tos 0x0, ttl 64, id 30981, offset 0, flags [DF], proto UDP (17), length 408)
demo-provd.example.com.60429 > 192.168.32.202.sip: SIP, length: 380
NOTIFY sip:4052@192.168.32.202:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.32.104:60429;branch=z9hG4bKafac525b97c2a886
Max-Forwards: 70
To: <4052>
From: <192.168.32.104:60429>;tag=d90d4ec3
Call-ID: e5b2371a2b563fce86632afcb75b6a5c
CSeq: 1 NOTIFY
Contact: <192.168.32.104:60429>
Subscription-State: active
Event: check-sync
Content-Length: 0
10:07:33.958180 IP (tos 0x68, ttl 64, id 17, offset 0, flags [none], proto UDP (17), length 431)
192.168.32.202.sip > demo-provd.example.com.60429: SIP, length: 403
SIP/2.0 401 Unauthorized
To: <4052>;tag=2e422a1bf432247fi0
From: <192.168.32.104:60429>;tag=d90d4ec3
Call-ID: e5b2371a2b563fce86632afcb75b6a5c
CSeq: 1 NOTIFY
Via: SIP/2.0/UDP 192.168.32.104:60429;branch=z9hG4bKafac525b97c2a886
Server: Cisco/SPA508G-7.4.8
WWW-Authenticate: Digest realm="xivo_proxies", nonce="d9b7a4b3", qop="auth", algorithm=md5
Content-Length: 0
10:07:43.964682 IP (tos 0x0, ttl 64, id 30982, offset 0, flags [DF], proto UDP (17), length 621)
demo-provd.example.com.60429 > 192.168.32.202.sip: SIP, length: 593
NOTIFY sip:4052@192.168.32.202:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.32.104:60429;branch=z9hG4bK536412ce240eec77
Max-Forwards: 70
To: <4052>
From: <192.168.32.104:60429>;tag=d90d4ec3
Call-ID: e5b2371a2b563fce86632afcb75b6a5c
CSeq: 1 NOTIFY
Contact: <192.168.32.104:60429>
Subscription-State: active
Event: check-sync
Authorization: Digest username="4052", realm="xivo_proxies", nonce="d9b7a4b3", uri="sip:4052@192.168.32.202:5060", response=a5089bef6a9ac7194523c6a5973c8c79, algorithm=MD5, cnonce="19f988", qop=auth, nc=00000001
Content-Length: 0
10:07:43.977923 IP (tos 0x68, ttl 64, id 18, offset 0, flags [none], proto UDP (17), length 431)
192.168.32.202.sip > demo-provd.example.com.60429: SIP, length: 403
SIP/2.0 401 Unauthorized
To: <4052>;tag=2e422a1bf432247fi0
From: <192.168.32.104:60429>;tag=d90d4ec3
Call-ID: e5b2371a2b563fce86632afcb75b6a5c
CSeq: 1 NOTIFY
Via: SIP/2.0/UDP 192.168.32.104:60429;branch=z9hG4bK536412ce240eec77
Server: Cisco/SPA508G-7.4.8
WWW-Authenticate: Digest realm="xivo_proxies", nonce="d9b7a4b3", qop="auth", algorithm=md5
Content-Length: 0192.168.32.104:60429>4052>192.168.32.104:60429>192.168.32.104:60429>4052>192.168.32.104:60429>4052>192.168.32.104:60429>192.168.32.104:60429>4052>
The password associated with the '4052' SIP user is '4052'.
04-14-2011 05:59 AM
I had the same problem. After digging around, I found the solution in the config.
You have to disable "Auth Resync-Reboot" per line you wish to be able to receive the Check-Sync NOTIFY on.
Here is my config to allow the phone to receive Sync-Check on line 1, but NOT challenge/authenticate the NOTIFY message.
Here is the syslog showing the Challenge for the NOTIFY when the above is not set:
2011-04-14 08:49:32 Local2.Debug 192.168.108.1 [0]SipNotifyCmd 28
2011-04-14 08:49:32 Local2.Debug 192.168.108.1 [0]SipNotifyCmd 28
2011-04-14 08:49:32 Local2.Debug 192.168.108.1 SIP:Challenge NOTIFY
2011-04-14 08:49:32 Local2.Debug 192.168.108.1 SIP:Challenge NOTIFY
Message was edited by: DavidSarvai
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide