[Freeswitch-users] att_xfer and loopback

[Michael Collins]

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