[Freeswitch-users] Run dialplan tools from event socket

[Steven Ayre]

uuid_broadcast appears to have support for executing a dialplan app from the
api (it uses say as an example):

uuid_broadcast <uuid> app!::args [aleg|bleg|both]

http://wiki.freeswitch.org/wiki/Mod_commands#uuid_broadcast

I haven't tried it myself though.

-Steve


2011/1/21 João Mesquita <jmesquita at freeswitch.org>

> Actually, Fraser, I think this won't work...
>
> att_xfer uses the signal_bond variable to get the leg connected to the
> party being transferred. This variable is unset when you park the legs or
> break the bridge in any way. Maybe I can make a API command that does
> att_xfer taking the trasferred leg UUID as the transferred party? Do me a
> favor, make some tests and I will take a deeper look at the att_xfer
> application code.
>
> Regards,
> João Mesquita
>
>
>
> On Fri, Jan 21, 2011 at 1:37 AM, Fraser Redmond <fraserredmond at gmail.com>wrote:
>
>> Thanks João.
>>
>> My transfer_call extension runs a couple of js scripts to get and validate
>> the number to transfer to, then does
>>                 <action application="att_xfer" data="${dial_string}"/>
>> (and it has a couple of steps after that to handle failed transfers.)
>>
>> So could I use ESL's execute command to run the execute_extension? Not
>> sure how I missed that option in the wiki. I"ll give it a try, see what
>> happens.
>>
>>
>> I forgot to say in the original post, but execute_extension seems to be
>> particularly nice for this use-case, as it falls back through the dialplan
>> gracefully if there's a problem.
>>
>> Cheers,
>> Fraser
>>
>>
>>
>>
>> 2011/1/20 João Mesquita <jmesquita at freeswitch.org>
>>
>> Lucky for you I have been working on this lately and the bad news is ...
>>> there's no easy way to do it....
>>>
>>> You can execute an extension like you said, but you have to park the legs
>>> first... It would help to know how's the transfer_call extension so that I
>>> can try to help you out, but maybe it is easier if you think of it this way:
>>>
>>> When you use an app like att_xfer, the core already knows what to do next
>>> with a call and parks the legs for you. If you do it on ESL, you've done it
>>> half way and you didn't really park anything before you transfered the call.
>>> When the bridge is undone, the leg that was not transfered doesn't know what
>>> to do, has no applications to be run at this moment and so all it's left for
>>> it is to let go.
>>>
>>> A bit clearer? Att_xfer is a bit of a pain in the butt and it kinda
>>> requires you to know a bit more of the inner workings of the state machine.
>>>
>>> You can always execute att_xfer using ESL's execute (
>>> http://wiki.freeswitch.org/wiki/Event_Socket_Library#execute) if you
>>> don't care what happens to the legs afterwards but if you want to have
>>> control over all 3 legs, no luck for you...
>>>
>>> Regards,
>>> João Mesquita
>>>
>>>
>>> On Fri, Jan 21, 2011 at 12:13 AM, Fraser Redmond <
>>> fraserredmond at gmail.com> wrote:
>>>
>>>> Is there any way to run a dialplan tool from the event socket?
>>>>
>>>> I have a dialplan that uses a dtmf to set up and perform an attended
>>>> transfer, like so:
>>>> <action application="bind_meta_app" data="8 a s
>>>> execute_extension::TransferCall XML transfer_call"/>
>>>>
>>>> But I can't see any way to run the same thing from the event socket. I
>>>> thought doing an  "api uuid_transfer"  might do it, but that hangs up one of
>>>> the legs (no good for attended transfer.)
>>>>
>>>> api uuid_transfer Uuid -bleg TransferCall XML transfer_call
>>>>
>>>> As far as I can see, the closest thing is "sendmsg execute", but it
>>>> looks like you have to park a call/channel first to use that, so I'm not
>>>> sure that that is much use for attended transfer either.
>>>>
>>>> Or should I be lame and do "api uuid_send_dtmf" to send * 8.
>>>>
>>>> Cheers,
>>>> Fraser
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20110121/dc6743db/attachment-0001.html