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

[Anthony Minessale]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100504/5123c0c8/attachment.html