[Home]

Summary:ASTERISK-22379: Strange dialplan lookups happening when dial()ing sip peers
Reporter:Birger "WIMPy" Harzenetter (wimpy)Labels:
Date Opened:2013-08-23 17:37:42Date Closed:2013-09-26 16:48:51
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:SVN Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) astdebug
( 1) dial-contexts.txt
( 2) sip-conf-info
Description:I'm experiencing very noticeable delays on delivering calls do to an unexplained dialplan lookup. This probably wouldn't be any issue at all if it wouldn't happen in a context that contains loopback switches to a dundi switch that, off course, takes some time to fail.
Comments:By: Birger "WIMPy" Harzenetter (wimpy) 2013-08-23 17:47:52.331-0500

That's quite a lot of debug unfortunately. It's not about the dundi lookups at the beginning they are expected.

It's what happens after executing dial (line 1161). After the outgoing sip channel is created (line 1300) there is a dialplan lookup happening for dial-master,,1. (empty extension)
As dial-master contains loopack switches to dial-canonical, which again contains a dundi switch, it looks for several possible expansions of "" via dundi.

The interesting thing is that this call is not going through the dial-master context.
That is however the context defined for calls from the _called_ peer. (context= in sip.conf)
It is also Context, Exten and Priority as seen in the varset events on the outgoing channels.
By: Rusty Newton (rnewton) 2013-09-05 18:17:03.290-0500

That looks weird...

Can you post the sip.conf as well?

Maybe you can narrow it down by minimizing the dialplan?

Remove all the dialplan that the call shouldn't be going through and see where it fails.

If possible, remove DUNDI from the picture and try to reproduce, then remove switches..

Can you also post a "sip show peer" and "sip show user" for both of the SIP peers being dialed?
By: Birger "WIMPy" Harzenetter (wimpy) 2013-09-05 19:04:54.009-0500

Sip info attached as requested.

I don't see much point in trying to empty or remove the unrelated contexts. It's pretty clear why they cause a huge delay.
The question is why something tries to use the dialplan at all.
By: Rusty Newton (rnewton) 2013-09-09 15:58:53.872-0500

Mark Michelson and I both looked into the debug and configs so far. It is not clear to us how the call to SIP/digidev&SIP/digidevs is triggering the dialplan execution at their assigned contexts.

1. Did this start after an update to your trunk version? Do you know when it was previously working different?

bq. The question is why something tries to use the dialplan at all.

Yes this is what we would like to find out.

2. Please provide steps for reproduction so that we can easily reproduce the behavior. I think that is easiest if you minimize your configuration to only what is needed to reproduce the issue. Often in doing that for other issues I find that seemingly unrelated aspects of configuration are sometimes related.

Thanks!
By: Rusty Newton (rnewton) 2013-09-26 16:48:51.393-0500

WIMPy I'm going to close this one out until there is a reliable way to reproduce it posted to the issue. We can gladly take a look further into it, but you know we have a few hundred other issues to go look at.

Right now we can't really identify if this is just a really weird configuration issue, or a definite bug.

If more people start seeing it, or if you can find a way to describe reproduction we can open it back up. Thanks for the report! You can always message me on IRC if you have more info.