Would it be possable to ask what your real application is, other then just originating calls via ESL? What are you trying to actually find out by subscribing to events? How much control do you need over the call from you ESL application, once the call is created?
Do you have the new FS book? It does a better job of not refering to things like ESL as a replacment for doing an API command and things like that. You do know that there are many other options other then ESL to do external origination of a call? It may be the right answer, or it may not.
In most cases just one single interface to FS, while can be used to do the entire application, the greatest thing about FS is that you can mix and match the different interfaces. Some in ESL, and then some of the supporting things that are needed to control the call mid-stream can be done with others.
Just to give one example, you may want to originate a call from ESL, but use apps from the dialplan after the call is in prgress to actually handle the call flow. If you do something like that, you could report back to your application w/ custom events fired from either the dialplan, or API with only the info you want, w/o having to track the call with the CHANNEL_* events.
For external applications remember that the API_ON_* and the EXECUTE_ON_* variables that you can pass in the dial string are your friend. Also when you use these *_ON_* variables and set them from a dialstring w/ originate, you can pass variable substitution that can be evaled at execute time. Example: {origination_nested_vars=true,api_on_hangup=lua myscript ${var_i_set_in_dialplan}}sofia/gateway/.... This would invoke a lua script when the calll complted and pass to it the the evaled var_i_set_in_dialpaln, with it's value at the time it was executed. That script could create a custom event, with all the data collected from the dialplan apps that were called to handle the call and report it back to your external application in a single message, no need to track the call through it's states.
Remember this is just one example, but with FS and external applications it's best to think of FS as a bunch of building blocks (lego parts) that you can stitch together to provide your complete solution.
--Dave
From: Steven Ayre [mailto:steveayre@gmail.com]
To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]
Sent: Mon, 17 Jun 2013 06:40:33 -0700
Subject: Re: [Freeswitch-users] Inconsistent Event CHANNEL_PROGRESS
On the PSTN *if* there's no Alerting you'll likely go straight to the answer state never seeing CHANNEL_PROGRESS.
Also you may want to watch for CHANNEL_PROGRESS_MEDIA as well as CHANNEL_PROGRESS. They are similar but slightly different events.
-Steve
On 17 June 2013 20:19, Steven Ayre
<steveayre@gmail.com> wrote:
How does that affect my answer? :)