Autodestruct on dialog?

Asterisk Asterisk Support
1

After weeks of performing fantasically, our Asterisk went haywire the other day.

I looked at the logs of our server and it does, indeed, report losing the ability to communicate with Asterisk at some point (we’re using the Java API):

In the var/logs/messages file of our Asterisk install, I see this huge string of “Autodestruct” errors, all of which look something similar to this:

[Sep 28 14:47:20] WARNING[25703] chan_sip.c: Autodestruct on dialog '973229537_87662997@66.7.123.144' with owner in place (Method: BYE)
[Sep 28 14:51:24] WARNING[25703] chan_sip.c: Autodestruct on dialog '2ad5325a16791b0c33ea74222848e3c0@10.30.0.232:5060' with owner in place (Method: BYE)

I’ve done a Google search, looked on these forums, and looked on voip-info.org but can’t find any good information about what may have happened and how to avoid it.

Our setup is simple: we have a SIP provider and have eight channels with them. We process outgoing calls which remind patients of their dentist appointment and also incoming calls that allow offices to record a custom greeting to give to their patients.

Both calls trigger an AGI script where I present an IVR.

The error seem to have occurred on an incoming call.

Does anyone have any ideas what suddenly caused this?

2

Have you got an extremely long running h extension?

3

I haven’t specifically defined an “h” extension in the extensions.conf file. Could that be the problem in and of itself?

4

No. The error is saying that you still have a channel associated with a dialogue a long time after the dialogue is over. That could be a bug, but the possibility that you were running something on the h extension that took longer than the time to destroy the dialogue also occurred to me.

5

Thanks for the info! That gave me a place to start looking.

Here’s what I did: first, I added a Hangup() command immediately after the AGI() command in the extension. I also made sure that the AGI script calls the hangup() method.

exten => 666,1,Agi(agi://localhost/vrscript.agi)
exten => 666,n,Hangup()

I also added/enabled default-ish values for timeouts to the sip.conf file:

rtptimeout=60
rtpholdtimeout=300

I attached to the running Asterisk via CLI, i.e.:

asterisk -r

Now, when there are calls, I can use the command:

sip show channels

I noticed that several seconds after it hangs up, I see something like this (numbers blanked out):

bell*CLI> sip show channels
Peer  User/ANR  Call ID  Format  Hold  Last Message  Expiry  Peer
XX.X.XXX.XX  1801XXXXXXX  7bcf40e66b6281d  0x0 (nothing)  No  Rx: BYE  veracity

So it basically stays at Rx: BYE for several seconds.

Is this something at the SIP trunk provider level that may be happening? Did my rtptimeout possibly fix something?

Thanks in advance!

6

That’s normal. The problem is not the autodestruct, but the fact that the channel private structure still has an owning channel.

sip show channels shows the private structures and they are kept around in order to be able to cope with retransmissions. The autodestruct happens when it is too late to receive a retransmission from the other side.

7

[quote=“david55”]That’s normal. The problem is not the autodestruct, but the fact that the channel private structure still has an owning channel.

sip show channels shows the private structures and they are kept around in order to be able to cope with retransmissions. The autodestruct happens when it is too late to receive a retransmission from the other side.[/quote]

I just caught one today! It has been stuck on “Rx: BYE” for the last 20 minutes.

Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer
66.7.123.144     8013317126       1661308552_7929  0x4 (ulaw)       No       Rx: BYE                    veracity

I even saw the “Autodestruct” message come through in the Asterisk logs but it’s still there!

Could this be something in our code, something on the end of our SIP trunk provider, a misconfigured Asterisk?

Thank you for your help so far, BTW!

8

I found out a little more: this resulted from an incoming call. I also see in the Asterisk messages file in the log directory:

[Oct  4 09:03:11] NOTICE[15585] chan_sip.c: Disconnecting call 'SIP/veracity-0000004f' for lack of RTP activity in 61 seconds

The rtptimeout attempted to kick in but unsuccessfully closed the channel.

9

It could be an Asterisk bug, or a dialplan problem. It shouldn’t be the result of a provider problem.

10

We got to the bottom of it yesterday. Thanks for your help!

11

I’m running into the same issue on our system. What was the final cause of that channel staying open? It appears that its stuck on Rx: BYE for many calls.

I do have 2-3 SQL queries on the h exten but dont have anything to say its hanging on those.