How to tell the state of the other end of a Originate()

When calling Originate like: Originate(Local/ext@originator_primary,exten,originator_secondary,ext,1,1,a) is there a way for originator_primary to tell the call state (ringing/answered) of originator_secondary in the dialplan if originator_secondary performs a Dial()? As far as I can tell one of originator_primary or originator_secondary must be answered() immediately, and I’m unclear on how to block one end of the originate until the other answers.

I’m looking for a solution that works with outbound calls, so dialplan hints won’t work. CHANNEL() doesn’t seem to have a ringing/answered state and I’m not sure how to properly get the other end channel ID anyway.

In Asterisk, when using the Originate application to initiate calls, you typically don’t have direct access to the call state (ringing/answered) of the callee (originator_secondary) from the caller’s context (originator_primary) during the Originate process.

  1. Use Local Channels: Instead of directly dialing originator_secondary from originator_primary, you can use local channels. The local channel allows you to execute a dialplan context and retrieve the result.Example:
exten => s,1,Dial(SIP/exten)
exten => s,n,Set(RESULT=${DIALSTATUS}) ; Store the dial status
exten => s,n,Return()
  1. Retrieve Call Status: After initiating the call with the Originate application, you can monitor the status of the call by reading the value of the RESULT variable set in the dialplan of originator_secondary.Example:
exten => s,1,Originate(Local/ext@originator_secondary,exten,originator_secondary,ext,1,1)

exten => s,1,Dial(SIP/exten)
exten => s,n,Set(RESULT=${DIALSTATUS}) ; Store the dial status
exten => s,n,Return()

Once the call status is obtained in originator_primary, you can take appropriate actions based on the result.


exten => s,n,GotoIf($["${RESULT}"="ANSWER"]?answered:ringing)

; Handle answered call scenario

; Handle ringing call scenario

By using this method, you can communicate the call status from originator_secondary back to originator_primary .

You have to originate to the one that you want to answer first.

This is where I’m getting confused, when the Dial transitions from ringing to answered it doesn’t re-enter the dialplan, so won’t this variable not be updated?

Also, what’s the scope of the RESULT variable? Isn’t that a channel variable? That variable is shared between the two sides of the Originate()?

You have to originate to the one that you want to answer first.

I tried this but it behaved the same. If I didn’t immediately answer the secondary side the primary immediately hungup.

Please provide verbose full logs (verbosity 3 or more), so that I can understand what you are doing.

Local channels are not subroutines. They should be ended by Hangup, or falling off the end. Because it is not a subroutine, the local variable will be lost when it ends

In any case the action for the originate will not be run unless Dial succeeds, and will be run as soon as the channel answers.

There is only one channel involved in a simple originate. However the use of a local channel means that there are now two.

That’s a good idea. I’ll make some test cases to make sure the questions and behavior are clear. I’ll report back in after I have time to do so, currently teaching myself ARI.

So just to close the thread I was able to do what I intended to do in ARI, and it was a lot easier. I’d fully intended to reproduce this to help bridge the documentation gaps I’d been struggling with, but life is getting in the way and my free time has been sucked up by other urgent issues. To anyone else struggling with this I recommend using ARI instead. It’s not hard to learn, and if you’re concerned about it’s security like I initially was set up a enclave Asterisk behind a tight firewall that handles the Stasis app and trunk your calls into it with IAX. That’s what I did, works fine. Even easier if you’re using Docker.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.