| Summary: | ASTERISK-13267: Subscription not removed when user becomes unsubscribed | ||
| Reporter: | Kevin Stewart (skavin) | Labels: | |
| Date Opened: | 2008-12-23 15:14:22.000-0600 | Date Closed: | 2011-06-07 14:08:13 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Subscriptions |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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. italksrv1*CLI> * 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 : 0.0.0.0 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 1.4.21.1. That is old code and some improvements have been made since then. If it is at all possible, please update to 1.4.26.2 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. | ||