[asterisk-bugs] [JIRA] (ASTERISK-26696) pjsip_pubsub: PJSIP Subscription Persistence in AstDB Does not update on subscription refresh

Fri Jan 20 16:11:10 CST 2017

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

Zach R edited comment on ASTERISK-26696 at 1/20/17 4:09 PM:
------------------------------------------------------------

{quote}
Richard Mudgett

There are three things I am aware of concerning subscriptions that relate to updating Asterisk level data structures.

    The expiry value in the "pjsip show subscriptions" commands (ASTERISK-23828) currently count down to zero because the Asterisk level structures don't get updated with the new expiration time when the subscription is refreshed.
    ASTERISK-26696 is the same as 1 but concerns the AstDB record.
    Stopping Asterisk, rebooting phones, and then starting Asterisk will result in persisted subscriptions that haven't expired being recreated and not getting deleted when the old subscriptions expire because the phone created new subscriptions and no longer knows about the old ones. However, the old subscriptions are removed the next time asterisk restarts.

{quote}

In response to Richard's comment about subscriptions, I'm not sure if the following data will help in response to concern #3. Twice last week on the 11th to 12th and 13th to 14th I had experienced phones which made duplicate subscriptions that have not expired. Unlike the method you described to reproduce the bug, the server these cases occurred on did not reboot any time recently. The uptime for asterisk on the server currently shows over 2 weeks of uptime. I included the output of core show uptime below.
{noformat}
System uptime: 2 weeks, 1 day, 19 hours, 7 minutes, 46 seconds
Last reload: 1 week, 4 hours, 15 minutes, 2 seconds
{noformat}

I have attached the data I have on these cases to the ticket, with the first set as a set of files prefixed/starting with set1 and the second as set2. There are 3 files for each set:

* setx-hints.txt - Contains the diff of the hints for the day I noticed the trouble and the previous day
* setx-duplicates.txt  - Contains the duplicate subscriptions seen in the AstDB in the subscription_persistence family. These are grouped which extension they subscribe to.
* setx-subs.txt - Contains the subscriptions unsorted subscriptions in the subscription_persistence family of the AstDB for that day.

The first set happened on Jan 11th to Jan 12th 2017, and the second set happened on Jan 13th to Jan 14th 2017.

In set1 the phones rebooted at 4AM as we programmed them for synchronization of their configs, and as expected they sent a message to unsubscribe for the current subscription, and resubscribed when they came back up. Later that day it appears that they had been rebooted, as a new subscription was made at 10 AM on Jan 12th. This showed up as it had 2 subscriptions to each phone it was watching. The phone that had duplicate subscriptions to multiple hints was a Cisco SPA 50XG series phone.

In set 2 a phone that had been watching 4 extensions gained 2 more subscriptions to each of the phones it was watching. As with the first set the phone had rebooted at 4 AM to resync its configuration file with our provisioning server. Later that day it looks like it rebooted twice adding 2 additional subscriptions to the one it remade at 4 AM causing this phone to have 3 subscriptions to each of the 4 hints it was watching.

If needed I have dumps of the hints and subscriptions from the AstDB for each day starting from Jan 5th 2017.

was (Author: zrothy):
{quote}
{quote}

In response to Richard's comment about subscriptions, I'm not sure if the following data will help in response to concern #3. Twice last week on the 11th to 12th and 13th to 14th I had experienced phones which made duplicate subscriptions that have not expired. Unlike the method you described to reproduce the bug, the server these cases occurred on did not reboot any time recently. The uptime for asterisk on the server currently shows over 2 weeks of uptime. I included the output of core show uptime below.
{noformat}
System uptime: 2 weeks, 1 day, 19 hours, 7 minutes, 46 seconds
Last reload: 1 week, 4 hours, 15 minutes, 2 seconds
{noformat}