[Freeswitch-users] Behaviour of group_confirm_cancel_timeout
lakshmanan ganapathy
lakindia89 at gmail.com
Fri Jun 25 21:03:40 PDT 2010
Dear Antony,
Can you please give me some inputs regarding my douts?
On Sat, Jun 19, 2010 at 11:38 AM, lakshmanan ganapathy <lakindia89 at gmail.com
> wrote:
> Can you please tell me what is meant by group confirm timeouts?, because I
> thought group confirm timeouts means you are talking about
> group_confirm_cancel_timeout only. I'm sorry if my understanding is wrong.
>
>
> Here I've tested the group_confirm_cancel_timeout, and it didn't worked.
> But the same solution has worked for
> Phillip Jones
> Refer
> http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg14207.html.
>
>
> My scenario is,
> When a caller calls, an ESL Outbound socket program will be executed.
> The program will set group_confirm_key=exec and group_confirm_file=perl
> script.pl
> In the script.pl I'll get some digits from the user to get the
> confirmation, if true I'll allow him to bridge with the caller.
>
> I've also used [leg_timeout=10]. What happens is, when the user answers the
> call after 5 seconds, then while getting the password, the call gets hangup,
> due to leg_timeout.
>
> To solve this, I've added group_confirm_cancel_timeout=true, but still the
> other end got hangup immediately, once it reaches the leg_timeout.
>
> Here is my dialplan:
> <context name="default">
> <extension name="outbound_soc">
> <condition field="destination_number"
> expression="^.*$">
> <action application="set"
> data="continue_on_fail=true"/>
> <action application="set"
> data="bypass_media=false"/>
> <action application="set"
> data="ignore_early_media=true"/>
> <action application="set"
> data="exec_after_bridge_app=park"/>
> <action application="socket" data="
> 0.0.0.0:8447 async full"/>
> </condition>
> </extension>
> </context>
>
> Here is the commands they I used in NC:
> connect
>
> sendmsg
> call-command: execute
> execute-app-name: answer
>
>
> sendmsg
> call-command:execute
> execute-app-name: set
> execute-app-arg: group_confirm_key=exec
>
> sendmsg
> call-command:execute
> execute-app-name: set
> execute-app-arg: group_confirm_file=perl /root/bridge.pl
>
>
> sendmsg
> call-command:execute
> execute-app-name: set
> execute-app-arg: group_confirm_cancel_timeout=true
>
>
> sendmsg
> call-command: execute
> execute-app-name: bridge
> execute-app-arg:
> {group_confirm_cancel_timeout=true}[leg_timeout=10]user/1006
>
> Here is the bridge.pl:
> #!/usr/bin/perl
> use freeswitch;
> use Data::Dumper;
>
> our $session;
> freeswitch::consoleLog("info","Goint to get the digits");
> # To simulate the scenario I used sleep here.
> sleep(30);
> 1;
>
> Here is the FreeSwitch Log.
> http://pastebin.freeswitch.org/13220
>
> Kindly provide me some inputs.
>
> On Fri, Jun 18, 2010 at 7:44 PM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
>> I said leg timeout beats the group confirm timeouts
>>
>> group_confirm_cancel_timeout is a whole different variable, when you set
>> that to true it will stop all the timeouts as soon as you reach
>> group_confirm execution
>>
>> {group_confirm_cancel_timeout=true}[leg_timeout=10]sofia/foo/foo at bar.com
>>
>>
>>
>> On Fri, Jun 18, 2010 at 12:50 AM, lakshmanan ganapathy <
>> lakindia89 at gmail.com> wrote:
>>
>>> Dear Antony,
>>>
>>> Also in the leg_timeout wiki
>>> http://wiki.freeswitch.org/wiki/Variable_leg_timeout, it is stated as
>>> follows
>>>
>>> "If you are using group confirm then you can cancel the timeout by using
>>> the group_confirm_cancel_timeout<http://wiki.freeswitch.org/wiki/Channel_Variables#group_confirm_cancel_timeout>channel variable."
>>>
>>>
>>>
>>> On Thu, Jun 17, 2010 at 8:22 PM, Anthony Minessale <
>>> anthony.minessale at gmail.com> wrote:
>>>
>>>> no there is no way, besides making both timeouts longer.
>>>> you could file a feature request/bounty to ask for a feature to stop the
>>>> leg timer when you reach the confirm.
>>>>
>>>>
>>>> On Thu, Jun 17, 2010 at 4:23 AM, Nagalenoj H. <nagalenoj at gmail.com>wrote:
>>>>
>>>>> Anthony,
>>>>> But, then there is no use. Am I right? Usually, we'll use the
>>>>> group_confirm_cancel_timeout only when we need to override the leg_timeout.
>>>>> But it happens in reverse in this case.,
>>>>>
>>>>> I've tried using the group_confirm_cancel_timeout along with
>>>>> call_timeout and things happening similar like setting leg_timout.
>>>>>
>>>>> Then, tried without setting leg_timeout and call_timeout explicitly.
>>>>> * In this case if the callee doesn't picks the call, it
>>>>> disconnects the leg in 30 secs.
>>>>> * If he answers the call and the script continues to execute,
>>>>> the leg is disconnected in 60 secs.
>>>>>
>>>>> What I need to do is, when the callee picks the call the leg_timeout
>>>>> should not be accounted more and the leg shouldn't be disconnected because
>>>>> of leg_timeout after that.
>>>>>
>>>>> Any other way of doing this?!
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 15, 2010 at 10:53 PM, Anthony Minessale <
>>>>> anthony.minessale at gmail.com> wrote:
>>>>>
>>>>>> leg timeout beats the group confirm timeouts
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 15, 2010 at 12:28 AM, Nagalenoj H. <nagalenoj at gmail.com>wrote:
>>>>>>
>>>>>>> Dear friends,
>>>>>>> I've tried using the group_confirm_cancel_timeout channel
>>>>>>> variable. I've written a testing script to get digits before bridging. But,
>>>>>>> it doesn't seem to be working.
>>>>>>>
>>>>>>> My understanding after reading wiki is,
>>>>>>> * When I dial [leg_timeout=10]user/1005, if he answers before
>>>>>>> timeout and in the process of giving digits, then the call shouldn't be
>>>>>>> disconnected after the leg_timeout secs (10 sec in the example).
>>>>>>>
>>>>>>> But, When I experiment it, the call is getting disconnected after 10
>>>>>>> seconds and it doesn't bother whether the callee has answered the
>>>>>>> call(Started giving digits) or not answered at all.
>>>>>>>
>>>>>>> I've checked it with nc as follows,
>>>>>>>
>>>>>>> sendmsg
>>>>>>> call-command: execute
>>>>>>> execute-app-name: set
>>>>>>> execute-app-arg: group_confirm_key=exec
>>>>>>>
>>>>>>> sendmsg
>>>>>>> call-command: execute
>>>>>>> execute-app-name: set
>>>>>>> execute-app-arg: group_confirm_file=perl /root/confirm.pl
>>>>>>>
>>>>>>> sendmsg
>>>>>>> call-command: execute
>>>>>>> execute-app-name: set
>>>>>>> execute-app-arg: group_confirm_cancel_timeout=1
>>>>>>>
>>>>>>> sendmsg
>>>>>>> call-command: execute
>>>>>>> execute-app-name: bridge
>>>>>>> execute-app-arg: [leg_timeout=10]user/1005
>>>>>>>
>>>>>>> And here is the script,
>>>>>>>
>>>>>>> use freeswitch;
>>>>>>> our $session;
>>>>>>> my $digit;
>>>>>>>
>>>>>>> while(1) {
>>>>>>> # Wait till response timeout for the first digit.
>>>>>>> $digit = $session->getDigits(1, "", 10000);
>>>>>>> freeswitch::consoleLog ("info","Digit>>".$digit."<<");
>>>>>>>
>>>>>>> if (! $session->ready() ) {
>>>>>>> freeswitch::consoleLog("info","Going to Exit\n");
>>>>>>> last;
>>>>>>> }
>>>>>>> if (defined $digit and $digit ne "" ) {
>>>>>>> freeswitch::consoleLog("info","DTMF received:
>>>>>>> $digit\n");
>>>>>>> if ($digit eq '#') {
>>>>>>> return;
>>>>>>> }
>>>>>>> }
>>>>>>> else {
>>>>>>> freeswitch::consoleLog("info","Timeout\n");
>>>>>>> $session->hangup();
>>>>>>> }
>>>>>>> }
>>>>>>> 1;
>>>>>>>
>>>>>>> If my understanding is right then, I believe there is something wrong
>>>>>>> with channel_variable.
>>>>>>>
>>>>>>> Kindly help me to resolve this.
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Nagalenoj H.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> FreeSWITCH-users mailing list
>>>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>>>> UNSUBSCRIBE:
>>>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>>>> http://www.freeswitch.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anthony Minessale II
>>>>>>
>>>>>> FreeSWITCH http://www.freeswitch.org/
>>>>>> ClueCon http://www.cluecon.com/
>>>>>> Twitter: http://twitter.com/FreeSWITCH_wire
>>>>>>
>>>>>> AIM: anthm
>>>>>> MSN:anthony_minessale at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>
>>>>>> FreeSWITCH Developer Conference
>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>> pstn:+19193869900
>>>>>>
>>>>>> _______________________________________________
>>>>>> FreeSWITCH-users mailing list
>>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>>> UNSUBSCRIBE:
>>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>>> http://www.freeswitch.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Nagalenoj H.
>>>>>
>>>>> _______________________________________________
>>>>> FreeSWITCH-users mailing list
>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:
>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Anthony Minessale II
>>>>
>>>> FreeSWITCH http://www.freeswitch.org/
>>>> ClueCon http://www.cluecon.com/
>>>> Twitter: http://twitter.com/FreeSWITCH_wire
>>>>
>>>> AIM: anthm
>>>> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:+19193869900
>>>>
>>>> _______________________________________________
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at 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 at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:+19193869900
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100626/aa6f40e6/attachment-0001.html
More information about the FreeSWITCH-users
mailing list