40 second delay in dialing

I have a trunk set up to send long distance calls out to an Audiocodes SIP gateway. My trunk dial plan looks like this…

[trunkld] ; ; Long distance context accessed through trunk ; exten => _91NXXNXXXXXX,1,Dial(SIP/${EXTEN}@10.10.1.202)

When I dial number that matches that pattern from one of my IP phones, it is taking 40 seconds for Asterisk to actually send the SIP invite to the gateway.

I have observed the following from the Asterisk CLI. When I initiate the call from the IP phone, immediately see the following…

== Using SIP RTP CoS mark 5 -- Executing [918642864941@users:1] Dial("SIP/1000-0000010a", "SIP/918642864941@10.10.1.202") in new stack

And then 40 seconds later…

== Using SIP RTP CoS mark 5 -- Called 918642864941@10.10.1.202 -- SIP/10.10.1.202-0000010b is ringing -- SIP/10.10.1.202-0000010b answered SIP/1000-0000010a -- Native bridging SIP/1000-0000010a and SIP/10.10.1.202-0000010b == Spawn extension (users, 918642864941, 1) exited non-zero on 'SIP/1000-0000010a'

I have done some research on my own and found that 40 second is the default master timeout for Asterisk. I am just not sure what it is waiting for.

My guess is that it is trying to reverse resolve the IP address against a broken DNS (one that doesn’t respond, rather than responding “not found”).

I am having it dial by IP address (SIP/${EXTEN}@10.10.1.202) so I am not sure what DNS would have to do with it. The call is going through successfully; it just takes 40 seconds to do so.

I said reverse DNS, getting a name from the IP address.

The easiest approach to this is probably to attach a debugger and then run thread apply all bt. That will allow you to work out where it is waiting.

[quote=“david55”]
The easiest approach to this is probably to attach a debugger and then run thread apply all bt. That will allow you to work out where it is waiting.[/quote]

Forgive my ignorance, as I am still kinda new to Asterisk, but what is the best way of doing that?

This isn’t actually a deadlock, but the same process applies.

wiki.asterisk.org/wiki/display/ … rADeadlock

[quote=“david55”]This isn’t actually a deadlock, but the same process applies.

wiki.asterisk.org/wiki/display/ … rADeadlock[/quote]

It looks like this going to require me to recompile Asterisk which I am not sure how to do on an AsteriskNOW box. Is there any other way to debug this?

You will get some idea of what it is doing from an optimised build; it just won’t be acceptable for a bug report.

I have been able to fix this based on david55’s assumption that the delay was coming from a reverse DNS lookup. Instead having is dial an IP address, I created a context in sip.conf that looks like this…

[audiocodes] ;FXO Gateway for PSTN type=friend host=10.10.1.166 context=trunkld

and my trunk dialplan looks like this now…

[trunkld] ; ; Long distance context accessed through trunk ; exten => _91NXXNXXXXXX,1,Dial(SIP/${EXTEN}@audiocodes,20)

and it works like a charm. Thanks for the nudge in the right direction david55