Summary:	ASTERISK-25861: Subscription timeout earlier than anticipated - Asterisk accepts SUBSCRIBE with Event: presence and Accept: application/dialog-info+xml
Reporter:	patronic (user448929)	Labels:
Date Opened:	2016-03-23 06:33:43	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_sip/Subscriptions
Versions:	11.6.0 13.18.4	Frequency of Occurrence	Frequent
Related Issues:
Environment:		Attachments:	( 0) asterisk.txt ( 1) messages.txt ( 2) resip-part1.txt ( 3) resip-part2.txt ( 4) resiprocate-client.txt ( 5) resiprocate-client-part2.txt ( 6) test.pcap
Description:	I'm using a client built with the reSIProcate stack. After a random amount of time, my subscription to presence times out. In the asterisk log file, I can see a SUBSCRIBE comming in at 00:57:48 with a timeout of 60s. Asterisk says it is Scheduling destruction of SIP dialog in 70ms (so at 00:58:58) Then for an unknown reason, the client sends another one at 00:58:15. That seems pretty early. But it shouldn't matter. Then Asterisk sends a notify that terminates the subscription with reason=timeout. The dialog in question is wBSlQrD0PQD6CSJ_-ZipWg. The timeout occurs at 00:58:15. The last sucessful SUBSCRIBE was at 00:57:48. There are retransmits at the end of the log file because the client application killed itself as soon as it detected the subscription timeout (for testing purposes)
Comments:	By: Asterisk Team (asteriskteam) 2016-03-23 06:33:43.893-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2016-03-23 15:40:59.057-0500 We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2016-03-23 15:41:25.965-0500 Please provide a packet capture (wireshark viewable) along with the new debug log. Thanks! By: patronic (user448929) 2016-03-23 17:51:13.206-0500 Currently capturing. Will update when issue manifests again By: patronic (user448929) 2016-03-24 05:40:15.716-0500 Please see subscription slzzuQXxm9tzJQ2NrT0RVw being terminated at Mar 24 03:36:15 By: patronic (user448929) 2016-03-24 05:41:46.277-0500 Any way to make the attached files only viewable by me and your team? By: patronic (user448929) 2016-03-24 05:46:26.344-0500 Hmm, I just realised that it is the client that's sending a subscribe with expires=0. I guess we can close this. Sorry. By: Joshua C. Colp (jcolp) 2016-03-24 06:16:14.676-0500 Closed per reporter. By: patronic (user448929) 2016-03-24 09:28:13.254-0500 Actually.... I'm wondering if the NOTIFY could be in cause. The client sends a SUBSCRIBE with event: presence. Then it receives a 200 OK. Then it receives a NOTIFY: NOTIFY sip:testmeow@192.168.1.3:5555 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK1e471bc9;rport Max-Forwards: 70 From: <sip:voipms@192.168.1.3:5070>;tag=as46139e91 To: "testmeow"<sip:testmeow@192.168.1.3:5070>;tag=6309187b Contact: <sip:voipms@192.168.1.3:5070> Call-ID: wBSlQrD0PQD6CSJ_-ZipWg.. CSeq: 102 NOTIFY User-Agent: Asterisk PBX 11.6-cert10 Subscription-State: active Event: dialog Content-Type: application/dialog-info+xml Content-Length: 213 Shouldn't the Event be "presence" instead of "dialog" in this case? By: Asterisk Team (asteriskteam) 2016-03-24 09:28:13.361-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: patronic (user448929) 2016-03-27 09:42:36.787-0500 This would be in regards to rfc3265  section 3.2.1 By: Joshua C. Colp (jcolp) 2016-03-27 09:49:41.335-0500 The real bug is that chan_sip is accepting that. The event package should be "dialog" and not "presence". This is defined in RFC 4235. It seems to be more lenient on the event package name matching. By: patronic (user448929) 2016-03-27 10:05:26.246-0500 I'm confused then. As the example NOTIFY message in https://wiki.asterisk.org/wiki/display/AST/Presence+State does show a event package called "presence". By: Joshua C. Colp (jcolp) 2016-03-27 10:39:56.305-0500 That example is using the "application/pidf+xml" content type which is part of the "presence" event package.