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

Wed May 5 07:33:07 PDT 2010

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.

Most of the time it works just fine.  But sometimes the deflected call
dies.

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.

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

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.

Like I said, most of the time this works, so FS sends Session Progress and
eventually an OK for that INVITE.

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

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:
      * when the deflected call does get answered successfully, I see the
messages:

[DEBUG] sofia.c:5831 IP 10.244.16.26 Approved by acl "domains[]". Access
Granted.
[NOTICE] switch_channel.c:675 New Channel
sofia/internal/25327 at 10.244.16.23[82e4521a-5848-11df-b467-cd6b5075e2a0]

   (above, 10.244.16.26 is the IP of the SIP router for device Phone A)

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

I'm on what was latest git pull as of yesterday morning.  Is this something
where I should pastebin the logs and sip traces?

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.

Thanks again for the help.  Any feedback is much appreciated.

On Tue, May 4, 2010 at 12:53 PM, Steven Ward <steve.d.ward at gmail.com> wrote:

> 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/20100505/c6bff06f/attachment.html 