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@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@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@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@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