< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

[SFtrack] Created: (XECS-1944) Publisher 401 Unauthorized rejects SUBSCRIBE, then sends update NOTIFY


Publisher 401 Unauthorized rejects SUBSCRIBE, then sends update NOTIFY
----------------------------------------------------------------------

                 Key: XECS-1944
                 URL: http://track.sipfoundry.org/browse/XECS-1944
             Project: sipXecs
          Issue Type: Bug
          Components: sipXpublisher
         Environment: main stream FC8 development environment revision 14115
            Reporter: Paul Mossman
         Attachments: MWI_unauthorized_NOTIFY-filtered.pcap, PolycomFiles.zip, 
sipx-configuration-bcmdesk7199.ca.nortel.com.tar.gz

I have a Polycom 430 registered to user 201, and I noticed two MWI (refresh) 
SUBSCRIBEs failed un-expectedly.  Later there was an MWI NOTIFY with this 
failed Dialog ID.

See the attached MWI_unauthorized_NOTIFY-filtered.pcap.  
   - Frame 14: A message-summary SUBSCRIBE refresh (there are to and from 
tags), and there is a Proxy-Authorization: header
   - Frame 15: A 401 Unauthorized with a Www-Authenticate: header, but no 
Content-Length: header  (Why wouldn't the SUBSCRIBE have been accepted?)
   - Frame 16: Another message-summary SUBSCRIBE refresh with the same 
Proxy-Authorization: header as Frame 14, plus a Www-Authenticate: header with 
nonce corresponding to Frame 15.
   - Frame 17: Another 401 Unauthorized, similar to Frame 15, the notable 
exception being that there is a Content-Length: header  (Why wouldn't the 
SUBSCRIBE have been accepted?)
   - Note that there is no first NOTIFY, as would be seen if the SUBSCRIBE was 
successful.
   - At this point I left a message directly into user 201's mailbox (by 
dialing 8201)
   - Frame 19: A message-summary NOTIFY regarding the voicemail.  This is 
unexpected, since the subscription failed.  Note that this message has the same 
Dialog ID as Frames 14-17.
   - Frame 20: Indeed the phone considers the subscription dead, and therefore 
returns a 481 Call Leg/Transaction Does Not Exist.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://track.sipfoundry.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira