[Home]

Summary:ASTERISK-12253: Asterisk 1.4.21 breaks realtime sip on 'sip reload'
Reporter:nuitari (nuitari)Labels:
Date Opened:2008-06-23 20:59:47Date Closed:2009-05-27 10:48:19
Priority:MajorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_realtime
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20080804__bug12921.diff.txt
( 1) 20080815__bug12921.diff.txt
Description:Using Asterisk 1.4.21 realtime becomes useless after a sip reload is done.

The dynamic information is cleared, however it doesn't get reloaded from the database when the friend is doing some activity. The only way to make the friend show again is to force the phone to register again, usually though a reboot.

The module is res_mysql, from asterisk-addons 1.4.7, works as expected with Asterisk 1.4.20.
Comments:By: Mark Michelson (mmichelson) 2008-06-25 11:01:53

I just set up a realtime SIP peer and could not reproduce this behavior. I'll admit, my peer is pretty minimal. Here is the information stored for the peer:
<pre>
asterisk=# select * from sippeers;
id | name | context  | dtmfmode |  host   | secret | type | username | port |   ipaddr    | regseconds
----+------+----------+----------+---------+--------+------+----------+------+-------------+------------
 1 | 2000 | internal | rfc2833  | dynamic | 2000   | peer | 2000     | 5060 | 10.19.3.253 | 1214411262
(1 row)
</pre>
When I issue a "sip reload" command, the peer is still available. I also tried issuing the command while the peer was talking to another (non-realtime) peer, and the reload still caused no problems.

Note that I am not using res_config_mysql. I am using res_config_odbc with Postgresql as my database backend. I don't think this should matter though since you do not have the problem when using Asterisk 1.4.20.1.

I tried testing both with rtcachefriends set to yes and no. It made no difference in my tests. Perhaps there is some configuration option I need to set in order to be able to reproduce this.
By: nuitari (nuitari) 2008-06-26 00:06:07

I've did some more testing. I can place a call using the peer, even if it doesn't show up in "sip show peers", however I cannot receive any call as it doesn't load the existing info from the database.

rtcachefriends has no effect on the behaviour
rtupdate has no effect on the behaviour
ignoreregexpire has no effect on the behaviour.

From tracing MySQL the information is queried from the database, and the row is found.

080626  1:04:41      12 Init DB     asterisk
                    12 Query       SELECT * FROM sip_buddies WHERE name = '4000' AND host = 'dynamic'

And it stops here, the call is then sent to voicemail just after that happens.

On an 1.4.18.1 server it does the same query, and then there are a few more for specific channels (like for 4000-09791168).

I don't think res_config_mysql is in cause here as the same version works on a different version of Asterisk.


mysql> SELECT * FROM sip_buddies WHERE name = '4000' AND host = 'dynamic';
+-------------------------------------------------------------------------+
| id | ipaddr     | regseconds | name | callerid | canreinvite | context | dtmfmode | fromuser | fromdomain | host    | insecure | language | mailbox | nat | deny | port | qualify | secret | type   | username | disallow | allow                              | musiconhold | setvar | progressinband | subscribecontext | useragent | regexten | fullcontact         | t38pt_udptl |
+-------------------------------------------------------------------------+
|  8 | 10.0.2.197 | 1214459372 | 4000 | <4000> | no          | inside  | rfc2833  | NULL     | NULL       | dynamic | NULL     | NULL     | 4000    | no  | NULL | 5060 | yes     | <snip> | friend | 4000     | all      | g729;ilbc;gsm;g726;adpcm;ulaw;alaw | NULL        |        | no             | blf              |           |          | sip:4000@10.0.2.197 | no          |
+-------------------------------------------------------------------------+
Is placing calls to the peer after a sip reload working for you?


By: nuitari (nuitari) 2008-06-26 00:38:02

Another thing that I've found. Qualify still works after a "sip reload", however the peer doesn't show in "sip show peers"


*CLI> Reliably Transmitting (no NAT) to 10.0.2.197:5060:
OPTIONS sip:4000@10.0.2.197 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.11:5060;branch=z9hG4bK1c21f394;rport
From: "asterisk" <sip:asterisk@10.0.2.11>;tag=as62f6ae98
To: <sip:4000@10.0.2.197>
Contact: <sip:asterisk@10.0.2.11>
Call-ID: 60f7f44364e90baf02c365042376c2ef@10.0.2.11
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Thu, 26 Jun 2008 05:43:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


---

<--- SIP read from 10.0.2.197:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.2.11:5060;branch=z9hG4bK1c21f394;rport
From: "asterisk" <sip:asterisk@10.0.2.11>;tag=as62f6ae98
To: <sip:4000@10.0.2.197>;tag=1C9774B5-7B303CA8
CSeq: 102 OPTIONS
Call-ID: 60f7f44364e90baf02c365042376c2ef@10.0.2.11
Contact: <sip:4000@10.0.2.197>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_501-UA/3.0.0.0258
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '60f7f44364e90baf02c365042376c2ef@10.0.2.11' Method: OPTIONS
Reliably Transmitting (no NAT) to 10.0.2.197:5060:
OPTIONS sip:4000@10.0.2.197 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.11:5060;branch=z9hG4bK55eb7519;rport
From: "asterisk" <sip:asterisk@10.0.2.11>;tag=as33cf8f72
To: <sip:4000@10.0.2.197>
Contact: <sip:asterisk@10.0.2.11>
Call-ID: 770e37ee562cacfb46a9a2e550961a40@10.0.2.11
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Thu, 26 Jun 2008 05:43:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


---

<--- SIP read from 10.0.2.197:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.2.11:5060;branch=z9hG4bK55eb7519;rport
From: "asterisk" <sip:asterisk@10.0.2.11>;tag=as33cf8f72
To: <sip:4000@10.0.2.197>;tag=2641EB4C-7271F3C7
CSeq: 102 OPTIONS
Call-ID: 770e37ee562cacfb46a9a2e550961a40@10.0.2.11
Contact: <sip:4000@10.0.2.197>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_501-UA/3.0.0.0258
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '770e37ee562cacfb46a9a2e550961a40@10.0.2.11' Method: OPTIONS
By: nuitari (nuitari) 2008-07-09 08:02:28

This problem is still present in asterisk 1.4.21.1
By: Richard Brady (rnbrady) 2008-07-09 09:14:23

We have a system with about 1000 peers and we have this problem. We have stopped
doing sip reloads altogether. If changes are made to an account we use a sip prune
for that specific peer, instead of a whole reload. (Of course this doesn't help if
you make changes to your flat file).


By: nuitari (nuitari) 2008-07-09 09:17:51

It also happens when asterisk starts, so it's not only on sip reloads.

And only calls to a device, nor from a device

It also used to be that hints and calls from a device would cause asterisk to load the device from the realtime table, this doesn't happen anymore
By: nuitari (nuitari) 2008-07-12 08:46:51

I've started seeing these, however it's all on register.

[Jul 12 09:52:47] WARNING[5455]: res_config_mysql.c:360 update_mysql: MySQL RealTime: Failed to query database. Check debug for more info.

There is no debug info
By: Brett Bryant (bbryant) 2008-07-14 12:34:35

Nuitari, were there any debug messages right before or after the one that said it failed to query?
By: nuitari (nuitari) 2008-07-14 12:37:49

Just that someone registered, and this is with core set debug 99999
By: Brett Bryant (bbryant) 2008-07-14 17:59:34

Nuitari, I can't seem to replicate this issue reliably between two asterisk boxes. Could you please send me output of the server when the call to the friend fails with "sip set debug" and "core set debug 99999" all set?
By: nuitari (nuitari) 2008-07-15 07:10:58

*CLI> core show version
Asterisk 1.4.21.1 built by portage @ hammer on a x86_64 running Linux on 2008-07-10 08:52:28 UTC
*CLI> sip reload
*CLI> sip set debug peer 2000
Unable to get IP address of peer '2000'  <-- First sign of something wrong
*CLI> core set debug 99999
Core debug was 8 and is now 99999
*CLI> Really destroying SIP dialog '144b982e0bb7a39237384a4a27eecf74@10.1.8.1' Method: OPTIONS
Really destroying SIP dialog '71e6a26003c8dd916ca4851560a668f3@67.205.71.100' Method: OPTIONS
Really destroying SIP dialog '681a19556216225f1c9355a735f4b4ee@67.205.71.100' Method: OPTIONS
   -- Executing [didww@incoming-voip:1] Goto("SIP/didww-100761a0", "mainmenu|s|1") in new stack
--- SNIP DIALPLAN STUFF ---
   -- Executing [s@macro-stdexten:300] Dial("SIP/didww-100761a0", "SIP/2000|25|mw") in new stack
Really destroying SIP dialog '689592b32dca282b29d5fb90286bd467@67.205.71.100' Method: INVITE
[Jul 15 08:10:00] WARNING[8052]: app_dial.c:1183 dial_exec_full: Unable to create channel of type 'SIP' (cause 3 - No route to destination)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing [s@macro-stdexten:301] Goto("SIP/didww-100761a0", "s-CHANUNAVAIL|1") in new stack
   -- Goto (macro-stdexten,s-CHANUNAVAIL,1)

looking at MySQL's debug log, no query is made to try and load peer 2000.

The problem is clear, Asterisk isn't loading the peer from the database anymore, as it used to do before 1.4.21.

To replicate it, setup a server to register to the other via SIP.
Use realtime SIP to store the registration.
On the server that is being connected to, do a sip reload.
Try to place a call to the friend in realtime.
By: Brett Bryant (bbryant) 2008-07-15 10:48:59

Nuitari, I can't seem to replicate this with the 1.4 branch. Would you be able to test it there and see if it works for you? If not, I may need to ask for more information to try and figure this out.
By: Paul Hales (paulh) 2008-07-18 01:42:13

Just seen this on a system - upgraded to 1.4.21.1 last night, and now get 'status' UNKNOWN
for all realtime SIP peers after a reload. Rebooting the phone fixes the problem.
eg:
Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
6617/6617                  10.17.3.224      D          2048     UNKNOWN              
6537/6537                  10.17.3.223      D          2048     UNKNOWN              
6545/6545                  10.17.3.229      D          2048     UNKNOWN              
6452/6452                  10.17.2.251      D          2048     UNKNOWN              
6543/6543                  10.17.3.225      D          2048     UNKNOWN
By: nuitari (nuitari) 2008-07-19 18:47:24

I've traced it to something in chan_sip.so, I've changes the one in asterisk 1.4.21.1 with the one from 1.4.20.1 and it works
By: nuitari (nuitari) 2008-07-19 19:48:19

With the latest chan_sip.c 130959 I got this compile error:
chan_sip.c: In function 'hangup_cause2sip':
chan_sip.c:3460: error: duplicate case value
chan_sip.c:3451: error: previously used here
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2
make: *** Waiting for unfinished jobs....

I've commented out 3460 to continue.

Bug still present in r130959
By: nuitari (nuitari) 2008-07-19 19:54:49

After playing around with  chan_sip.c and undoing changes in this commit
http://svn.digium.com/view/asterisk/branches/1.4/channels/chan_sip.c?r1=117574&r2=118251

I have found the line that is bugging everything.
The change at line 2617 is causing the bug.
Reverting it back to
peer = build_peer(newpeername, var, NULL, !ast_test_flag(&global_flags[1], SIP_PAGE2_RTCACHEFRIENDS));
works.

I do not understand why the function build_peer uses the 4th argument as a boolean, so 1 should work.

But changing it back to that fixes the bug.
By: Danilo Lotina F. (dlotina) 2008-07-22 17:39:09

I have the same issue with 1.4.21.1. Changing the line 2617 resolves the issue.
Thanks Nuitari
By: Tilghman Lesher (tilghman) 2008-07-28 16:37:32

Please try the latest SVN 1.4.  Basically, rtcachefriends has been broken for a very long time, and while that change may have broken some stuff for you, it was actually the right fix (it simply didn't go far enough).  I made some changes in another bug late last week, which should make rtcachefriends work correctly for the first in a very long time.
By: Christoph Stadlmann (cstadlmann) 2008-08-04 08:26:56

Corydon, I admin that RT peers didn't work as expected for a long time and svn branch 133488 was a good starting point. Since svn branch 133488 the peer is displayed as 'Cached RT', which is good. But as the others mentioned before, peers aren't loaded into memory anymore after restart or 'sip reload'.

Going back to svn branch 133361, RT peers are loaded as expected, except that the status is 'UNKNOWN', even with qualify=yes and hints for all peers.

Maybe you can have a look at what you changed and how this is affecting other things.
By: Tilghman Lesher (tilghman) 2008-08-04 10:58:41

Try this patch, which differentiates between a realtime peer loaded into memory due to a register, versus a realtime peer loaded into memory because device state was requested.  The first caches, if rtcachefriends is turned on, while the second does not.  This is different from the current SVN in that a peer is allowed to be loaded without causing an infinite loop on expiration competing with devicestate.
By: Christoph Stadlmann (cstadlmann) 2008-08-05 01:20:08

Corydon, sorry to tell but this didn't solve the problem:

   -- Registered SIP 'test' at 192.168.4.109 port 2048 expires 3600
   -- Saved useragent "snom360/7.1.30" for peer test
[Aug  5 08:14:05] NOTICE[23293]: chan_sip.c:12698 handle_response_peerpoke: Peer 'test' is now Reachable. (53ms / 2000ms)

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
test/test                  192.168.4.109    D   N      2048     OK (53 ms) Cached RT
WNT                        xx.xxx.xxx.xxx              5060     OK (10 ms)
2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]
*CLI> sip reload
*CLI>  Reloading SIP
*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
WNT                        xx.xxx.xxx.xxx              5060     OK (11 ms)
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]


As you can see, peer registers and is visible. After a 'sip reload' the peer is gone.

Here is the debug log:

[Aug  5 08:18:18] VERBOSE[23293] logger.c:  Reloading SIP
[Aug  5 08:18:18] DEBUG[23293] res_config_mysql.c: MySQL RealTime: Static SQL: SELECT category, var_name, var_val, cat_metric FROM ast_config WHERE filename='sip.conf' and commented=0 ORDER BY filename, cat_metric desc, var_metric asc, category, var_name, var_val, id
[Aug  5 08:18:18] DEBUG[23293] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug  5 08:18:18] DEBUG[23293] res_config_mysql.c: MySQL RealTime: Found 63 rows.
[Aug  5 08:18:18] DEBUG[23293] chan_sip.c: --------------- SIP reload started
[Aug  5 08:18:18] DEBUG[23293] chan_sip.c: --------------- Done destroying user list
[Aug  5 08:18:18] DEBUG[23293] chan_sip.c: --------------- Done destroying registry list
[Aug  5 08:18:18] DEBUG[23293] chan_sip.c: Setting SIP channel User-Agent Name to smarTel
[Aug  5 08:18:18] DEBUG[23293] acl.c: 192.168.0.0/255.255.0.0/255.255.0.0 appended to acl for peer
[Aug  5 08:18:18] DEBUG[23293] acl.c: 10.0.0.0/255.0.0.0/255.0.0.0 appended to acl for peer
[Aug  5 08:18:18] DEBUG[23293] acl.c: 172.16.0.0/12/12 appended to acl for peer
[Aug  5 08:18:18] DEBUG[23293] acl.c: 169.254.0.0/255.255.0.0/255.255.0.0 appended to acl for peer
[Aug  5 08:18:18] DEBUG[23293] res_config_mysql.c: MySQL RealTime: Static SQL: SELECT category, var_name, var_val, cat_metric FROM ast_config WHERE filename='sip_notify.conf' and commented=0 ORDER BY filename, cat_metric desc, var_metric asc, category, var_name, var_val, id
[Aug  5 08:18:18] DEBUG[23293] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug  5 08:18:18] DEBUG[23293] res_config_mysql.c: MySQL RealTime: Found 0 rows.
[Aug  5 08:18:18] DEBUG[23293] chan_sip.c: --------------- Done destroying pruned peers
[Aug  5 08:18:18] DEBUG[23293] chan_sip.c: --------------- SIP reload done

As you an see, only the static entries are loaded, but no realtime peers.

BTW, in the internal database, the realtime peer is still there after a 'sip reload':

*CLI> database show
/SIP/Registry/test : 192.168.4.109:2048:3600:test:sip:test@192.168.4.109:2048
By: nuitari (nuitari) 2008-08-05 01:32:53

cstadlmann: this is the same behaviour as in previous versions.
Can you place a call to the peer itself?

Corydon76:
I've tried replacing the chan_sip.so of my 1.4.20.1 installation with the SVN one and I'm getting this message:

[Aug  5 02:38:54] WARNING[5457]: loader.c:363 load_dynamic_module: Error loading module 'chan_sip.so': /usr/lib/asterisk/modules/chan_sip.so: undefined symbol: ast_tcptls_server_root
[Aug  5 02:38:54] WARNING[5457]: loader.c:657 load_resource: Module 'chan_sip.so' could not be loaded.
By: Christoph Stadlmann (cstadlmann) 2008-08-05 01:46:38

Nuitari: This behavior is since svn branch 133488. I'm not using release version, so I can't tell since which version this behavior occurs.
I tried with latest svn branch version 135536.

And yes, I can call to this peer. Anyway, because I'm monitoring the peers if some peer died or lagged, the behavior itself is breaking my monitoring.
After calling to the peer:

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
test/test                  192.168.4.109    D   N      2048     UNKNOWN    Cached RT
WNT                        xx.xxx.xxx.xxx              5060     OK (10 ms)
2 sip peers [Monitored: 1 online, 1 offline Unmonitored: 0 online, 0 offline]

As you can see, the peer is visible again, but still without 'Status' as mentioned earlier.
By: Tilghman Lesher (tilghman) 2008-08-05 08:58:29

Nuitari:  that is expected behavior, and was the behavior even before this patch.  when you initiate a reload event, Asterisk knocks every realtime peer out of memory until it is needed once again.  The patch additionally permits device state requests to continue to work, even when the realtime peer is not in memory.

cstadlmann: are you running with the patch I uploaded yesterday?
By: Christoph Stadlmann (cstadlmann) 2008-08-05 09:07:46

Yes, I'm running the patch you provided and it it working. Peers get loaded again, but devicestate is still somehow broken because the peer's status is 'UNKNOWN'.
Although I admin that Hints are working again...

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
test/test                  192.168.4.109    D   N      2048     UNKNOWN    Cached RT
WNT1                       xx.xxx.254.130              5060     OK (9 ms)
WNT2                       xx.xxx.254.162              5060     OK (11 ms)
3 sip peers [Monitored: 2 online, 1 offline Unmonitored: 0 online, 0 offline]
*CLI> core show hints
*CLI>
   -= Registered Asterisk Dial Plan Hints =-
                  test@internal            : SIP/test              State:Idle            Watchers  0
----------------
- 1 hints registered
By: Tilghman Lesher (tilghman) 2008-08-05 09:28:26

Nuitari:  You're trying to replace a 1.4 version with a trunk version.  That will almost never work.  Instead, try using 1.4 from SVN (http://svn.digium.com/svn/asterisk/branches/1.4, not http://svn.digium.com/svn/asterisk/trunk).
By: nuitari (nuitari) 2008-08-06 01:45:04

Corydon76: I've tried the one from 1.4 SVN and it still has the issue.
By: Tilghman Lesher (tilghman) 2008-08-06 10:46:18

Nuitari:  which issue?  You've described several in the course of this bug, some of which should be fixed, and I think the last issue is simply a misunderstanding of the proper functioning of the Realtime cache.
By: nuitari (nuitari) 2008-08-07 10:52:14

Corydon76, the issue where a peer from the realtime database can no longer receive a call after anything that clears it from "sip show peers"
By: Bryan Cramer (bcramer) 2008-08-15 10:39:04

We're also experiencing this same bug where sip peers statuses change to UNKNOWN after a 'sip reload' or 'sip prune'.  I've tried the latest branch release (chan_sip.c 133572) with same results.  The sip options/qualify continue to work, however, the data doesn't seem to populate back to the the actual sip status.
By: Tilghman Lesher (tilghman) 2008-08-15 12:48:54

One more patch to try.  This should allow a realtime host to work after a 'sip reload'.
By: Tilghman Lesher (tilghman) 2008-08-15 12:51:39

By the way, both patches should be applied at the same time.  (in addition to, not instead of).
By: Bryan Cramer (bcramer) 2008-08-15 15:47:04

Corydon75, I've applied both patches successfully to the latest 1.4 branch of chan_sip.c and unfortunately have to report that it still looses the status information:

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

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

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
0 sip peers [Monitored: 0 online, 0 offline Unmonitored: 0 online, 0 offline]

If I pickup the phone and dial out I can complete the call:
-- Executing [6046381111@fromCLIENT:1] Dial("SIP/6046309553-09240cf0", "SIP/blah/6046381111") in new stack
   -- Called blah/6046381111
   -- SIP/blah-09248848 answered SIP/6046309553-09240cf0
   -- Packet2Packet bridging SIP/6046309553-09240cf0 and SIP/blah-09248848
 == Spawn extension (fromCLIENT, 6046381111, 1) exited non-zero on 'SIP/6046309553-09240cf0'

However, the clients status details or registration are still empty.

*CLI>sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime  
0 sip peers [Monitored: 0 online, 0 offline Unmonitored: 0 online, 0 offline]

Note, I'm using ODBC as the datasource, not mysql as others above.  My sip.conf is extremely small:

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

[authentication]
By: Tilghman Lesher (tilghman) 2008-08-15 16:14:45

bcramer:  I'm less concerned about the CLI display than the actual behavior.  Given that you're able to make calls, even though the phone has not re-registered after reload, I'm inclined to believe that the last bug reported in this issue has been fixed.
By: Bryan Cramer (bcramer) 2008-08-15 16:44:45

Corydon76, Outbound calls work, but not inbound as the client is not in a reachable state:


Inbound Call 1:
   -- Registered SIP '6046309553' at 24.207.127.0 port 5060 expires 3600
[Aug 15 07:47:01] NOTICE[30791]: chan_sip.c:12703 handle_response_peerpoke: Peer '6046309553' is now Reachable. (68ms / 2000ms)
   -- Executing Macro("SIP/blah-08a86990", "dialAcctInternal|SIP/6046309553|500|bcramer")
   -- Executing [s@macro-dialAcctInternal:1] GotoIf("SIP/blah-08a86990", "0?notinservice|s|1") in new stack
   -- Executing [s@macro-dialAcctInternal:2] Set("SIP/blah-08a86990", "CDR(accountcode)=bcramer") in new stack
   -- Executing [s@macro-dialAcctInternal:3] Dial("SIP/blah-08a86990", "SIP/6046309553|500|r") in new stack
   -- Called 6046309553
   -- SIP/6046309553-08a8bda8 is ringing
 == Spawn extension (macro-dialAcctInternal, s, 3) exited non-zero on 'SIP/blah-08a86990' in macro 'dialAcctInternal'
 == Spawn extension (macro-dialAcctInternal, s, 3) exited non-zero on 'SIP/blah-08a86990'
   -- Executing [h@macro-dialAcctInternal:1] Hangup("SIP/blah-08a86990", "") in new stack
 == Spawn extension (macro-dialAcctInternal, h, 1) exited non-zero on 'SIP/blah-08a86990'

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  
blah/blah  10.10.200.10     D   N      5060     OK (1 ms)            
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]


Inbound Call 2:
   -- Executing Macro("SIP/blah-b7a04b28", "dialAcctInternal|SIP/6046309553|500|bcramer")
   -- Executing [s@macro-dialAcctInternal:1] GotoIf("SIP/blah-b7a04b28", "0?notinservice|s|1") in new stack
   -- Executing [s@macro-dialAcctInternal:2] Set("SIP/blah-b7a04b28", "CDR(accountcode)=bcramer") in new stack
   -- Executing [s@macro-dialAcctInternal:3] Dial("SIP/blah-b7a04b28", "SIP/6046309553|500|r") in new stack
[Aug 15 07:48:06] WARNING[30878]: app_dial.c:1183 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing [s@macro-dialAcctInternal:4] Goto("SIP/blah-b7a04b28", "s-CHANUNAVAIL|1") in new stack
   -- Goto (macro-dialAcctInternal,s-CHANUNAVAIL,1)
 == Auto fallthrough, channel 'SIP/blah-b7a04b28' status is 'CHANUNAVAIL'

If I pick up the device SIP/6046309553 and call out from it, it works as advertised.  During the sip reload asterisk destroy's all the registrations then reloads the sip.conf with new information.  It should only do that for the static clients, the dynamic ones when the caching in enabled should be updated from the DB with the only exception being the last IP and latency info, which I believe is still being saved.
By: Tilghman Lesher (tilghman) 2008-08-15 17:17:03

Well, I have no idea what the problem is.  For me, this is working perfectly.  Here is what is in my sip.conf, for comparison:

[general]
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
videosupport=yes
limitonpeers=yes
rtcachefriends=yes
rtupdate=yes
rtautoclear=15
By: Tilghman Lesher (tilghman) 2008-08-15 17:18:44

rtupdate may be your problem.  The second patch explicitly needs rtupdate, as the fullcontact headers are what are needed for the host to stay persistent across reloads.
By: Digium Subversion (svnbot) 2008-08-15 17:25:01

Repository: asterisk
Revision: 138258

U   branches/1.4/channels/chan_sip.c
U   branches/1.4/configs/sip.conf.sample

------------------------------------------------------------------------
r138258 | tilghman | 2008-08-15 17:25:00 -0500 (Fri, 15 Aug 2008) | 8 lines

More fixes for realtime peers.
(closes issue ASTERISK-12253)
Reported by: Nuitari
Patches:
      20080804__bug12921.diff.txt uploaded by Corydon76 (license 14)
      20080815__bug12921.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=138258
By: nuitari (nuitari) 2008-08-15 21:55:52

Placing a call to the device now works, fixing the main issue.

However even after placing the call, the Status column of the "sip show peers" still list it as UNKNOWN. It used to have the ping time (if qualify was on) for the host which was quite useful.
By: nuitari (nuitari) 2008-08-15 22:04:06

Actually that seems to affect all peers in realtime
I've restarted one of my sipuras to check and it shows this:

*CLI>     -- Saved useragent "Linksys/PAP2T-5.1.6(LS)" for peer 4201
   -- Saved useragent "Linksys/PAP2T-5.1.6(LS)" for peer 4202
sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
4202/4202                  10.0.2.195       D          5061     UNKNOWN    Cached RT
4201/4201                  10.0.2.195       D          5060     UNKNOWN    Cached RT
By: Bryan Cramer (bcramer) 2008-08-29 09:54:51

More details on this bug can be found in:
http://bugs.digium.com/view.php?id=13316
By: Leif Madsen (lmadsen) 2008-08-29 10:45:28

Did both those patches go in? If so, should this issue be closed and continued in 13316?
By: Tilghman Lesher (tilghman) 2008-08-29 11:38:37

Yes, both of those patches were committed.
By: Leif Madsen (lmadsen) 2008-08-29 12:43:32

Changes in this bug were committed. Please see bug 13316 for any further debugging / issues related to this one.

Thanks!
Leif.