Originate issue when using Local/exten/context triggers Hangup Weirdly

I am running into a tough one.

So we have a dialer that uses ami to generate an originate call

Now this works perfect if I want to use a specific trunk:

Action: originate
Channel: IAX2/voipMSTEST/6305551234
Exten: s
Context: speech-rec
Priority: 1

My issue is I want to instead use a context to dial since I will be implementing LCR and failover routing, so the new originate looks like below, but the problem is when I use a local context instead of the trunk, the DIAL app triggers a hangup immidately when the DIAL app is ran in the speech-rec context. Then even though I set the g flag so it continues the dialplan, it does not. Any idea why this is doing that? My alternative is to write the logic outside asterisk, but I’d like to do it inside:

Action: originate
Channel: IAX2/voipMSTEST/6305551234
Channel: Channel: Local/s@outbound-dialer-custom
Exten: s
Context: speech-rec
Priority: 1

So the above originate uses outbound-dialer-custom to call my cell phone 6305551111, connects me to do the speech-rec context… All of this works perfectly. Then in the speech-rec context I patch into my office line using the

exten => s,n,Dial(IAX2/voipMSTEST/6305551234,30,ge)

Everything up to this point works perfectly until I answer the office line. Immidiately when I do the hangup extension is hit, and the items in my dialplan after the DIAL_APP in speech-rec context never run.

Again, this works flawlessly though if instead of using a Local/s@outbound-dialer-custom channel I use the
IAX2/voipMSTEST/63055512345 channel… Only problem in doing it that way my failovers and lcr I cannot build into my asterisk dialplan… Any suggestions?

[outbound-dialer-custom]
;exten => s,1,NoOp()
exten => s,n,Dial(IAX2/voipMSTEST/6305551111,30) 
exten => s,n,Hangup();

exten=>h,1,Verbose(2,### HANGUPOUTBOUNDDIALER #######)


[speech-rec]
 exten => s,1,Answer()
   exten => s,n,Wait(3)
   exten => s,n,Dial(IAX2/voipMSTEST/6305551234,30,g)
;The second I answer on above number a Hangup even happens and nothing after this runs?????
   exten => s,n,Verbose(2,### HANGUPGO #######)
   exten => s,n,Hangup()

        exten => h,1,NoOp(${DIALSTATUS})
	exten => h,n,NoOp(${ANSWEREDTIME})
	exten => h,n,NoOp(${DIALEDTIME})

Anyone have any ideas?

Local channels can optimize themselves and disappear. Without a console log showing what is going on that’s only a guess. You can prevent it by adding “/n” to the end of your Local dial string.

There’s nothing on the console log besides it showing the channel hanging up.

Are you saying on my originate command changing to this?

Local/s@outbound-dialer-custom/n

?

Yes, and if you increase the verbosity (core set verbose 5) then you may get more information on the console.

Ok… So your trick did it!!! Thanks so much. Can you please let me know what putting a /n does?

Why does this make it work correctly?

Thanks!

A Local channel will optimize itself out if there’s things on each side, causing the dialplan in between to not get executed. The ‘/n’ disables this functionality. You can read about it on the wiki[1].

[1] https://wiki.asterisk.org/wiki/display/AST/Local+Channel+Optimization

1 Like

Thanks so much!

Just one more question. How much more overhead am I adding to asterisk by using a local channel to originate a call with the /n on it than I would be to originate to a Sip/55555555555@myoutbountsiptrunk

Both produce the exact same result, but am I sacraficing a lot of overhead this way? If so I will have no choice but to build the fail and lcr logic outside of asterisk, which is not what I’d want as a failed call is much easier to catch realtime in a dialplan, than an async originate ami call (I need to check the cdr, or event monitor, which adds a couple fail points).

Thanks

It’s more channels, and more memory allocations. What that means would have to be profiled for your usage to see the impact. It’s not a ton though unless you get into high concurrent count.

We just were about to go to production with this and I found an issue.

when I use a local context, if there is no answer within 30 seconds of the time I connect to
Local/s@outbound-dialer-custom/n

it timesout and I cannot find anyway to extend that 30 seconds.

I tried

Action: originate
Channel: Local/s@outbound-dialer-custom/n
Exten: s
Context: speech-rec
Priority: 1
Timeout: 60000

and that did nothing, I tried settings the absolute and response digit and that did nothing, and I am running out of options. When I check the outbound-dialer-custom channel state it says ringing even before it gets to the dial application, so I think it is a timeout there. Basically the channel times out before the dial timeout causing me some issues.

Anyway to extend the timeout on that channel (I think its the ringtimeout of the channel, as no matter what I do, I have 30 seconds to connect or it terms out

so if this was my context

[outbound-dialer-custom]
exten =>s,1,NoOp()
exten =>s,n,wait(31)
exten => s,n,Dial(IAX2/voipMSTEST/6305551111,30)

Dial would never even be reached.

Thanks!

Look for a 30 in your dialplan and either remove it or set it to an appropriate higher figure.

HI david, I had to create another account it would not let me log in for some reason even after 5 password resets. I dont think you understood what I was saying. THe issue is in the originate

so look at this, this is what I am sending to my asterisk manager

Action: originate
Channel: Local/s@outbound-dialer-custom/n
Exten: s
Context: speech-rec
Priority: 1
Timeout: 60000

if my context was this that I am originating FROM, not my destination (the dialer context does my dial for me, so it’s unique in I am not using the SIP/XYZ/NUM directly, but this is what I have to use.
[outbound-dialer-custom]
exten =>s,1,NoOp()
exten =>s,n,wait(40)

It would still terminate the context at 30 seconds in the midst of the wait application. The channel state when I look at it on the log is RING, so I think there is a default ring timer somewhere on the originate. There is nothing in the dialplan itself though where I can override this that I can find, or a way around this. Any help would be greatly appriciated!

The channel is fully up at that point, so I would look to the peer.

Such a dumb mistake! Finally figured it out… So my originate is handled via a looping script written in php.

Well my changes to timeout were being saved in my file so it looked good… BUT I had to kill the loop as the prior 30000 millisecond code was running in memory… In essance, thanks, but it was just fatigue error!