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

[Jens Beyer (JIRA)]

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

Jens Beyer commented on ASTERISK-27759:
---------------------------------------

I can confirm the BLF problem with Yealink phones and firmware 44.82.X. The workaround that Bryan Nelson has posted is working for me as well, but is only a partial solution because you still cannot just reload but must restart asterisk. So I tried this:

\[res_pjsip_pubsub\]
subscription_persistence/cache=memory_cache,object_lifetime_maximum=4000,object_lifetime_stale=2000
subscription_persistence=config,dummy.conf

with the idea to have a memory cache on top of an empty config file. The memory cache should be cleared on reload and then the phones must resubscribe. But this has the same effect as the idea from Bryan Nelson - after reload the BLF will not work. Maybe it is necessary to add the option "expire_on_reload" but I have not tested this yet.

> 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)