[Freeswitch-users] Is it possible to use att_xfer on channels already bridged via loopback?

[Dmitry Sytchev]

Yes, I'm using SIP as my endpoints.

There are number of reasons why I want to use in-call triggered transfers.

1. We are migrating several large ISP PBX to Freeswitch from Asterisk.
In-call transfers in Asterisk via res_features are mature and stable,
and many users use it - if we remove this feature, we will loose our
users.

2. Not all SIP endpoints support call transfer, and despite majority
of devices support this, we want fine control over who is allowed to
do transfer in which situation - there are many paths of call in our
PBXs.

3. We also need to provide call transfer functionality to external
PSTN users, which are dialed via SIP proxy and then SIP-E1 gateway
like audiocodes or cisco. There is no simple universal solution to
trigger such transfers from PSTN side besides in-call transfers with
bind_meta_app.

I agree, in ideal world we would live without server-side attended
transfers, but for now att_xfer is an ultimate feature of real PBX,
even old Avaya and Samsung boxes support this :)


2011/1/24 João Mesquita <jmesquita at freeswitch.org>:
> I am just now discussing this with another developer and the question that
> is never answered is:
> Why are you trying to use att_xfer if it is your endpoint's duty to make the
> transfer? Are you using SIP?
> Regards,
> João Mesquita
>
>
> On Mon, Jan 24, 2011 at 1:01 PM, Dmitry Sytchev <kbdfck at gmail.com> wrote:
>>
>> Is att_xfer or mod_loopback is broken in FS-current?
>> I use FreeSWITCH Version 1.0.head (git-7eceff4 2011-01-16 22-33-50 +0000)
>> Seems there were no updates of att_xfer or mod_loopback since that.
>>
>> I use loopback channel as destination when doing att_xfer to re-enter
>> dialplan.
>> With loopback_bowout=false and loopback_bowout_on_execute=false this
>> works. But when any of connected parties tries to do att_xfer again,
>> all channels get hangup on transferer hangup.
>>
>> Scenario:
>>
>> A calls B, B answers
>> A launches att_xfer via *7, B listens to MOH
>> A dials C and we do att_xfer to loopback/C
>> C answers, A hangs up to complete transfer
>> C and B are now bridged via loopback, `show channels` shows 4 channels
>> include 2 loopback legs.
>>
>> Now, C also tries to do in-call transfer with *7.
>> C launches att_xfer via *7, B listens to MOH
>> C dials D and do att_xfer to loopback/D
>> D answers, C hangs up to complete transfer
>> B and D are hung up instead of be bridged together.
>>
>> There are also issues with MOH wile running att_xfer, but they are not
>> so important as att_xfer behavior itself.
>>
>>
>>
>> --
>> Best regards,
>>
>> Dmitry Sytchev,
>> IT Engineer
>>
>> _______________________________________________
>> 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
>
>



-- 
Best regards,

Dmitry Sytchev,
IT Engineer