[Freeswitch-users] Help regard to park_timeout

Tue Jan 25 10:02:24 MSK 2011

The output of a uuid_dump is here:

> uuid_dump ff64db72-284d-11e0-abd4-772c8caa0462

Event-Name: CHANNEL_DATA
Core-UUID: 05595dbc-27b0-11e0-ab9f-772c8caa0462
FreeSWITCH-Hostname: FMS-Demo
FreeSWITCH-IPv4: 192.168.1.72
FreeSWITCH-IPv6: %3A%3A1
Event-Date-Local: 2011-01-25%2012%3A10%3A49
Event-Date-GMT: Tue,%2025%20Jan%202011%2006%3A40%3A49%20GMT
Event-Date-Timestamp: 1295937649908745
Event-Calling-File: mod_commands.c
Event-Calling-Function: uuid_dump_function
Event-Calling-Line-Number: 4130
Channel-State: CS_EXECUTE
Channel-Call-State: ACTIVE
Channel-State-Number: 4
Channel-Name: FreeTDM/1%3A1/9952248266
Unique-ID: ff64db72-284d-11e0-abd4-772c8caa0462
Call-Direction: outbound
Presence-Call-Direction: outbound
Channel-Call-UUID: ff64cfc4-284d-11e0-abd3-772c8caa0462
Answer-State: answered
Channel-Read-Codec-Name: PCMA
Channel-Read-Codec-Rate: 8000
Channel-Read-Codec-Bit-Rate: 64000
Channel-Write-Codec-Name: PCMA
Channel-Write-Codec-Rate: 8000
Channel-Write-Codec-Bit-Rate: 64000
Caller-Direction: outbound
Caller-Destination-Number: 9952248266
Caller-Unique-ID: ff64db72-284d-11e0-abd4-772c8caa0462
Caller-Source: src/switch_ivr_originate.c
Caller-Context: default
Caller-Channel-Name: FreeTDM/1%3A1/9952248266
Caller-Profile-Index: 1
Caller-Profile-Created-Time: 1295937628350711
Caller-Channel-Created-Time: 1295937628350711
Caller-Channel-Answered-Time: 1295937635463788
Caller-Channel-Progress-Time: 0
Caller-Channel-Progress-Media-Time: 1295937632566721
Caller-Channel-Hangup-Time: 0
Caller-Channel-Transfer-Time: 0
Caller-Screen-Bit: true
Caller-Privacy-Hide-Name: false
Caller-Privacy-Hide-Number: false
variable_direction: outbound
variable_uuid: ff64db72-284d-11e0-abd4-772c8caa0462
variable_read_codec: PCMA
variable_read_rate: 8000
variable_write_codec: PCMA
variable_write_rate: 8000
variable_channel_name: FreeTDM/1%3A1/9952248266
variable_freetdm_span_name: wp1
variable_freetdm_span_number: 1
variable_freetdm_chan_number: 1
variable_is_outbound: true
variable_call_uuid: ff64cfc4-284d-11e0-abd3-772c8caa0462
variable_ignore_early_media: true
variable_api_hangup_hook: perl%20/root/a.pl
variable_exec_after_bridge_app: park
variable_originate_early_media: false
variable_endpoint_disposition: ANSWER
variable_current_application: park

> eval uuid:ff64db72-284d-11e0-abd4-772c8caa0462
${variable_exec_after_bridge_app}
park

> eval uuid:ff64db72-284d-11e0-abd4-772c8caa0462 ${variable_park_timeout}
-ERR no reply

When I looked into the source I found that, the variable park_timeout is
being set to NULL, once it is read in switch_ivr.c under switch_ivr_park()
function. So I think that's why uuid_getvar returns __undef__.

After seeing this, I experimented as follows.
I made 2 calls.
CLI> originate
{ignore_early_media=true,park_timeout=50,api_hangup_hook='perl
/root/a.pl',exec_after_bridge_app=park}freetdm/grp1/a/9952248266
&park()
CLI > originate
{ignore_early_media=true,park_timeout=50,api_hangup_hook='perl
/root/a.pl'}freetdm/grp1/a/9843171457
&park()

Then I bridged them using uuid_bridge.
CLI> uuid_bridge 6e53bbae-277f-11e0-8580-8390cbcc860f
75126f12-277f-11e0-8582-8390cbcc860f
Now:
uuid_getvar 6e53bbae-277f-11e0-8580-8390cbcc860f park_timeout ( return
__undef__. So I set the park_timeout from the CLI explicitly ).

CLI> uuid_setvar 6e53bbae-277f-11e0-8580-8390cbcc860f park_timeout 20
CLI> uuid_getvar 6e53bbae-277f-11e0-8580-8390cbcc860f park_timeout ( returns
20 ).

Now I hangup the call with 75126f12-277f-11e0-8582-8390cbcc860f UUID.

After that, 6e53bbae-277f-11e0-8580-8390cbcc860f call goes in to park, and
after 20 seconds the call got ended, and it works as I expected.

Now I need to know, whether any specific purpose is there to set the
park_timeout to NULL once it is read?  The variable park_after_bridge is
also set to NULL? I'm unable to find reasons for this. Someone please light
me on this!.

Thanks for your response.

On Tue, Jan 25, 2011 at 1:46 AM, Michael Collins <msc at freeswitch.org> wrote:

> Do a uuid_dump on the channel and see what all is there. Also, try doing
> this:
> eval uuid:9b59d172-2781-11e0-8586-8390cbcc860f ${park_timeout}
>
> See what happens.
>
> -MC
>
> On Sun, Jan 23, 2011 at 10:21 PM, lakshmanan ganapathy <
> lakindia89 at gmail.com> wrote:
>
>> Hi all,
>> I've done a further experimentation and I need a clarification.
>>
>> From CLI>
>> originate {ignore_early_media=true,park_timeout=50,api_hangup_hook='perl
>> /root/a.pl',exec_after_bridge_app=park}freetdm/grp1/a/9952248266 &park()
>>
>> Then I executed the following commands from CLI.
>> uuid_getvar 9b59d172-2781-11e0-8586-8390cbcc860f park_timeout
>> _undef_
>> uuid_getvar 9b59d172-2781-11e0-8586-8390cbcc860f api_hangup_hook
>> perl /root/a.pl
>>
>> I don't know why uuid_getvar, returns undef for park_timeout variable. But
>> the call is hangup once 50 seconds is reached. Can some one pls explain what
>> it is printing as __undef__
>>
>>
>>
>> On Fri, Jan 21, 2011 at 6:37 PM, lakshmanan ganapathy <
>> lakindia89 at gmail.com> wrote:
>>
>>> Dear all,
>>> I was using park_timeout and I come across the following scenario which I
>>> felt something is missing.
>>> I've originated a call as follows.
>>>
>>> originate
>>> {ignore_early_media=true,exec_after_bridge_app=park,park_timeout=60,api_hangup_hook='perl
>>> /root/a.pl'}freetdm/grp1/a/9952248266 &park()
>>>
>>> Once the call is answered I originated another call.
>>> originate {ignore_early_media=true,park_timeout=60,api_hangup_hook='perl
>>> /root/a.pl'}freetdm/grp1/a/9843171457 &park()
>>>
>>> Once this call is also answered, I said "uuid_bridge <uuid1> <uuid2>".
>>> Both call gets bridged. After some time, I hangup the second call
>>> (9843171457). Now the first call goes into park().
>>>
>>> I expect that the first call will hangup after 60 seconds, but it didn't.
>>>
>>> The freeswitch log is here
>>> http://pastebin.freeswitch.org/15099
>>>
>>> When I start to use the park_timeout, I thought once a leg is in park,
>>> then the timer will start, and once it is unparked for various reason the
>>> timer will be reseted. After sometime, when the leg again comes in park, the
>>> timer will start. Is this correct?
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110125/47a9b551/attachment.html 