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

On Mon, Jan 24, 2011 at 12:44 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:

Guess who wrote that code in res_features ;)

Was that another hack done on a whim like mod_yaml? :P -MC

=)) res_features is cool :)) I'll clean out my dialplan and provide it to you tomorrow. How do I authenticate to pastebin? With my Jira account? There is another problem, I'm using mod_spidermonkey/mod_spidermonkey_odbc to get virtual extension from my database, but I'll try to convert it to simple dialplan. BTW, maybe my scripts can be a reason of my troubles? 2011/1/24 Michael Collins <msc@freeswitch.org>:

Dmitry, I'd like to try this myself on one of my boxes. Would you pastebin the dialplan you are using? Thanks, MC

On Mon, Jan 24, 2011 at 8:01 AM, 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

http://pastebin.freeswitch.org/15141 - dialplan features.xml http://pastebin.freeswitch.org/15140 - extraction from main dialplan to only test att_xfers http://pastebin.freeswitch.org/15138 - freeswitch.xml Do you also need my debug logs or any other info? My problem can be reproduced on my hardware with this configuration. There is a problem with MOH also - if first att_xfer fails for any reason, there will be no MOH for transferee on subsequent att_xfer calls, just silence 2011/1/24 Michael Collins <msc@freeswitch.org>:

Dmitry, I'd like to try this myself on one of my boxes. Would you pastebin the dialplan you are using? Thanks, MC

On Mon, Jan 24, 2011 at 8:01 AM, 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

Hi! Any news on this? Did you succeed reproducing our bug? Problem seems to be present in latest git too. Also, if first att_xfer attempt is failed for any reason, when transferer hangs up on subsequent attempts, no transfer is made, all channels are just hungup. 2011/1/25 Brian West <brian@freeswitch.org>:

I couldn't replicate it on mine but i'll try his configs. /b On Jan 25, 2011, at 10:01 AM, Dmitry Sytchev wrote:

http://pastebin.freeswitch.org/15141 - dialplan features.xml http://pastebin.freeswitch.org/15140 - extraction from main dialplan to only test att_xfers http://pastebin.freeswitch.org/15138 - freeswitch.xml

Do you also need my debug logs or any other info? My problem can be reproduced on my hardware with this configuration. There is a problem with MOH also - if first att_xfer fails for any reason, there will be no MOH for transferee on subsequent att_xfer calls, just silence

2011/1/24 Michael Collins <msc@freeswitch.org>:

Dmitry,

I'd like to try this myself on one of my boxes. Would you pastebin the

dialplan you are using?

Thanks,

MC

_______________________________________________ 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