[Home]

Summary:ASTERISK-23542: Dynamic realtime SIP peers using callbackextension will not register after a 'sip reload' where sip.conf has changed
Reporter:Jay Jideliov (jideliov)Labels:
Date Opened:2014-03-26 16:07:45Date Closed:
Priority:CriticalRegression?
Status:Open/NewComponents:Resources/res_config_odbc Resources/res_odbc Resources/res_realtime
Versions:SVN 11.4.0 11.8.1 13.18.4 Frequency of
Occurrence
Related
Issues:
is the original version of this clone:ASTERISK-22026 Peers in realtime not register after "sip reload" using callbackextension
Environment:Debian Wheezy 64 bitsAttachments:( 0) asterisk-23542-regobj-counter_11_v1.diff
( 1) full.txt
Description:Originally reported here: ASTERISK-22026
But closed due to inactivity.
I am now experiencing the same issue, and have attached a full log to this ticket.

______________________________________________________________________




When i use peers in realtime with option callbackextension after "sip reload" the peer change to "unregister" and stay.

If i restart asterisk or unload/load chan_sip works again
{noformat}
debian*CLI> sip show registry
Host                                    dnsmgr Username       Refresh State                Reg.Time                
xxxxxxxxxxxx:5060                        Y      xxxx              160 Registered           Sat, 06 Jul 2013 10:31:41
1 SIP registration.
debian*CLI> sip reload
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found
debian*CLI> sip show registry
Host                                    dnsmgr Username       Refresh State                Reg.Time                
xxxxxxxxxxxx:5060                        N      xxxxx              120 Unregistered                                  
{noformat}                  
Thanks
Comments:By: Jay Jideliov (jideliov) 2014-03-26 16:12:08.837-0500

Realtime peer info:

    id  2
                 element_type  1
                  customer_id  1107
                     username  User1107140228200749
                         name  User1107140228200749
                         port  5060
                  defaultuser  User1107140228200749
                         host  sip.provider.com
                         type  friend
                      context  from-external
                       secret  LGD43fDsa
                  canreinvite  no
                     dtmfmode  rfc2833
                  directmedia  no
                          nat  auto_force_rport,auto_comedia
                     disallow  all
                        allow  ulaw
                        allow  alaw
                     insecure  invite,port
                 videosupport  no
                   fromdomain  sip.provider.com
                     fromuser  User1107140228200749
                      qualify  600
                     sendrpid  yes
            callbackextension  User1107140228200749
                         avpf  no
                   encryption  no
                   icesupport  no
By: Jay Jideliov (jideliov) 2014-03-26 16:20:47.869-0500

This is also independent of rtcachfriends (same behavior for yes/no)
By: Rusty Newton (rnewton) 2014-04-10 16:02:05.904-0500

The key to reproduction was this
{quote}
debian*CLI> sip reload
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found
{quote}

Whoever wants to reproduce, must make sure that sip.conf has changed so that the config file will be re-parsed. In that case, the registration always becomes unregistered and does not try to re-register until chan_sip is completely unloaded and loaded back. (or Asterisk is restarted of course)
By: Matt Jordan (mjordan) 2014-04-10 18:11:35.255-0500

Jay: I'm pretty sure I've asked you before not to clone issues. Please do *not* clone them again. It makes tracking issues harder. If this issue is fixed, people who reported the original issue are now unlikely to get notifications about the issue being resolved. This creates a suboptimal experience for everyone in the Asterisk project.

If you find you can reproduce an issue, please ask a bug marshal to reopen the issue. You can ask in #asterisk-bugs, #asterisk-dev, or on the asterisk-dev mailing list.
By: Michael L. Young (elguero) 2014-08-06 16:47:24.569-0500

I just attempted to reproduce this on the latest 11 branch and also with trunk.  I was unable to reproduce and I did make sure to change sip.conf in order for it to be re-parsed.

Any clues as to what else can be done to re-produce this issue?
By: Walter Doekes (wdoekes) 2014-08-07 02:55:53.013-0500

@michael: Just to be clear, you did use *dynamic realtime* peers from a db?
By: Michael L. Young (elguero) 2014-08-07 11:32:09.245-0500

@walter: Yes, I did.  I setup a peer/friend following the example provided in the comment by Jay using dynamic realtime.
By: Michael L. Young (elguero) 2014-08-07 12:56:14.725-0500

Okay, I now am able to reproduce it.  The only way I was able to reproduce it was to change the sip.conf, run "sip reload" then change the sip.conf file again and then run "sip reload" again.  It seems that the second time around causes this to happen.  If you have one peer coming from dynamic realtime with callbackextension set, then it also stops the other non-realtime peers from registering as well and not just this one dynamic realtime peer.
By: Michael L. Young (elguero) 2014-08-07 22:32:02.224-0500

What I have found:

The registry object counter is being decremented incorrectly.  In a case where you have 3 peers (like I did when initially trying to reproduce this problem, one is dynamic realtime with callbackextension and the other 2 are static register=> lines), the counter initially goes to 3 but then becomes 2 after the realtime peer is loaded into memory from the db.  At a reload, the counter is decremented as the registries are destroyed resulting in the counter becoming -1.  Then the config is loaded up, the counter is at 2 and then goes down to 1.  At the next reload, the registries are destroyed and the counter becomes -2.  Upon loading the register entries, it becomes 1 and then goes to 0.  With the next reload, the counter ends up being -3 when destroying the registries, goes up to 0 and therefore when the function to send sip registers is called, it sees the counter is at 0 and returns without registering any peer.

It would appear that when dynamic realtime is involved, the peer is built.  During the build, it sees there is a callback extension and adds a registry entry when sip_register is called.  When register_realtime_peers_with_callbackextens() is called, the peer is built, loaded into memory and sip_register is called again for the same peer because it has callbackextension set.  sip_register() finds a registry object entry already, and proceeds to throw away the reference.  The registry object counter is never incremented.  The "reg" object that was setup by calling ASTOBJ_INIT is un-referenced by calling registry_unref().  Inside of that function, the registry object counter is decremented, resulting in the problem with the counter.

The patch that I am going to attach fixes the issue.  It is simple and takes care of the counter.  It seems that it is safe to increment the counter since the call to registry_unref() will take care of decrementing the counter for the reg object that was initialized and then subsequently thrown away.  But, I don't like to increment the counter when the registry entry is never linked into the list.  It doesn't seem the right thing to do.  I was attempting to focus on fixing the double call to sip_register for the same dynamic realtime peer with callbackextension but was hitting a mental block right now.  Feedback is welcomed.
By: nixon nixon (nixon) 2014-08-14 13:33:47.606-0500

I was testing for several days. This is beautiful patch. Thnxs!