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

[ADTopkek (JIRA)]

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

ADTopkek commented on ASTERISK-27759:
-------------------------------------

We restart asterisk every day just to keep calls from slowly degrading in quality. So every morning with newer firmware phone's BLF buttons would not work.

What do you mean brings it back to the pre-pjsip days? This happens on both PJSIP and SIP. 

Resubscribing does not update the BLF version number. My phone is set to 5 min subscriptions and the problem persists for hours/days or until I manually reboot the phone. Same with clients.

> res_pjsip_pubsub: 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
>              Labels: pjsip
>
> 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)