So the way I've tried interrupting a transfer of the type described in this thread is by using uuid_deflect, but I have a strange problem with that.<br><br>Most of the time it works just fine. But sometimes the deflected call dies. <br>
<br>I've done sip traces and looked at the log, but it's a bit baffling to me why it doesn't work all the time.<br><br>From a lua script, I do a uuid_deflect on the a-leg to sip:[MyNewDestinationURI], where MyNewDestinationURI gets routed to a different destination on my FS box.<br>
<br>So when I do the uuid_deflect, I see the a-leg's device (let's call that Phone A) get the REFER, the a-leg hangs up, and a new call comes back into FS from device Phone A to the new destination.<br><br>Like I said, most of the time this works, so FS sends Session Progress and eventually an OK for that INVITE.<br>
<br>But sometimes FS simply sends a BYE and a 486 Busy Here in response to the INVITE. (The cause for the BYE is "BLIND_TRANSFER"). <br><br>Doing a diff on the logs for when the uuid_deflect works and when it doesn't work, the only difference I see is as follows:<br>
* when the deflected call does get answered successfully, I see the messages:<br><br>[DEBUG] sofia.c:5831 IP 10.244.16.26 Approved by acl "domains[]". Access Granted.<br>[NOTICE] switch_channel.c:675 New Channel sofia/internal/<a href="mailto:25327@10.244.16.23">25327@10.244.16.23</a> [82e4521a-5848-11df-b467-cd6b5075e2a0]<br>
<br> (above, 10.244.16.26 is the IP of the SIP router for device Phone A) <br> <br> * when the deflected call does NOT get answered, but is sent a BYE and Busy Here, I notice the above messages do NOT appear in the log at all.<br>
<br>I'm on what was latest git pull as of yesterday morning. Is this something where I should pastebin the logs and sip traces?<br><br>And the Busy Here seems to strange to me, because the endpoint on FS it's getting sent to is dialplan that does a 'fifo in' - and no one else is calling to execute that dialplan when I ran these tests, so it's not really busy as far as I understand.<br>
<br>Thanks again for the help. Any feedback is much appreciated.<br><br><br><br><br><br><div class="gmail_quote">
On Tue, May 4, 2010 at 12:53 PM, Steven Ward <span dir="ltr"><<a href="mailto:steve.d.ward@gmail.com" target="_blank">steve.d.ward@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
At the moment, I'm not using an ivr. The transfer is done by the phone (so when I hit the Transfer button, the phone puts a-leg on hold and I dial a new call; I hit the Transfer button again and the Polycom does the REFER w/ REPLACES and hangs up on a-leg and the new destination).<br>
<br>(Makes me wish the phone didn't come with its own built-in Transfer feature with accompanying button and I could have FS handle everything... :-)<div><div></div><div><br><br><div class="gmail_quote">On Tue, May 4, 2010 at 3:40 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Could you just collect the digits from the user in the ivr, transfer him back to the conference.<div>
then originate the call separately with the collected digits to enter the conference once it answers?</div><div><br></div>
<div><div><div></div><div><br><div class="gmail_quote">On Tue, May 4, 2010 at 1:55 PM, Steven Ward <span dir="ltr"><<a href="mailto:steve.d.ward@gmail.com" target="_blank">steve.d.ward@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Sorry I haven't provided feedback any sooner...<br><br>I've been looking at uuid_transfer and uuid_deflect, and I'm still having a tough time getting the desired effect for my situation. <br><br>I hope these details make things a bit more clear.<br>
<br>The thing is, this script is monitoring transfers that are done by a Polycom; the transfer starts as attended, but then is converted to a blind xfer (so the xfer is ringing, and I hit the Transfer button again to exit out of the transfer). So the Polycom sends a REFER to the a-leg w/ a REPLACES param.<br>
<br>My script then turns on, sleeps for a bit, and then checks out the a-leg. If the a-leg hasn't been answered, I'd like the script to cancel that transfer and move the leg somewhere else on the box.<br><br>The thing is, the a-leg isn't bridged yet because it hasn't been answered (destination does not even send early media). And the a-leg doesn't even know in its channel variables what channel it's trying to ring, because of the way the transfer works. The a-leg is just waiting for the transfer to complete. As Tony graciously described to me on irc one time, until the destination answers (or sends early media), the channel that dialed out to do the transfer remains up in a zombified state. And once the destination answers, then the zombified channel drops out and the a-leg is bridged to the destination.<br>
<br>Incidentally, I do see that FS keeps track of the "zombie" channel in the a-leg's <b>att_xfer_kill_uuid</b> channel variable.<br><br>The impact of this to what I'm trying to do is that uuid_transfer doesn't work for taking over the call. I can uuid_transfer the a-leg, but the original destination of the transfer keeps ringing and the att_xfer_kill_uuid channel stays up. So now it's as if the a-leg is ringing two destinations, and the original destination never stops ringing. <br>
<br>Is there any way I can find out what channel the a-leg is trying to get connected to via att_xfer_kill_uuid? Or is there any way I can truly cancel that attended xfer and take control of the a-leg?<br><br>I see that uuid_deflect can be used to send a REFER and send it off-box, but I'd like to simply send the a-leg through dialplan on-box. (And when I've tried using uuid_deflect to REFER it back to another destination on my same box, I *sometimes* get a busy for a reason I haven't been able to debug yet.)<br>
<br>So, any thoughts on controlling the Polycom attended-transfer-turned-blind :) would be much appreciated.<br><br>This is for an application that replicates the features of an operator console that is currently in use - that's why I need to control calls so maniacally. Once I get this polished off, I look forward to putting the final results onto the wiki as an example application. <br>
<br>Thanks again for all the help I've already received on irc and the list in the past, and thanks for any comments on this scenario...<br><br>- Steve <br>(sward_)<br><a href="mailto:steve.d.ward@gmail.com" target="_blank">steve.d.ward@gmail.com</a><br>
<br><br><div class="gmail_quote"><div><div></div><div>On Sat, Apr 24, 2010 at 2:47 PM, Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.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>
<div style="word-wrap: break-word;">just uuid_transfer the a leg.<div><div></div><div><div><br><div><div>On Apr 21, 2010, at 10:09 AM, Steven Ward wrote:</div><br><blockquote type="cite">Hello all,<br><br>I have a lua script running that checks the state of a call between A and B - the call between A and B was set up through a Polycom's attended transfer feature, so A itself didn't necessarily execute the bridge to B.<br>
<br>A gets early media from B. After a certain amount of time, if A is still getting early media, I want the script to end that call between A and B, and send A through some specific dialplan.<br><br>How does uuid_transfer work for this goal? I'd like to kill B and move A to specific dialplan. I don't want B to be in the transfer at all.<br>
<br>I know there may be many possibilities here; I'm just wondering if anyone can recommend something. Thanks.<font color="#000000"><font color="#144fae"><br></font></font></blockquote></div></div></div></div></div>
<br></div></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></div></blockquote></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><br clear="all"><br></div></div>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<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><br>
</div></div></blockquote></div><br>