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 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_jabber |
Versions: | 1.8.9.3 1.8.12.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | CentOS 5.4 x86_64 | Attachments: | ( 0) xmpp_unsubscribe.patch |
Description: | 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@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 | ||
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. |