[asterisk-bugs] [JIRA] (ASTERISK-27759) Subscription persistence does not preserve XML <dialog-info> version number

[Bryan Nelson (JIRA)]

Bryan Nelson created ASTERISK-27759:
---------------------------------------

             Summary: Subscription persistence does not preserve XML <dialog-info> version number
                 Key: ASTERISK-27759
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27759
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Resources/res_pjsip_pubsub
    Affects Versions: 15.3.0
         Environment: CentOS Linux release 7.4.1708 (Core)
            Reporter: Bryan Nelson
            Severity: Minor


When utilizing the subscription persistence via astDB to restore dialog-info+xml subscriptions on restart of asterisk, the re-built subscriptions do not have the correct 'version' number in the xml content, and the message is discarded by phones per the RFC.  I am unable to find anywhere that the current xml version number is stored in the persistence table, so it makes sense that it cannot be restored on restart. 

Desired behavior would be similar to how the SIP Cseq is stored, and used when restoring the subscription.

Example:

Prior to restart, version number has reached 6
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" *version="6"* state="full" entity="sip:701 at 1.1.1.1:5060">
 <dialog id="701">
  <state>terminated</state>
 </dialog>
</dialog-info>
{quote}

After restart, subscription is restored, but version number starts at 1:
{quote}
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" *version="1"* state="full" entity="sip:701 at 1.1.1.1:5060">
 <dialog id="701">
  <state>confirmed</state>
 </dialog>
</dialog-info>
{quote}

In this particular case, the version number would 'catch up' to the phones with 5 more state changes, and the BLF would resume functioning on the phone.  In cases where there is a very long running subscription with many state changes, this version number can be in the hundreds, so the delay before if begins functioning again is quite long.



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