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@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@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@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@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