40 second delay in dialing


#1

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.


#2

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”).


#3

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.


#4

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.


#5

[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?


#6

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

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


#7

[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?


#8

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


#9

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