Summary:ASTERISK-19882: Asterisk fails to unsubscribe from PubSub nodes when using ejabberd
Reporter:Matt Ryan (mattvryan)Labels:
Date Opened:2012-05-16 17:31:50Date Closed:2012-07-17 14:05:55
Versions: Frequency of
Environment:CentOS 5.4 x86_64Attachments:( 0) xmpp_unsubscribe.patch
Description:Asterisk patch: xmpp_unsubscribe.patch
 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'
 <event xmlns='http://jabber.org/protocol/pubsub#event'>
   <items node='device_state'>
     <retract id='SIP/01357cab9ced2ba87a006300620001' />
 <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>

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

CentOS 5.4 x86_64 - Xen Virtualized
XMPP:  ejabberd.x86_64 version 2.1.8-2.el5
Comments:By: Matt Ryan (mattvryan) 2012-05-16 17:32:52.804-0500

Patch to fix this issue.

By: Joshua C. Colp (jcolp) 2012-07-17 14:05:55.181-0500

Fixed in trunk as of revision 370157.