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

ADTopkek (JIRA) noreply at issues.asterisk.org
Thu Aug 16 15:17:54 CDT 2018


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

ADTopkek edited comment on ASTERISK-27759 at 8/16/18 3:17 PM:
--------------------------------------------------------------

This is now a problem on all yealink firmware V82+. It seems to also affect some newer Grandstream models too. 

See: https://community.asterisk.org/t/blf-s-not-working-right-with-yealink-83-0-x-firmware-response-from-yealink/75708/7

Restarting the phones temporarily fixes the issue till the next server reboot. Causing major problems for some customers due to major reliance on BLF states. 


was (Author: adtopkek):
This is now a problem on all yealink firmware V82+. It seems to also affect some newer Grandstream models too.

See: https://community.asterisk.org/t/blf-s-not-working-right-with-yealink-83-0-x-firmware-response-from-yealink/75708/7

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



More information about the asterisk-bugs mailing list