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
Why do you need to use loopback at all? -MC On Fri, Jun 1, 2012 at 3:17 AM, Alex Lake <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
... 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> 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> 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 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
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> 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>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> 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
... 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> 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> 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>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> 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 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
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> 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>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> 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>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> 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
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? -Avi On Mon, Jun 4, 2012 at 12:02 AM, Michael Collins <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> 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>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> 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>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>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 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
On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus <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>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> 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>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> 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>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>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 >
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>
On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus <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>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> 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>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> 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>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>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 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
-- Best regards, Dmitry Sytchev, IT Engineer
Comments inline... On Mon, Jun 4, 2012 at 7:53 AM, Dmitry Sytchev <kbdfck@gmail.com> 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.
Maybe there's a more elegant way to do this. 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.
This makes me wonder if att_xfer is the right tool.
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.
Please do. I get the feeling that we (the community attempting to help) have just enough information to be frustrated. I suspect that if we knew the big picture we could probably offer some more useful suggestions. -MC
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 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
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> 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>
On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus <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> 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> 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> 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> 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> > 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> >> 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 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
-- Best regards,
Dmitry Sytchev, IT Engineer
_________________________________________________________________________ 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
_________________________________________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
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> 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>
On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus<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> 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> 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> 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> 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> >> 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> >>> 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 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
-- Best regards,
Dmitry Sytchev, IT Engineer
_________________________________________________________________________ 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
_________________________________________________________________________ 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
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> 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> 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>
On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus<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> 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> 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
> 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> 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> >>> 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> >>>> 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 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
-- Best regards,
Dmitry Sytchev, IT Engineer
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
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
_________________________________________________________________________ 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
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
Sign up for an account on the Wiki at wiki.freeswitch.org and go from there. Brian Foster Endigo Computer LLC Sent from a mobile device. On Jun 5, 2012 4:00 PM, "Jeremy Childs" <jeremyc@ssimicro.com> wrote:
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>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> 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>
On Sun, Jun 3, 2012 at 2:15 PM, Avi Marcus<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> 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> 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> >> 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> 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> >>>> 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> >>>>> 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 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
-- Best regards,
Dmitry Sytchev, IT Engineer
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
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
_________________________________________________________________________ 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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ 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
participants (7)
-
Alex Lake
-
Anthony Minessale
-
Avi Marcus
-
Brian Foster
-
Dmitry Sytchev
-
Jeremy Childs
-
Michael Collins