| Summary: | ASTERISK-24673: outgoing sip registers cannot be removed or modified without doing restart (or doing module unload chan_sip.so) | ||||||
| Reporter: | Stefan Engström (StefanEng86) | Labels: | |||||
| Date Opened: | 2015-01-08 08:52:01.000-0600 | Date Closed: | 2015-01-21 07:39:37.000-0600 | ||||
| Priority: | Major | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Registration | ||||
| Versions: | 13.0.0 13.1.0 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | fedora 20, x86_64 | Attachments: | ( 0) ASTERISK-24673-13.diff ( 1) console-register-problems.txt ( 2) console-register-problems-real-account.txt ( 3) debug-register-problems ( 4) debug-register-problems-real-account ( 5) procedure-register-problems.txt | ||||
| Description: | Let sip.conf contain a register line such as:
register => test97:foo@boo.se/266 asterisk -rx "sip show registry" now outputs a single registry entry: Host dnsmgr Username Refresh State Reg.Time boo.se:5060 N test97 105 Registered Thu, 08 Jan 2015 15:39:03 Comment out the above register-line (;register => test97:foo@boo.se/266) Issue asterisk -rx "sip reload" ==>the registration is still alive! that is, asterisk -rx "sip show registry" still has an entry. When I had asterisk version 12.6.0 installed, commenting out the line and issuing that 'sip reload' would destroy the sip registration as expected. ( asterisk -rx "sip show registry" would output 0 SIP registrations). However, it doesn't for version 13.0.0 or for version 13.1.0... Modifying an existing line 'register=>...' line in sip.conf (and not removing it) produces similar bad behaviour as well as this creates multiple active registrations (old+new). Having to restart the asterisk process (or unload+reload chan_sip.so) every time I want to change the callbackextension(266 above) for a sip-registry is not very fun. | ||||||
| Comments: | By: Stefan Engström (StefanEng86) 2015-01-09 07:53:03.082-0600 Possibly related to JIRA ASTERISK-24640 By: Matt Jordan (mjordan) 2015-01-12 10:24:24.853-0600 As Rusty noted on ASTERISK-24640, we were unable to reproduce this. Please provide both a DEBUG log (with 'sip set debug on' enabled) as well as your {{sip.conf}} that reproduces this. By: Torbjörn Abrahamsson (tobbe) 2015-01-13 01:38:40.917-0600 Here are the requested logs. By: Torbjörn Abrahamsson (tobbe) 2015-01-13 01:46:14.975-0600 FYI, I work together with Stefan Engström, and compiled the logs in his absence. We are surprised that you could not reproduce, as this have happened on every Asterisk 13 installation we tried. All installed in different ways, from source or RPMs. This is the most streamlined install though. Seems like a regression, as it works great in our 12.6.0 servers. In the logs we use 10.10.10.10 as domain for the register, which do not respond. But the result is the same if using a real, working, sip-account to register to. Thanks for your efforts. By: Torbjörn Abrahamsson (tobbe) 2015-01-13 03:53:43.723-0600 Here are some logs for the same scenario, but this time the Asterisk registers against a real working account. Procedure is the same, with the addition that I cleared iptables so it wouldn't interfere. This time I used this register line: register => testreg:Bt7QgsQcBTUV@192.168.1.227:8060/123 Changed it in the same way as in previous logs. By: Stefan Engström (StefanEng86) 2015-01-16 09:47:06.424-0600 It seems in 12.6.0 sip_registry_destroy was called in the sip_reload process: [2015-01-16 16:29:01] DEBUG[14757]: chan_sip.c:31547 reload_config: --------------- SIP reload started [2015-01-16 16:29:01] DEBUG[14757]: chan_sip.c:3425 registry_unref: SIP Registry wx3.se: refcount now 1 [2015-01-16 16:29:01] DEBUG[14757]: chan_sip.c:6431 sip_registry_destroy: Destroying registry entry for testreg@192.168.1.227:8060 [2015-01-16 16:29:01] DEBUG[14757]: chan_sip.c:31561 reload_config: --------------- Done destroying registry list But in 13.1.0 it's not. I tried to compile 13.1.0 with ref debug on, and it seems like something is not unreffed properly? feel free to take a look at: http://pastebin.com/VFJvhGZd By: Matt Jordan (mjordan) 2015-01-19 13:57:24.804-0600 A possible patch for this issue has been attached - ASTERISK-24673-13.diff. When testing it, I created a registration to a SIP trunk, verified that I was registered; commented out the registration, reloaded and the registration was gone. By: Stefan Engström (StefanEng86) 2015-01-19 14:24:59.400-0600 The attached patch ASTERISK-24673-13.diff seems to solve the leaking registration issue! By: Matt Jordan (mjordan) 2015-01-19 16:35:53.209-0600 Added review board link to a slightly cleaned up version of the patch. | ||||||