Yep, I just made a test with the default dialplan and when you do this on the CLI:<div><br></div><div>uuid_transfer <uuid> execute_extension:att_xfer\sXML\sfeatures inline</div><div><br></div><div>the leg to be transfered is lost because you att_xfer can't clear the CF_INNER_BRIDGE on the leg, which, by the looks of the bridge code, will park the leg for you...</div>
<div><br></div><div>I am not a very experienced programmer, but that's what it looks like to be happening. Maybe an API command for att_xfer would make most ppl life's easier? It seems to be basically the same function as the application but instead of using the signal_bond variable, we could use a var provided on the command line? Anyone?</div>
<div><br></div><div>The other option is to do what Edwin said, do it all "by hand".</div><div><br></div><div>Regards,<br clear="all">Joćo Mesquita<br>
<br><br><div class="gmail_quote">2011/1/21 Joćo Mesquita <span dir="ltr"><<a href="mailto:jmesquita@freeswitch.org">jmesquita@freeswitch.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Actually, Fraser, I think this won't work...<div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>Joćo Mesquita<div><div></div><div class="h5"><br>
<br><br><div class="gmail_quote">On Fri, Jan 21, 2011 at 1:37 AM, Fraser Redmond <span dir="ltr"><<a href="mailto:fraserredmond@gmail.com" target="_blank">fraserredmond@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks Joćo.<br><br>My transfer_call extension runs a couple of js scripts to get and validate the number to transfer to, then does<br> <action application="att_xfer" data="${dial_string}"/><br>
(and it has a couple of steps after that to handle failed transfers.)<br><br>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.<br>
<br><br>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.<br><br>Cheers,<br>Fraser<br>
<br>
<br>
<br><br><div class="gmail_quote">2011/1/20 Joćo Mesquita <span dir="ltr"><<a href="mailto:jmesquita@freeswitch.org" target="_blank">jmesquita@freeswitch.org</a>></span><div><div></div><div><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Lucky for you I have been working on this lately and the bad news is ... there's no easy way to do it....<div><br></div><div>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:</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>You can always execute att_xfer using ESL's execute (<a href="http://wiki.freeswitch.org/wiki/Event_Socket_Library#execute" target="_blank">http://wiki.freeswitch.org/wiki/Event_Socket_Library#execute</a>) 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...</div>
<div><br></div><div>Regards,</div><div>Joćo Mesquita<br>
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jan 21, 2011 at 12:13 AM, Fraser Redmond <span dir="ltr"><<a href="mailto:fraserredmond@gmail.com" target="_blank">fraserredmond@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div><div></div><div>
Is there any way to run a dialplan tool from the event socket?<br><br>I have a dialplan that uses a dtmf to set up and perform an attended transfer, like so:<br><action application="bind_meta_app" data="8 a s execute_extension::TransferCall XML transfer_call"/><br>
<br>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.)<br><br>api uuid_transfer Uuid -bleg TransferCall XML transfer_call<br>
<br>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.<br><br>
Or should I be lame and do "api uuid_send_dtmf" to send * 8.<br><br clear="all">Cheers,<br><font color="#888888">Fraser<br><br><br>
</font><br></div></div>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div></div></div><br>
<br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div>