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

[Bryan Nelson (JIRA)]

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

Bryan Nelson commented on ASTERISK-27759:
-----------------------------------------

@ADTopkek

As far as I can tell, this will impact any phone that properly follows the spec for dialog-info+xml subscriptions.  I've tested Polycom, Grandstream, Yealink, Cisco, and Obihai with the same results.  Any phone that continues to work fine is technically behaving badly, and has the potential to get out of order BLF notify messages and display the incorrect BLF state.

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