[asterisk-bugs] [JIRA] (ASTERISK-25861) Subscription timeout earlier than anticipated

[Joshua Colp (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230037#comment-230037 ] 

Joshua Colp commented on ASTERISK-25861:
----------------------------------------

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.

> Subscription timeout earlier than anticipated
> ---------------------------------------------
>
>                 Key: ASTERISK-25861
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25861
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Subscriptions
>    Affects Versions: 11.6.0
>            Reporter: patronic
>            Assignee: Unassigned
>         Attachments: asterisk.txt, messages.txt, resip-part1.txt, resip-part2.txt, resiprocate-client-part2.txt, resiprocate-client.txt, test.pcap
>
>
> 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)



--
This message was sent by Atlassian JIRA
(v6.2#6252)