|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:50||Date Closed:||2012-07-17 14:05:55|
|Versions:||188.8.131.52 184.108.40.206||Frequency of|
|Environment:||CentOS 5.4 x86_64||Attachments:||( 0) xmpp_unsubscribe.patch|
|Description:||Asterisk patch: xmpp_unsubscribe.patch|
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:
<retract id='SIP/01357cab9ced2ba87a006300620001' />
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 220.127.116.11 but I'm providing the patch against trunk which also exhibits this behavior.
Asterisk Version Info:
Repository Root: http://svn.digium.com/svn/asterisk
Repository UUID: f38db490-d61c-443f-a65b-d21fe96a405b
Node Kind: directory
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.