[Freeswitch-users] att_xfer and loopback

Tue Jun 5 23:44:29 MSD 2012

Updated to the latest git, so I can verify:

{ignore_early_media=ring_ready,loopback_bowout_on_execute=true}loopback/foo

does the right thing

{ignore_early_media=ring_ready}loopback/foo

Bridges all 3 legs together immediately (not the right thing).

On 12-06-04 11:03 AM, Anthony Minessale wrote:
> This thread is all FUD now, please disregard above.
>
>
> att_xfer and loopback endpoint are both crutches but they work at the
> cost of elegance since you are doing emulated behaviors.
>
> Your problem probably comes from the loopback bow-out happening too
> soon that tries to cut its way out of the call..
>
> You should be looking at logs and finding the root of the problem not
> guessing at things.
>
> My recommendation:
>
> 1) Make sure you are on latest GIT we have fixed a few issues in both
> in the recent past.
> 2) try {ignore_early_media=ring_ready,loopback_bowout_on_execute=true}loopback/foo
> in your dialstring  --- This may eliminate the loopback right off the
> bat.
> 3) try {ignore_early_media=ring_ready}}loopback/foo ---- it may just
> need to wait for the call to be answered.
> 4) try {loopback_bowout=false}loopback/foo --- the bummer here is it
> will never eliminate loopback
>
>
> On Mon, Jun 4, 2012 at 10:57 AM, Jeremy Childs<jeremyc at ssimicro.com>  wrote:
>> I'm also very interested in some answers! I've been bitten by att_xfer in
>> the past.
>>
>> Is getting dialplan processing working within the att_xfer function
>> possible, and just a low priority for implementation, or is there some
>> technical reason why this is not feasible?
>>
>> Lastly, is this somewhere that execute_extension can help? I've never been
>> able to get it to work inside att_xfer.
>>
>>
>>
>> On 12-06-04 8:53 AM, Dmitry Sytchev wrote:
>>
>> I asked this question many times on mailing list, and now I'm sure this
>> can't be really done with loopback.
>> The only alternative for loopback is to re-inject call into FS via some
>> separate Sofia profile, and specify that profile in string for att_xfer.
>> This brings up large amount of troubles including DTMF transcoding,
>> sequential att_xfer attempt recognition and overall voice/dtmf delay
>> introduced by chained channels. Maybe some channels can be moved out of
>> scene by using 'simplify' api on correct channels, but this needs tests.
>>
>> Anyway, loopback channel in FS is completely unusable, so we do need to have
>> some  best practices on how to do things without it in FS wiki... Maybe I
>> have time and will describe our experience soon.
>>
>> 2012/6/4 Michael Collins<msc at freeswitch.org>
>>>
>>>
>>> On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus<avi at avimarcus.net>  wrote:
>>>> I know you can do anything in the dialstring. But intended feature is to
>>>> allow the user to do an attended transfer to any number that they could
>>>> reach via the default calling. The default outbound path already has a LOT
>>>> of stuff set up and it would be impossible to duplicate that within a SINGLE
>>>> dialstring in a function call.
>>>> What is needed is for an att_xfer to be able to have leg C hit the
>>>> dialplan and bridged however a "normal" leg B to that number would be
>>>> called.
>>>> Does this make sense?
>>> Perhaps, but I remain unconvinced that this scenario is impossible without
>>> loopback. How about the OP actually supply a sample Lua script and dialplan
>>> and call log? I'd be willing to wager that the gurus could come up with a
>>> non-evil alternative that actually works. Just because loopback seems like a
>>> clean solution doesn't necessarily mean that it is. I'll leave it to Anthony
>>> to give the technical reasons why loopback doesn't always work as one would
>>> expect or why it should be avoided wherever possible.
>>>
>>> -MC
>>>
>>>> -Avi
>>>>
>>>>
>>>>
>>>> On Mon, Jun 4, 2012 at 12:02 AM, Michael Collins<msc at freeswitch.org>
>>>> wrote:
>>>>> Au contraire mon frere!
>>>>>
>>>>> You can do multiple things in a dialstring, like setting channel
>>>>> variables. You can also use execute_on_ring/media/answer to execute the
>>>>> extension with doing all the loopback overhead.
>>>>>
>>>>> I propose an experiment: provide a dialplan and loopback dialstring and
>>>>> we'll see if we can't give you a non-loopbackish alternative.
>>>>>
>>>>> -MC
>>>>>
>>>>>
>>>>> On Sun, Jun 3, 2012 at 1:54 PM, Avi Marcus<avi at avimarcus.net>  wrote:
>>>>>> ... all the normal dialplan handling. Setting CID, options, LCR stuff,
>>>>>> billing controls.
>>>>>> -Avi
>>>>>>
>>>>>>
>>>>>> On Sun, Jun 3, 2012 at 11:40 PM, Michael Collins<msc at freeswitch.org>
>>>>>> wrote:
>>>>>>> Let me rephrase...
>>>>>>>
>>>>>>> Since loopback is generally evil and should be avoided wherever
>>>>>>> possible, what does loopback give you that you can't get from doing a normal
>>>>>>> dialstring?
>>>>>>> -MC
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jun 2, 2012 at 11:13 AM, Avi Marcus<avi at avimarcus.net>  wrote:
>>>>>>>> ... because att_xfer seems to require a "sofia/$profile/$destination"
>>>>>>>> directive, and he just wants the call to hit the dialplan.
>>>>>>>>
>>>>>>>> -Avi
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jun 1, 2012 at 8:13 PM, Michael Collins<msc at freeswitch.org>
>>>>>>>> wrote:
>>>>>>>>> Why do you need to use loopback at all?
>>>>>>>>> -MC
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jun 1, 2012 at 3:17 AM, Alex Lake<alex at digitalmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Got a lua script for a B-party "mid-call menu". Is it legitimate to
>>>>>>>>>> do..
>>>>>>>>>> "session:execute("att_xfer", "loopback/"..destnum)"
>>>>>>>>>>
>>>>>>>>>> I've tried it and it seems to start off doing the right things, but
>>>>>>>>>> my
>>>>>>>>>> A-party gets disconnected as soon as the call to the C-Party (the
>>>>>>>>>> person
>>>>>>>>>> I'm transferring the call to) answers the call.
>>>>>>>>>>
>>>>>>>>>> Maybe better to try to orchestrate the entire affair from within
>>>>>>>>>> the lua
>>>>>>>>>> script? (Tricky for a beginner like me!)
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> Join Us At ClueCon - Aug 7-9, 2012
>>>
>>> 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
>>>
>>
>>
>> --
>> Best regards,
>>
>> Dmitry Sytchev,
>> IT Engineer
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> Join Us At ClueCon - Aug 7-9, 2012
>>
>> 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
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> Join Us At ClueCon - Aug 7-9, 2012
>>
>> 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
>>
>
>