ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
Hi! Switched from outbound ESL to an INBOUND mode, for controlling the incoming CALL flow: so when call comes, Inbound ESL app catches corresponding event and executes the necessary command on the caller UUID. My question is: In XML dialplan, when call comes, if do not PARK it or do PAUSE, the ESL controlling application is too late to execute park before XML dialplan ends, and disconnect the call. PARK shows itself as not a good solution, since if call did not handled by ESL - it stales. PAUSE - i would not like to add extra delays to call handling. I suppose there should be a known good way to handle in XML dialplan if anything else executed on the given channel/uuid? Regards, Anton.
PARK is the only way to handle this in a good way. If you can't separate the calls directly in the dial plan, you could probably do a transfer of the call (that you don't want to handle) inside your app, to another extension in the dial plan. /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 17:40 Till: FreeSWITCH Users Help Ämne: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL? Hi! Switched from outbound ESL to an INBOUND mode, for controlling the incoming CALL flow: so when call comes, Inbound ESL app catches corresponding event and executes the necessary command on the caller UUID. My question is: In XML dialplan, when call comes, if do not PARK it or do PAUSE, the ESL controlling application is too late to execute park before XML dialplan ends, and disconnect the call. PARK shows itself as not a good solution, since if call did not handled by ESL - it stales. PAUSE - i would not like to add extra delays to call handling. I suppose there should be a known good way to handle in XML dialplan if anything else executed on the given channel/uuid? Regards, Anton. _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org !DSPAM:4df38d5032765714154118!
now actually I do park over ESL, as soon as I get channel_create message, and there is only a single command in the XML dialplan: pause 1000. I was hoping there is a better approach to this. PS. Outbound ESL showed itself as a terribly bad scaling solution if implemented in python... 2011/6/11 Peter Olsson <peter.olsson@visionutveckling.se>:
PARK is the only way to handle this in a good way. If you can't separate the calls directly in the dial plan, you could probably do a transfer of the call (that you don't want to handle) inside your app, to another extension in the dial plan.
/Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 17:40 Till: FreeSWITCH Users Help Ämne: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
Hi!
Switched from outbound ESL to an INBOUND mode, for controlling the incoming CALL flow: so when call comes, Inbound ESL app catches corresponding event and executes the necessary command on the caller UUID.
My question is: In XML dialplan, when call comes, if do not PARK it or do PAUSE, the ESL controlling application is too late to execute park before XML dialplan ends, and disconnect the call.
PARK shows itself as not a good solution, since if call did not handled by ESL - it stales. PAUSE - i would not like to add extra delays to call handling.
I suppose there should be a known good way to handle in XML dialplan if anything else executed on the given channel/uuid?
Regards, Anton.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
!DSPAM:4df38d5032765714154118!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I do it like this; First I separate calls in the dialplan, those calls with a destination to my "IVR" i will first set a variable, for instance "ivr=true", I then park the call in the dialplan. In my ESL app I wait for the CALL_PARKED event, I then check if the var is set on the call - if it is I start handling it. /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 18:07 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL? now actually I do park over ESL, as soon as I get channel_create message, and there is only a single command in the XML dialplan: pause 1000. I was hoping there is a better approach to this. PS. Outbound ESL showed itself as a terribly bad scaling solution if implemented in python... 2011/6/11 Peter Olsson <peter.olsson@visionutveckling.se>:
PARK is the only way to handle this in a good way. If you can't separate the calls directly in the dial plan, you could probably do a transfer of the call (that you don't want to handle) inside your app, to another extension in the dial plan.
/Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 17:40 Till: FreeSWITCH Users Help Ämne: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
Hi!
Switched from outbound ESL to an INBOUND mode, for controlling the incoming CALL flow: so when call comes, Inbound ESL app catches corresponding event and executes the necessary command on the caller UUID.
My question is: In XML dialplan, when call comes, if do not PARK it or do PAUSE, the ESL controlling application is too late to execute park before XML dialplan ends, and disconnect the call.
PARK shows itself as not a good solution, since if call did not handled by ESL - it stales. PAUSE - i would not like to add extra delays to call handling.
I suppose there should be a known good way to handle in XML dialplan if anything else executed on the given channel/uuid?
Regards, Anton.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org !DSPAM:4df392d332762225017462!
very similar... 2011/6/11 Peter Olsson <peter.olsson@visionutveckling.se>:
I do it like this;
First I separate calls in the dialplan, those calls with a destination to my "IVR" i will first set a variable, for instance "ivr=true", I then park the call in the dialplan. In my ESL app I wait for the CALL_PARKED event, I then check if the var is set on the call - if it is I start handling it.
/Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 18:07 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
now actually I do park over ESL, as soon as I get channel_create message, and there is only a single command in the XML dialplan: pause 1000. I was hoping there is a better approach to this.
PS. Outbound ESL showed itself as a terribly bad scaling solution if implemented in python...
2011/6/11 Peter Olsson <peter.olsson@visionutveckling.se>:
PARK is the only way to handle this in a good way. If you can't separate the calls directly in the dial plan, you could probably do a transfer of the call (that you don't want to handle) inside your app, to another extension in the dial plan.
/Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 17:40 Till: FreeSWITCH Users Help Ämne: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
Hi!
Switched from outbound ESL to an INBOUND mode, for controlling the incoming CALL flow: so when call comes, Inbound ESL app catches corresponding event and executes the necessary command on the caller UUID.
My question is: In XML dialplan, when call comes, if do not PARK it or do PAUSE, the ESL controlling application is too late to execute park before XML dialplan ends, and disconnect the call.
PARK shows itself as not a good solution, since if call did not handled by ESL - it stales. PAUSE - i would not like to add extra delays to call handling.
I suppose there should be a known good way to handle in XML dialplan if anything else executed on the given channel/uuid?
Regards, Anton.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
!DSPAM:4df392d332762225017462!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
BTW, what language do you use for your ESL app? Any info on performance? How many CPS? 2011/6/11 Anton VG <anton.vazir@gmail.com>:
very similar...
2011/6/11 Peter Olsson <peter.olsson@visionutveckling.se>:
I do it like this;
First I separate calls in the dialplan, those calls with a destination to my "IVR" i will first set a variable, for instance "ivr=true", I then park the call in the dialplan. In my ESL app I wait for the CALL_PARKED event, I then check if the var is set on the call - if it is I start handling it.
/Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 18:07 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
now actually I do park over ESL, as soon as I get channel_create message, and there is only a single command in the XML dialplan: pause 1000. I was hoping there is a better approach to this.
PS. Outbound ESL showed itself as a terribly bad scaling solution if implemented in python...
2011/6/11 Peter Olsson <peter.olsson@visionutveckling.se>:
PARK is the only way to handle this in a good way. If you can't separate the calls directly in the dial plan, you could probably do a transfer of the call (that you don't want to handle) inside your app, to another extension in the dial plan.
/Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Anton VG [anton.vazir@gmail.com] Skickat: den 11 juni 2011 17:40 Till: FreeSWITCH Users Help Ämne: [Freeswitch-users] ESL Inbound - what would be the best known way to wait in XML dialplan for any command execution via ESL?
Hi!
Switched from outbound ESL to an INBOUND mode, for controlling the incoming CALL flow: so when call comes, Inbound ESL app catches corresponding event and executes the necessary command on the caller UUID.
My question is: In XML dialplan, when call comes, if do not PARK it or do PAUSE, the ESL controlling application is too late to execute park before XML dialplan ends, and disconnect the call.
PARK shows itself as not a good solution, since if call did not handled by ESL - it stales. PAUSE - i would not like to add extra delays to call handling.
I suppose there should be a known good way to handle in XML dialplan if anything else executed on the given channel/uuid?
Regards, Anton.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
!DSPAM:4df392d332762225017462!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Sat, Jun 11, 2011 at 10:07 AM, Anton VG <anton.vazir@gmail.com> wrote:
PS. Outbound ESL showed itself as a terribly bad scaling solution if implemented in python...
What? I don't mean to troll here, but what does the language (in this case, Python) have to do with scaling Oubound ESL? Any long-running process is going to be able to handle the setup and teardown of TCP connections without much trouble. One could foul up ESL (in or out) in any language, and maybe you've see it done poorly in Python, but I'd have to hear/see more before accepting that it's a particularly bad choice. I'd love to understand better where you are coming from, if you'd care to share. Best, Gabe
Gabe, Try implementing yourself outbound stuff in python, and you will quickly find out, after trying feeding several hundred cps to it, while keeping several hundred sessions online. 2011/8/25 Gabriel Gunderson <gabe@gundy.org>:
On Sat, Jun 11, 2011 at 10:07 AM, Anton VG <anton.vazir@gmail.com> wrote:
PS. Outbound ESL showed itself as a terribly bad scaling solution if implemented in python...
What?
I don't mean to troll here, but what does the language (in this case, Python) have to do with scaling Oubound ESL? Any long-running process is going to be able to handle the setup and teardown of TCP connections without much trouble.
One could foul up ESL (in or out) in any language, and maybe you've see it done poorly in Python, but I'd have to hear/see more before accepting that it's a particularly bad choice.
I'd love to understand better where you are coming from, if you'd care to share.
Best, Gabe
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Anton VG
-
Gabriel Gunderson
-
Peter Olsson