cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to the Cisco Small Business Community

Have a question? Click on a topic board below to get started in the community.

3777
Views
0
Helpful
4
Replies
blablablab
Beginner

SIP NOTIFY 'Event: check-sync' on Cisco SPA50x

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

4 REPLIES 4
Alberto Montilla
Cisco Employee

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

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://').

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


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: 0


The password associated with the '4052' SIP user is '4052'.

DavidSarvai
Beginner

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.

    
     Yes
     No

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