[asterisk-bugs] [Asterisk 0014133]: Subscription not removed when user becomes unsubscribed

[Asterisk Bug Tracker]

The following issue has been CLOSED 
====================================================================== 
https://issues.asterisk.org/view.php?id=14133 
====================================================================== 
Reported By:                Skavin
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   14133
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.21.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-12-23 15:14 CST
Last Modified:              2009-11-02 16:13 CST
====================================================================== 
Summary:                    Subscription not removed when user becomes
unsubscribed
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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014193 I get two MWI subscritions for a peer (...
====================================================================== 

---------------------------------------------------------------------- 
 (0113017) dvossel (administrator) - 2009-11-02 16:13
 https://issues.asterisk.org/view.php?id=14133#c113017 
---------------------------------------------------------------------- 
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 notified on that BOX1 for that
user.

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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-02 16:13 dvossel        Note Added: 0113017                          
2009-11-02 16:13 dvossel        Status                   feedback => closed  
======================================================================