I’ve used the Asterisk forum search bar to find information on the issue described below and found a lot of helpful information; however, I could use further guidance on debugging this on a production server. I don’t believe that recompiling Asterisk with additional debugging options is a possibility currently.
From an end-user perspective: An employee logs into a queue to field incoming calls. He gets a call from a customer, attempts to warm transfer him to the appropriate department, but when bringing the customer back on the line with the appropriate department, the customer is no longer there. The employee logs out of the queue then tries to log back in, but it says that they are already logged in.
We typically resolve this from the Asterisk CLI with: channel request hangup [SIP channel]
However we occasionally can’t hangup the channel and get the following output from the CLI:
Asterisk Version and a `sip show channel’:
[code]voip2*CLI> core show version
Asterisk 1.8.19.0 built by root @ voip.server on a x86_64 running Linux on 2012-12-29 22:21:25 UTC
voip2*CLI> sip show channel 300c1113-952ec9fc-7451b8cd@X.X.X.X
SIP Call
Curr. trans. direction: Incoming
Call-ID: 300c1113-952ec9fc-7451b8cd@X.X.X.X
Owner channel ID: SIP/6512-000015e6
Our Codec Capability: 0x80000008000e (gsm|ulaw|alaw|h263|testlaw)
Non-Codec Capability (DTMF): 1
Their Codec Capability: 0x110c (ulaw|alaw|g729|g722)
Joint Codec Capability: 0xc (ulaw|alaw)
Format: 0x4 (ulaw)
T.38 support No
Video support No
MaxCallBR: 384 kbps
Theoretical Address: X.X.X.X:5060
Received Address: X.X.X.X:5060
SIP Transfer mode: open
Force rport: Yes
Audio IP: X.X.X.X (local)
Our Tag: as7e411a4d
Their Tag: C07A45C6-85378327
SIP User agent: PolycomSoundPointIP-SPIP_550-UA/3.0.4.0061
Username: 6512
Peername: 6512
Original uri: sip:6512@X.X.X.X
Caller-ID: 6512
Need Destroy: No
Last Message: Rx: BYE
Promiscuous Redir: No
Route: sip:6512@X.X.X.X
DTMF Mode: rfc2833
SIP Options: 100rel replaces replace
Session-Timer: Inactive[/code]
We are not using any h extensions in our dial plan. DEBUG_THREADS is not compiled. I’m not very familiar with gdb or bt. Any help on either 1) pinning down this problem, or 2) getting the needed debug level traces for bugtracker, would be greatly appreciated.
This is generally a secondary fault. You are either going to have to get deep into the code, or find an earlier, more specific, fault if you are going to diagnose this.
Given that you say that callers go away unexpectedly, I think it is most likely that this is a failure to cancel the auto-destruction, rather than a case of being late in closing the channel. If you turn up the debugging level, you should get to a point where Asterisk reports when it is starting and stopping autodestruct timers, from which you may be able to work out what started the timer that didn’t get cancelled.
Transfers involve masquerade operations, which are a very tricky part of the code. I suspect a transfer is happening at the same time as something else.
am also having similar issue, the situation has gone worse this week. have already had two outage , one today and other on yesterday.
this system we are having issues with is CentOs (64bit), running asterisk 1.8.20.0 and was build using yum
re yesterday’s outage, have gone through logs and can see following message when it all started happening
th queuing to Local/106@from-inside-XYZ-00000404;1
[2013-04-04 12:03:26] WARNING[6469] channel.c: Exceptionally long voice queue length queuing to Local/106@from-inside-XYZ-00000404;1
[2013-04-04 12:03:27] WARNING[6469] channel.c: Exceptionally long voice queue length queuing to Local/106@from-inside-XYZ-00000404;1
[2013-04-04 12:03:29] WARNING[6469] channel.c: Exceptionally long voice queue length queuing to Local/106@from-inside-XYZ-00000404;1
[2013-04-04 12:03:30] WARNING[6469] channel.c: Exceptionally long voice queue length queuing to Local/106@from-inside-XYZ-00000404;1
[2013-04-04 12:03:31] WARNING[6469] channel.c: Exceptionally long voice queue length queuing to Local/106@from-inside-XYZ-00000404;1
[2013-04-04 12:03:32] WARNING[6469] channel.c: Exceptionally long voice queue length queuing to Local/106@from-inside-XYZ-00000404;1
and after these , i could see hundreds of these message until i restarted asterisk (have changed IP/names etc for obv reason)
[2013-04-04 11:59:48] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘f40949f6-937e4fa4@10.10.10.10’ with owner SIP/104-XYZ-000056d5 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 11:59:54] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘f40949f6-937e4fa4@10.10.10.10’ with owner SIP/104-XYZ-000056d5 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:03:39] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘0186de534a5ac880596b77fa1f8d4f6a@90.90.90.90:5060’ with owner SIP/106-XYZ-000057e2 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:03:46] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘0186de534a5ac880596b77fa1f8d4f6a@90.90.90.90:5060’ with owner SIP/106-XYZ-000057e2 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:03:52] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘MGUyZTgwNjA3MjJhZGJlMDE2YTg5ZmUzM2VlMzk1OTU.’ with owner SIP/136-XYZ-000057ca in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:03:52] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘0186de534a5ac880596b77fa1f8d4f6a@90.90.90.90:5060’ with owner SIP/106-XYZ-000057e2 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:03:59] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘0186de534a5ac880596b77fa1f8d4f6a@90.90.90.90:5060’ with owner SIP/106-XYZ-000057e2 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:04:00] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘MGUyZTgwNjA3MjJhZGJlMDE2YTg5ZmUzM2VlMzk1OTU.’ with owner SIP/136-XYZ-000057ca in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:04:05] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘0186de534a5ac880596b77fa1f8d4f6a@90.90.90.90:5060’ with owner SIP/106-XYZ-000057e2 in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:04:07] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘1db082d03cf9a7242dd58ba36a90d938@90.90.90.90:5060’ with owner SIP/284-XYZ-0000568b in place (Method: BYE). Rescheduling destruction for 10000 ms
[2013-04-04 12:04:08] WARNING[7480] chan_sip.c: Autodestruct on dialog ‘MGUyZTgwNjA3MjJhZGJlMDE2YTg5ZmUzM2VlMzk1OTU.’ with owner SIP/136-XYZ-000057ca in place (Method: BYE). Rescheduling destruction for 10000 ms
(90.90.90.90 is the trunk side)
and from today’s outage, we again had hundreds of these auto destruct messages and had to restart asterisk again. but just before these auto destruct message, had loads of these WARNINGs ,
pbx.c: Unable to register extension ''s priority 3 in ‘from-outside-XYZ’, already in use
also i think its worth mentioning that this issue is only affecting inbound calls to the PBX, outgoing works fine even during this issue. did also check and its not maxing out CPU.
These sorts of problem are very difficult to debug. If you can provide a simple test configuration which reliably reproduces the problem you could raise a bug report. Otherwise, the only way you might get any progress is if you take a core dump and do an all thread backtrace.
There may be an element of deadlocking, so you may need to build with thread debugging enabled and run “core show locks” when the symptoms present.
The best thing would be if you could find an earlier symptom, indicating when things are starting to go wrong.
have already tried to reproduce that fault in a test system but unfortunately i could nt.
and the system is not crashing so there is no core dump.
re enabling thread debugging, may be a stupid question but as i have built asterisk from yum, how do i enable it. my understanding of this flag is that its a complier flag and you can set it while you are building * from source. is there an alternative to this complier flag when you building system from yum.
i have spent few hours crawling through the logs and sip traces, did manage to spot a call where asterisk did nt relay the 200OK (in response to invite msg) message, coming back from the phone, to the trunk side. then the caller party hung up and asterisk sent a “487 Request terminated” back. and then i could see hundreds of those autodestruct messages
In general, if you have difficult cases to debug, you cannot use packages.
You can use gcore (or manually attache gdb) to get a core dump from a running process. However, if you are using a package, there is a good chance that it was built optimised, and that makes analysing dumps difficult.
After upgrading Asterisk version from 1.4.42 to 1.8.20.1
I am getting below exception "We are getting exception in the messages logs “WARNING[7337] chan_sip.c: Autodestruct on dialog 'xxxxxxxxxxxxxxxx@x.x.x.x’ with owner SIP/x.x.x.x-00000e2a in place (Method: BYE). Rescheduling destruction for 10000”
Due to this… Calls are automatically initiating for every 10 seconds. Please advise how to fix this issue
Please explain how this warning results in calls being made every 10 seconds.
The error is almost certainly a secondary error.
What will be happening at 10 second intervals is repeat attemtps to release the data structure, in the hope that the main channel structure really has now gone.
It is unlkely that you will find an avoidance technique until you work out what is triggering the primary problem, and it is unlikely that there will be a way to fix it until a developer has enough information and time to debug it.
I faced with this problem too. We use Asterisk 11.4.0 with voice gateway Dlink DVG-5008S
When I captured traffic with tcpdump I noticed that Dlink says “INVITE” and Asterisk answers "422 Session Interval Too Small"
Searching in Google gave some results: Answer 422 indicates that value of Session-Expires header in INVITE message is too small.
I changed setting “General Settings - SIP - Session Expiration” at Dlink DVG and problem was resolved.