[asterisk-bugs] [JIRA] Closed: (ASTERISK-19882) Asterisk fails to unsubscribe from PubSub nodes when using ejabberd

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp closed ASTERISK-19882.
----------------------------------

    Resolution: Fixed

Fixed in trunk as of revision 370157.

> Asterisk fails to unsubscribe from PubSub nodes when using ejabberd
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-19882
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19882
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_jabber
>    Affects Versions: 1.8.9.3, 1.8.12.0
>         Environment: CentOS 5.4 x86_64
>            Reporter: Matt Ryan
>         Attachments: xmpp_unsubscribe.patch
>
>
> Asterisk patch: xmpp_unsubscribe.patch
> Author:
>   Matt Ryan
>   Jive Communications
>   mryan at getjive dot com
> Problem:  When Asterisk is configured to subscribe to the device_state and message_waiting PubSub nodes on an XMPP server (ejabberd in this case), it fails to unsubscribe from these nodes during shutdown.  On a subsequent restart, Asterisk re-subscribes to each PubSub node and is assigned a new subscription IDs.  Since the previous subscription IDs are still valid from the XMPP server's point of view, it includes all the valid subscription IDs when sending a "message" XMPP response to Asterisk.  This causes the message size to continue to grow larger and larger.
> Solution:  This patch addresses the problem by recognizing the additional subscription IDs when a message is received and by sending an unsubscribe request to the XMPP server for each subscription ID that is no longer valid.  This way, the subscription IDs get cleaned up even if Asterisk fails to shut down gracefully.
> How to reproduce:  Configure two Asterisk instances to subscribe to device_state and message_waiting PubSub messages.  Restart one of the Asterisk instances two or three times, then watch network traffic for that Asterisk instance using a traffic sniffing tool.  Generate some device_state traffic on the other Asterisk instance by generating a call on that Asterisk instance between two devices on the instance.  Among "message" responses from the XMPP server to the first Asterisk instance you will see one that looks something like this:
> <message from='pubsub.xmpp.mynetwork.com'
> to='asterisk1 at xmpp.mynetwork.com'>
>   <event xmlns='http://jabber.org/protocol/pubsub#event'>
>     <items node='device_state'>
>       <retract id='SIP/01357cab9ced2ba87a006300620001' />
>     </items>
>   </event>
>   <headers xmlns='http://jabber.org/protocol/shim'>
>     <header name='Collection'>device_state</header>
>     <header name='SubID'>53745EBA33564</header>
>     <header name='SubID'>53746F7A46C64</header>
>     <header name='SubID'>53759424E7E95</header>
>     <header name='SubID'>5375A36DB4EB5</header>
>     <header name='SubID'>5375AEE856B81</header>
>     <header name='SubID'>5375AFD84271C</header>
>   </headers>
> </message>
> Note the multiple "header" elements with different subscription IDs.
> After applying this patch, you can reproduce this same behavior and see the Asterisk instance generating unsubscribe requests to the PubSub node.  After these have been processed, call traffic will result in a "message" response like the one above, but the extra subscription IDs will no longer be present.
> We are using this patch against 1.8.9.3 but I'm providing the patch against trunk which also exhibits this behavior.
> Asterisk Version Info:
> URL: http://svn.digium.com/svn/asterisk/trunk
> Repository Root: http://svn.digium.com/svn/asterisk
> Repository UUID: f38db490-d61c-443f-a65b-d21fe96a405b
> Revision: 366739
> Node Kind: directory
> Schedule: normal
> Last Changed Author: rmudgett
> Last Changed Rev: 366700
> Last Changed Date: 2012-05-16 12:00:18 -0600 (Wed, 16 May 2012)
> Environment:
> CentOS 5.4 x86_64 - Xen Virtualized
> XMPP:  ejabberd.x86_64 version 2.1.8-2.el5

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira