I'd love to document this (and more). Can I contact you off-list to work out the details? On 12-06-05 1:54 PM, Michael Collins wrote:
We appreciate the validation. Any chance you could find a place on the wiki to add this hard-earned knowledge? -MC
On Tue, Jun 5, 2012 at 12:44 PM, Jeremy Childs <jeremyc@ssimicro.com <mailto:jeremyc@ssimicro.com>> wrote:
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@ssimicro.com <mailto:jeremyc@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@freeswitch.org <mailto:msc@freeswitch.org>> >>> >>> >>> On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus<avi@avimarcus.net <mailto:avi@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@freeswitch.org <mailto:msc@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@avimarcus.net <mailto:avi@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@freeswitch.org <mailto:msc@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@avimarcus.net <mailto:avi@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@freeswitch.org <mailto:msc@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@digitalmail.com <mailto:alex@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@freeswitch.org <mailto:consulting@freeswitch.org> >>> http://www.freeswitchsolutions.com >>> >>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >>> http://www.cudatel.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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@freeswitch.org <mailto:consulting@freeswitch.org> >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@freeswitch.org <mailto:consulting@freeswitch.org> >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org