[Freeswitch-users] Run dialplan tools from event socket

[João Mesquita]

You hit the right spot... That's what you need to do, we don't need an API,
it already exists. I've tested and it works like a charm.

Regards,
João Mesquita


On Fri, Jan 21, 2011 at 10:16 AM, Steven Ayre <steveayre at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/114b5912/attachment-0001.html