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-0600Date Closed:2015-01-21 07:39:37.000-0600
Versions:13.0.0 13.1.0 Frequency of
is caused byASTERISK-24067 chan_sip: upgrade registry and mwi object to ao2
is related toASTERISK-24640 Registration pending stays forever after sip reload
Environment:fedora 20, x86_64Attachments:( 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 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@

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@
[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:


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.