[Freeswitch-users] Method to force a transfer of A-Leg

Tue May 4 12:53:18 PDT 2010

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).

(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... :-)

On Tue, May 4, 2010 at 3:40 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> Could you just collect the digits from the user in the ivr, transfer him
> back to the conference.
> then originate the call separately with the collected digits to enter the
> conference once it answers?
>
>
> On Tue, May 4, 2010 at 1:55 PM, Steven Ward <steve.d.ward at gmail.com>wrote:
>
>> Sorry I haven't provided feedback any sooner...
>>
>> 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.
>>
>> I hope these details make things a bit more clear.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Incidentally, I do see that FS keeps track of the "zombie" channel in the
>> a-leg's *att_xfer_kill_uuid* channel variable.
>>
>> 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.
>>
>> 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?
>>
>> 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.)
>>
>> So, any thoughts on controlling the Polycom attended-transfer-turned-blind
>> :) would be much appreciated.
>>
>> 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.
>>
>> 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...
>>
>> - Steve
>> (sward_)
>> steve.d.ward at gmail.com
>>
>>
>> On Sat, Apr 24, 2010 at 2:47 PM, Michael Jerris <mike at jerris.com> wrote:
>>
>>> just uuid_transfer the a leg.
>>>
>>> On Apr 21, 2010, at 10:09 AM, Steven Ward wrote:
>>>
>>> Hello all,
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> I know there may be many possibilities here; I'm just wondering if anyone
>>> can recommend something.  Thanks.
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
>
> _______________________________________________
> 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/20100504/a227747e/attachment-0001.html 