[Freeswitch-users] Run dialplan tools from event socket

Sat Jan 22 22:27:00 MSK 2011

Ok, it is oficial now... It "kinda" works with uuid_broadcast ...

When you hangup the channel that initiated the transfer, the peer_channel
gets hungup as well, therefore, no luck with the transfer because all 3
channels get hungup. The rest works fine..

I compared the channel flags from the working and the non-working examples
and I found some interesting things. The failed call lacks the following
flags:

CF_BRIDGED
CF_CONTROLLED
CF_PARK

I am guessing that the important ones that make everything go to hell at the
end is the CF_BRIDGED because apparently, the lack of it means that the
system can let the session go. I don't know what CF_CONTROLLED is and the
lack of CF_PARK really messes up the MOH. You get the channel muted when you
initiate the transfer.

I am investigating more and will let you guys know as I move on.

Regards,
João Mesquita

2011/1/21 Fraser Redmond <fraserredmond at gmail.com>

> Awesome, thanks Steve and João!
>
> (Got called away to work on something else today, but will try it
> tomorrow.)
>
> Cheers,
> Fraser
>
>
>
>
>
> 2011/1/21 João Mesquita <jmesquita at freeswitch.org>
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20110122/4394e087/attachment.html 