|Summary:||ASTERISK-08743: Asterisk crashes without notice when sending a 10 digit CID to a VoIP provider (Cisco GW)|
|Date Opened:||2007-02-06 21:40:37.000-0600||Date Closed:||2007-02-26 10:45:17.000-0600|
|Environment:||Attachments:||( 0) output.txt|
( 1) output2.txt
( 2) output3.txt
( 3) stacktop.txt
|Description:||I have the following branch version of Asterisk running in a test environment: SVN-branch-1.4-r53246. This has been happening in general over all the versions of branch. |
I have a VoIP SIP provider that expects a 10 digit Called-ID to be sent with the call to correctly identify calls but when Asterisk is either configuered by users.conf with "fromuser" or when the extension is programmed with the caller-ID that the provider expects, As soon as an outgoing call is made using the VoIP provider and the callee answers asterisk just terminated without any kind of error message or log.
If the Extensions Caller ID is left open and it send the 4 digit extension number instead of the caller ID needed the call goes through properly.
Another issue in the same context is that the "CallerID" field in the users.conf in not taken into account when making an outgoing call to a VoIP provider, instead it always sends the extensions caller ID or extension number.
|Comments:||By: Russell Bryant (russell) 2007-02-07 10:37:41.000-0600|
Well, this does sound like a crash. However, there isn't anything we can do without a backtrace.
First, build Asterisk without optimizations by running "make menuselect", and selecting DONT_OPTIMIZE from the Compiler Flags section.
Then, make sure you start Asterisk with the -g option. Then, you should be able to get a backtrace using the information in doc/backtrace.txt.
By: warlock52 (warlock52) 2007-02-07 15:50:03.000-0600
OK I have attached output.txt as requested...the only thing I changed from the working solution was adding the 10 digit caller ID to the user that made the call and the result is a silent Asterisk crash as mentioned.
By: warlock52 (warlock52) 2007-02-07 16:05:37.000-0600
Sorry in the first file I seemed to have gotten hold of a different core file...Output2.txt should contain what youre looking for...
By: warlock52 (warlock52) 2007-02-10 01:12:43.000-0600
I have updated to SVN-branch-1.4-r53821 and the crash is now not when the call is initiated but instead when the called party answers. The console still registers the bridging of the call and then Asterisk crashes. Before it was as soon as the dialled digits were sent to de GW, asterisk died so there is a slight change but it still crashes.
By: Paul Cadach (pcadach) 2007-02-10 03:58:57.000-0600
warlock52, your backtraces shows just killed stack and isn't useful. Be sure you compiled Asterisk with DONT_OPTIMIZE flag enabled.
By: warlock52 (warlock52) 2007-02-10 13:13:26.000-0600
that`s what happens it just dies..."DONT OPTIMIZE" is enabled menuselect and I have recompiled Asterisk. I`ll do another trace now and send the output of that...
By: warlock52 (warlock52) 2007-02-10 13:30:49.000-0600
I`ve attached the output with DONT OPTIMZE and SVN-branch-1.4-r53821 which has the same effect as soon as a call is sent out to the VoIP provider with a 10 digit ANI (Caller ID) Asterisk goes for a ball of chalk. At the moment we are not in production but my provider is all over me to send him my 10 digit Caller ID so that we can put this into production.
By: Paul Cadach (pcadach) 2007-02-10 14:36:16.000-0600
warlock52, could you please describe exact call path which takes you into this problem? You shown additional stack overwrite...
Did you perform "make clean" after you set DONT_OPTIMIZE option?
Which codec_g723a.so do you use (looks like it's not fit to your environment)?
I've attached 4-102 stack frames converted to text (stacktop.txt) - probably it could be helpful for SIP gurus.
By: warlock52 (warlock52) 2007-02-10 15:43:36.000-0600
The G729 was one that Digium Support had me download to be able to use the 2 licences that I have implemented. What confirms that there is no problem with the Codec is that when I send a 4 digit Caller ID everything goes perfectly with that exact same codec!
Yes I did do:
make install and restarted Asterisk
The only change I have to make to have this problem is to add the 10 digit Calle-ID in the User config for the user that I want to have the Caller ID or add Caller-ID manually to users for the SIP trunk definition and inmediately after adding this Asterisk fails with any outgoing call from the extension to the VoIP provider which I insist with the 4 digit caller ID does not happen.
I cannot leave the 4 digit caller ID because the billing system for the Gateway that we are using requires a 10 digit Caller-ID.
The process is:
Ext 1588 makes an outgoing call using the SIP trunk defined in Users and only fails when the 10 digit Caller ID is used and "crashes inmeditaely after having sent the Call Setup to the external GW. If you are in the Asterisk Console all you see is "Disconnected form Asterisk".
-- Executing [91856214@numberplan-custom-1:1] Macro("SIP/1588-08b3e290", "trunkdial|SIP/trunk_1/019981856214") in new stack
-- Executing [s@macro-trunkdial:1] Dial("SIP/1588-08b3e290", "SIP/trunk_1/019981856214") in new stack
-- Called trunk_1/019981856214
-- Call on SIP/trunk_1-08ae8c80 left from hold
-- SIP/trunk_1-08ae8c80 is making progress passing it to SIP/1588-08b3e290
Disconnected from Asterisk server
This obviously provokes one way audio because the call path through Asterisk is lost and because Asterisk looses the initial contact with the call and the endpoints try to keep the call going but only with audio in one direction.
When I take out the 10 digit Caller ID from the user...the call goes through without a problem but sends only 4 digits as Caller ID. The following is a normal call process with a 4 digit Caller-ID.
-- Executing [91856214@numberplan-custom-1:1] Macro("SIP/1588-08b712f8", "trunkdial|SIP/trunk_1/019981856214") in new stack
-- Executing [s@macro-trunkdial:1] Dial("SIP/1588-08b712f8", "SIP/trunk_1/019981856214") in new stack
-- Called trunk_1/019981856214
-- Call on SIP/trunk_1-b734dff0 left from hold
-- SIP/trunk_1-b734dff0 is making progress passing it to SIP/1588-08b712f8
-- Call on SIP/trunk_1-b734dff0 left from hold
-- SIP/trunk_1-b734dff0 answered SIP/1588-08b712f8
-- Native bridging SIP/1588-08b712f8 and SIP/trunk_1-b734dff0
== Spawn extension (macro-trunkdial, s, 1) exited non-zero on 'SIP/1588-08b712f8' in macro 'trunkdial'
== Spawn extension (macro-trunkdial, s, 1) exited non-zero on 'SIP/1588-08b712f8'
...and Asterisk continues running.
By: warlock52 (warlock52) 2007-02-17 23:16:23.000-0600
Do you need any more info???...I am getting pretty desperate here...
By: Olle Johansson (oej) 2007-02-18 05:52:53.000-0600
You need to describe your system and installation a bit more.
By: warlock52 (warlock52) 2007-02-19 21:21:48.000-0600
The box is a HP 2core 2.8GHz machine with 512 of RAM and R-Path linux and Asterisk 1.4 and in the meantime were testing up to branch -r55483 with exactly the same results. The SIP provider has a Cisco GW that only expects SIP calls with a 10 digit ANI. I would like to get behind this ASAP.
By: Paul Cadach (pcadach) 2007-02-19 21:40:38.000-0600
Could you provide "sip debug" output and sip.conf for analysis?
By: Serge Vecher (serge-v) 2007-02-20 09:17:31.000-0600
1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
console => notice,warning,error,debug
3) restart Asterisk with the following command:
'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt'
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
5) Reproduce the problem
6) Trim startup information and attach verbosedebug.txt to the issue.
By: warlock52 (warlock52) 2007-02-25 22:22:36.000-0600
I have just updated Zaptel and Asterisk to the latest SVN and it seems to have taken care of the problem...I can now send a 10 digit ANI without the box crashing every time...
External at revision 19.
At revision 116.
By: Joshua C. Colp (jcolp) 2007-02-26 10:45:16.000-0600
Okay since this appears to be fixed as of latest SVN closing this out... if this is not the case please feel free to reopen.