[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