[Home]

Summary:ASTERISK-07362: FreeBSD Asterisk-port crashes when transfering/forwarding to Local/ext
Reporter:Vahan Yerkanian (vahan)Labels:
Date Opened:2006-07-20 02:45:42Date Closed:2011-06-07 14:01:04
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) crashlog1.txt
( 1) crashlog2.txt
( 2) extensions.ael
( 3) gdb.txt
( 4) gdb2.txt
( 5) modules.conf
( 6) queues.conf
( 7) sip.conf
Description:I'm running Asterisk 1.2.9.1 installed from /usr/ports/net/asterisk on FreeBSD 6.1-RELEASE.

I'm experiencing a guaranteed asterisk core dump with any Sipura device set to forward all calls to an extension that is mapped to a queue or a moh, this is what happens on CLI:

   -- Executing Macro("SIP/10040-4c43", "call|10027") in new stack
   -- Executing Set("SIP/10040-4c43", "ext=10027") in new stack
   -- Executing Dial("SIP/10040-4c43", "SIP/10027|20|o") in new stack
   -- Called 10027
   -- Got SIP response 302 "Moved Temporarily" back from 10.20.30.40
   -- Now forwarding SIP/10040-4c43 to 'Local/111@Main' (thanks to SIP/10027-4f37)
sip*CLI>
Disconnected from Asterisk server
#

Here the 10027 is the Sipura-3000 in this case, with configured "Cfwd All Dest:" (forward all calls) to the extension 111, which is a queue or 109, which is a musiconhold call.

If I set the "Cfwd All Dest:" in the Sipura configuration interface to a phone extension (f.e. 10011) everything works ok.

Any clue what's causing this?

relevant configuration and gdb bt attached.
Comments:By: Vahan Yerkanian (vahan) 2006-07-20 02:55:39

Same happens with the extensions.conf version of dialplan. I've seen this problem since version 1.2.7 but was hesitant to report until our infodesk operators developed a habit of putting their Sipura-941s Cfwd all to the customer support queue extension (111) during their lunch break, thus crashing asterisk on the first incoming call to their extension.

I'm not sure also if the SIP transfers category is the proper place to report this, but I wasn't able to find a better place, so I apologize if this has to be moved elsewhere.
By: Serge Vecher (serge-v) 2006-07-20 08:08:40

Hmm, from the bt it is not exactly clear what's causing the crash ...

Just to see if this is actually chan_sip resposible, can you please do a SIP debug per the following instructions. Let's see what happens with chan_sip prior to the crash:

1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.
By: Serge Vecher (serge-v) 2006-07-20 08:09:08

also, please update Asterisk to revision 1.2.10
By: Vahan Yerkanian (vahan) 2006-07-20 10:11:23

Unfortunately I can't upgrade to 1.2.10 until /usr/ports/net/asterisk port gets updated, this is a production server and I don't want to upgrade using source / bsd patches manually so I don't break live system.

For the rest of your requests, I'm attaching two crash logs. Tried several times, asterisk crashes always, same gdb bt output that says nothing... Nor I see anything on console that shows the culprit.


By: Vahan Yerkanian (vahan) 2006-07-20 10:13:39

Just in case this is needed:

[sip] /# kldstat
Id Refs Address    Size     Name
1    5 0xc0400000 691928   kernel
2    1 0xc0a92000 58554    acpi.ko
3    2 0xc6913000 31000    zaptel.ko
4    1 0xc6948000 2000     ztdummy.ko

[sip] /# pkg_info | grep asterisk
asterisk-1.2.9.1_1  An Open Source PBX and telephony toolkit
asterisk-addons-1.2.3_1 Additional modules for the Asterisk Open Source PBX
[sip] /# pkg_info | grep zaptel
zaptel-1.0          A FreeBSD Driver for FXO, FXS, BRI and PRI Telephony Cards
[sip] /#


By: Vahan Yerkanian (vahan) 2006-07-20 11:29:38

If I set forward to go to another phone, f.e. another sipura registered to the asterisk, everything works:


   -- Executing Macro("SIP/10040-be47", "call|10027") in new stack
   -- Executing Set("SIP/10040-be47", "ext=10027") in new stack
   -- Executing Dial("SIP/10040-be47", "SIP/10027|20|o") in new stack
   -- Called 10027
   -- Got SIP response 302 "Moved Temporarily" back from 10.20.30.228
   -- Now forwarding SIP/10040-be47 to 'Local/10011@Main' (thanks to SIP/10027-91c8)
   -- Executing Macro("Local/10011@Main-9305,2", "call|10011") in new stack
   -- Executing Set("Local/10011@Main-9305,2", "ext=10011") in new stack
   -- Executing Dial("Local/10011@Main-9305,2", "SIP/10011|20|o") in new stack
   -- Called 10011
   -- SIP/10011-5cff is ringing
   -- Local/10011@Main-9305,1 is ringing


By: Serge Vecher (serge-v) 2006-07-20 11:57:02

I've noticed that you are using some "unofficial" applications, such as app_nv_backgrounddetect, app_nv_faxdetect.so, app_tx[rx]fax. I remember at least one bug, where removing app_nv_backgrounddetect has fixed a weird crash scenario. I don't know how much leeway you have with a production system, but in order to get help through this bug-tracker you will need to reproduce the problem without any external modules that are known to cause issues.
By: Vahan Yerkanian (vahan) 2006-07-28 05:04:55

vechers, were you able to reproduce this problem?
By: Serge Vecher (serge-v) 2006-07-28 08:37:16

yerkanian: I was not able to reproduce this with Cfwd'all on a Cisco phone, with Asterisk 1.2.9.1 on a Linux FC5 system. I think the next step in debugging this problem will be for you to recompile asterisk with 'make dont-optimize' and produce a new bt.
By: Vahan Yerkanian (vahan) 2006-08-02 14:11:09

I've just recompiled Asterisk 1.2.10 from the tarball manually, instead of installing from FreeBSD's port /usr/ports/net/asterisk, and the problem has disappeared.

The port includes several patches that seem to interfere with the normal operation for call transfers.

Sorry for the noise, you can close this ticket.
By: Serge Vecher (serge-v) 2006-08-02 14:23:31

it seems so. Glad the problem is fixed -- thanks for reporting back.