[Home]

Summary:ASTERISK-12591: Realtime registrations don't work after a sip reload
Reporter:Bryan Cramer (bcramer)Labels:
Date Opened:2008-08-15 22:00:44Date Closed:2009-01-09 09:04:53.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Sip registrations get mixed up as the Nat'ed IP's get populated in the sip status, then the status becomes UNKNOWN.  Shortly after the sip registration completely disappears/expires:

sbc02*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
6046309553      24.207.127.215   D   N      5060     OK (10 ms) Cached RT
blah  10.10.200.10     D   N      5060     OK (1 ms)            
2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]

sbc02*CLI> sip reload
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found

sbc02*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
6046309553/6046309553      192.168.1.100    D   N      5060     UNKNOWN    Cached RT
blah  10.10.200.10     D   N      5060     OK (1 ms)            
2 sip peers [Monitored: 1 online, 1 offline Unmonitored: 0 online, 0 offline]

<couple minutes later>

sbc02*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
vr01mcitosbc02mci/vr01mci  10.10.200.10     D   N      5060     OK (1 ms)            
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]


Comments:By: Bryan Cramer (bcramer) 2008-08-15 22:03:09

I've used the latest build with Corydon76 fix for bug 12921 with no success.  
sip.conf:

[general]
context=default
allowguest=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=no
nat=yes
limitonpeers=yes
rtcachefriends=yes
rtupdate=yes
rtautoclear=15


By: Tilghman Lesher (tilghman) 2008-08-15 23:58:48

Let's see what your realtime table structure looks like.
By: Bryan Cramer (bcramer) 2008-08-17 23:22:06

CREATE TABLE IF NOT EXISTS `sip_clients` (
 `id` int(11) NOT NULL auto_increment,
 `name` varchar(80) NOT NULL default '',
 `accountcode` varchar(20) default NULL,
 `amaflags` varchar(13) default NULL,
 `callgroup` varchar(10) default NULL,
 `callerid` varchar(80) default NULL,
 `canreinvite` char(3) default 'yes',
 `context` varchar(80) default NULL,
 `defaultip` varchar(15) default NULL,
 `dtmfmode` varchar(7) default NULL,
 `fromuser` varchar(80) default NULL,
 `fromdomain` varchar(80) default NULL,
 `fullcontact` varchar(80) default NULL,
 `host` varchar(31) NOT NULL default '',
 `insecure` varchar(4) default NULL,
 `language` char(2) default NULL,
 `mailbox` varchar(50) default NULL,
 `md5secret` varchar(80) default NULL,
 `nat` varchar(5) NOT NULL default 'no',
 `deny` varchar(95) default NULL,
 `permit` varchar(95) default NULL,
 `mask` varchar(95) default NULL,
 `pickupgroup` varchar(10) default NULL,
 `port` varchar(5) default '',
 `qualify` char(3) default NULL,
 `restrictcid` char(1) default NULL,
 `rtptimeout` char(3) default NULL,
 `rtpholdtimeout` char(3) default NULL,
 `secret` varchar(80) default NULL,
 `type` varchar(6) NOT NULL default 'friend',
 `username` varchar(80) NOT NULL default '',
 `disallow` varchar(100) default 'all',
 `allow` varchar(100) default 'g729;speex;gsm;ulaw;alaw',
 `musiconhold` varchar(100) default NULL,
 `regserver` varchar(100) default NULL,
 `regseconds` int(11) default '0',
 `ipaddr` varchar(15) default '',
 `regexten` varchar(80) default '',
 `cancallforward` char(3) default 'yes',
 `setvar` varchar(100) default '',
 PRIMARY KEY  (`id`),
 UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC AUTO_INCREMENT=9 ;

INSERT INTO `sip_clients` (`id`, `name`, `accountcode`, `amaflags`, `callgroup`, `callerid`, `canreinvite`, `context`, `defaultip`, `dtmfmode`, `fromuser`, `fromdomain`, `fullcontact`, `host`, `insecure`, `language`, `mailbox`, `md5secret`, `nat`, `deny`, `permit`, `mask`, `pickupgroup`, `port`, `qualify`, `restrictcid`, `rtptimeout`, `rtpholdtimeout`, `secret`, `type`, `username`, `disallow`, `allow`, `musiconhold`, `regserver`, `regseconds`, `ipaddr`, `regexten`, `cancallforward`, `setvar`) VALUES(7, '6046309553', 'bcramer', '', '', 'Bryan', 'no', 'fromCLIENT', '', '', '', '', '', 'dynamic', 'yes', '', '', '', 'yes', '', '', '', '', '', 'yes', '', '', '', 'password', 'friend', '6046309553', 'all', 'ulaw', '', NULL, 300, '', '', '', '');
By: Bryan Cramer (bcramer) 2008-08-21 12:02:02

Corydon76, what is your realtime schema like and I'll test that out with my server.  This is the last part for me to roll out a bunch of servers.  Your help in solving this is greatly appreciated.  I noticed in one of the last patches that the NAT code was moved, could that cause this issue?
By: callguy (callguy) 2008-08-28 21:14:06

Corydon76: I think there's something more subtle going on here. While I agree that the patches you committed stop the functional issue (phones appear to be able to make/receive calls even when in "UKNOWN" state) there is still a display issue, but it isn't deterministic. What appears to have happened is that something has changed in the NAT code. If I do a reload and take a sample of 100 peers that were online before, about 37 of them were still showing as "OK (xx ms)" after re-registering.

However, if I go into the Cisco router that the majority of them are behind, and execute "clear ip nat translations *" that will clear the local NAT table and all of the phones will change to the "OK" status after re-registration.

This wasn't the behavior in past versions (we don't have any issue with 1.4.20), so something has changed in the interim that seems to be confusing the nat handling in asterisk (I can confirm that nothing has changed on the firewall).

I'm not really sure what the right tactic is to help debug this, please let me know what we can do to help.
By: nuitari (nuitari) 2008-08-29 10:55:54

I have a similar issue with 1 specific device on 1 server, through NAT.
The other customer on NAT is not having any issue.

I had to remove the qualify option so that calls can be received.
I'll try to get the model number of the firewall.

The phone is a Polycom 501.
By: Bryan Cramer (bcramer) 2008-09-03 11:08:51

My tests had been with a Polycom 601 which uses the same stack as the 501's.  Will test with another asterisk server and televantage to see if the same results occur.
By: BoneyM (boneymtom) 2008-09-09 20:13:28

We are running a production system on Asterisk BE Asterisk C.1.11 . We have the same issue as show below. Qualify =yes ,qualifyfreqok=60000 ,qualifyfreqnotok=10000. All phones are Cisco7940G . Yes it is working fine in Asterisk 1.4.14 .

Name/username              Host            Dyn Nat ACL Port     Status  Realtime
INN-2018/INN-2018          172.21.18.18     D          5060     UNKNOWN
INN-2017/INN-2017          172.21.18.17     D          5060     UNKNOWN
INV-3012/INV-3012          172.21.19.12     D          5060     UNKNOWN
QUA-3600/QUA-3600          172.31.68.100    D          5060     UNKNOWN
INV-3011/INV-3011          172.21.19.111    D          5060     UNKNOWN
INV-3015/INV-3015          172.21.19.15     D          5060     UNKNOWN
INV-3019/INV-3019          172.21.19.19     D          5060     UNKNOWN
INV-3016/INV-3016          172.21.19.16     D          5060     UNKNOWN
INN-2016/INN-2016          172.21.18.16     D          5060     UNKNOWN
JAY-2006/JAY-2006          172.21.26.6      D          5060     UNKNOWN
JAY-2004/JAY-2004          172.21.26.4      D          5060     UNKNOWN
QUA-3607/QUA-3607          172.31.68.7      D          5060     UNKNOWN
JAY-2005/JAY-2005          172.21.26.5      D          5060     UNKNOWN
JAY-2003/JAY-2003          172.21.26.3      D          5060     UNKNOWN
ACC-6005/ACC-6005          172.31.59.5      D          5060     UNKNOWN
By: Alan Graham (zerohalo) 2008-09-12 00:03:44

I get the similar behavior even for two peers on the same device (Polycom 550) after multiple re-registrations. rtcachefriends=yes and qualify=2000. PEER001 doesn't come back until reloading the router, but will still accept and originate calls normally (from what I've been able to test).

Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
PEER001                    xxx.xxx.xxx.xxx  D   N      5076     OK (108 ms)
PEER002                    xxx.xxx.xxx.xxx  D   N      5076     OK (108 ms)

sip reload

Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
PEER001                    xxx.xxx.xxx.xxx  D   N      5076     UNKNOWN
PEER002                    xxx.xxx.xxx.xxx  D   N      5076     OK (110 ms)

reboot router

Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
PEER001                    xxx.xxx.xxx.xxx  D   N      5076     OK (108 ms)
PEER002                    xxx.xxx.xxx.xxx  D   N      5076     OK (108 ms)


By: Tilghman Lesher (tilghman) 2008-11-13 15:06:44.000-0600

Several things have since changed in SVN.  Please try svn/branches/1.4 now.
By: Bryan Cramer (bcramer) 2008-11-13 15:23:22.000-0600

Will test shortly.
By: Tilghman Lesher (tilghman) 2008-12-11 11:12:08.000-0600

Given the lack of feedback, I am assuming that the changes made to SVN fixed this issue for you.  If this is not the case, please reopen.