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

[Steven Ward]

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