Summary:ASTERISK-13267: Subscription not removed when user becomes unsubscribed
Reporter:Kevin Stewart (skavin)Labels:
Date Opened:2008-12-23 15:14:22.000-0600Date Closed:2011-06-07 14:08:13
Versions:Frequency of
Description:when using realtime peers and subscribe if a user stops registering but has subscribed for MWI the peer will keep being re added as a peer even if pruned.
if the peer does not reply to the notify it will destroy the association.
if there are 2 servers both querying the same database and the user has moved from one asterisk server to the other their old server will keep setting the regserver, ipaddr port etc to "" making it very hard for other servers to find where this user is registered.

the only way I have found to remove the subscription is to restart asterisk.
Comments:By: Joshua C. Colp (jcolp) 2009-05-22 08:14:36

I spent the last while trying to reproduce this and understand exactly what is happening. A few comments:

1. Due to the way the MWI subscription works it wants to have a peer present in memory when active.
2. The regserver, ipaddr, port, etc will only get changed if we process a registration. I don't see how it could continually be reset back to nothing.

Is the problem really that Asterisk isn't treating the failure to respond to the NOTIFY as fatal and isn't tearing down the subscription? If not can you please try to better explain what the issue is? If there are multiple issues please try to keep them separate.

Additionally console output and SIP traces would also be useful.

By: Kevin Stewart (skavin) 2009-05-25 20:32:15

What I am seeing.
I have 2 servers both using the same database
All users are using real time
If a user registers and subscribes for MWI on one server
then moves to register on the second server.
regserver is updated by real time to the new server.
the old server keeps calling destroy_association
and recreating the sip peer
a "sip prune realtime peer" removes the peer until it is recreated by this process.


 * Name       : removed
 Realtime peer: No
 Secret       : <Not set>
 MD5Secret    : <Set>
 Context      : default
 Subscr.Cont. : <Not set>
 Language     : CP
 Accountcode  : removed
 AMA flags    : Unknown
 Transfer mode: open
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    : 1
 Pickupgroup  : 1
 Mailbox      : removed
 VM Extension : italkpbx
 LastMsgsSent : 32767/65535
 Call limit   : 3
 Dynamic      : Yes
 Callerid     : removed
 MaxCallBR    : 512 kbps
 Expire       : 83
 Insecure     : no
 Nat          : Route
 ACL          : No
 T38 pt UDPTL : Yes
 CanReinvite  : No
 PromiscRedir : No
 User=Phone   : No
 Video Support: No
 Trust RPID   : No
 Send RPID    : No
 Subscriptions: Yes
 Overlap dial : No
 DTMFmode     : auto
 LastMsg      : 0
 ToHost       :
 Addr->IP     : (Unspecified) Port 0
 Defaddr->IP  : Port 5060
 Def. Username:
 SIP Options  : (none)
 Codecs       : 0x50e (gsm|ulaw|alaw|g729|ilbc)
 Codec Order  : (g729:20,ilbc:30,gsm:20,alaw:20,ulaw:20)
 Auto-Framing:  Yes
 Status       : UNKNOWN
 Useragent    :
 Reg. Contact :

By: David Vossel (dvossel) 2009-10-12 17:57:08

I've looked into this issue for awhile and have not been able to determine what exactly is going on.  I don't understand why the peer on the first server keeps getting recreated and having destroy_association called.  Can you provide both sip debug and core debug on both boxes during this process?

By: David Vossel (dvossel) 2009-10-21 14:53:47

How do you have the database setup? Are you using two separate sipregs tables or do both boxes share the same registration information?  If they share the registration information that is a big problem.

By: Kevin Stewart (skavin) 2009-10-21 18:39:36

yes they share the same table allowing users to register to any server and to extensions logic to look at the reg server to know which server the user is registered on.

this is the only issue I have come across with them sharing all real time tables.

By: David Vossel (dvossel) 2009-10-23 11:52:39

Skavin, ah yes, you are correct. Using the same table but setting the regserver should not cause any issues with registrations being overridden.

Have you tried the 'subscribemwi' option to only send notifications when the user is subscribed?  If you have a defaultip set it may be possible for mwi subscriptions to be sent out to the user after the registration expires.

What version are you currently using to reproduce this issue?  It was reported against  That is old code and some improvements have been made since then.  If it is at all possible, please update to and verify that this issue still exists.

By: David Vossel (dvossel) 2009-11-02 16:13:49.000-0600

I've investigated this for quite a bit of time.  And I believe I understand the problem well.  You're using the same table for your sip users between multiple Asterisk boxes and are expecting regserver to differentiate what registration is for what box.  Using some extension logic makes it possible to determine what belongs to what box, but the chan_sip architecture does not differentiate this way.  If a user is pruned on BOX1 and that user re-registers with BOX2, that doesn't mean BOX1 doesn't have access to that user's registration information anymore.  If a request comes in to BOX1 for that user, it will be looked up in the database and possibly added back to the user list even though BOX2 is set as it's regserver.  If the user subscribed MWI to BOX2 and BOX1 later build's the user into it's internal list (for any reason), MWI is going to be sent from BOX1 to that user as well.

I don't know why your user is being rebuilt on BOX1 after the registration switches to BOX2.  You haven't provided enough information to determine that.  But that's really not all that important, because what is happening for your described setup is what I would expect.  The only way I see around your MWI problem is to use separate sip user tables or to identify why the user is being re-built on the box after you've pruned it.