[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=245013#comment-245013 ] 

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

That's really bad. Meaning asterisk is incompatible with modern SIP phones....

This is becoming a major problem as we are needing to update phones to newer firmwares for certain compatibility/bug fixes which then causes the BLF's to completely break every morning.

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