I do believe that there are some legit cases where att_xfer is an application that needs to be fully functional. The most obvious case is where analog phone are used with boards such as Sangoma, Khomp or Digium boards. It is in this instance arguable if that needs to be implemented as an application on the "core" so to speak on or the endpoint module. It is not a trivial task (at least beyond my capabilities) to make some extra things work on att_xfer such as call return. Nonetheless, Emrah, what you are asking is doable with the current implementation. Just use the loopback channel and make loopback_bowout=false. The downside in this case is that the loopback channel will be up during the entire duration of the call, but everything else will work. Also, this adds some extra complexity to CDR processing, but I haven't worked on that to really know how much complexity. I hope this works for you. Regards, João Mesquita On Thu, Sep 6, 2012 at 12:46 PM, Emrah <lists@kavun.ch> wrote:

Hi Michael,

It was great to hear you as well, will try to be a regular. :)

I use a Polycom and it does have all the capabilities I need, but I wanted to have the PBX side working for a couple of scenarios where I thought I might need it. E.g.: pick up a call on your cellphone, walk into the office, att_xfer the call from your cell to your desk and continue the conversation. The reason of using att_xfer is to make sure to release the call when the line is properly established and prevent calls from landing in voicemail inadvertently.

And on a final note, I never had any issue transferring calls from my SIP phones, but for some reason I find the Polycom way somewhat cumbersome and repelling.

Best, Emrah On Sep 6, 2012, at 11:23 AM, Michael Collins <msc@freeswitch.org> wrote:

...

What kind of phone are you using? The reason I ask is that most desk phones have real transfer keys that do all of this. If you're stuck using something like x-lite then yeah, I can see the dilemma. In all honesty, the att_xfer app wasn't designed as the be all end all of call transfers. If you are in a scenario where your only option is to use att_xfer then I recommend solving that problem. In the long run it will be much better for you.

-MC

P.S. - It was nice having you on the conf call yesterday! Hope you can join more calls. :)

On Thu, Sep 6, 2012 at 7:38 AM, Emrah <lists@kavun.ch> wrote: Hi guys,

I just briefly tried the att_xfer app and it seems very limited to me. It seems to be either using a gateway or the db, but it never hits the dialplan at any point. I love the extra add-ons you guys built, especially the option to conference before finalizing the transfer, but I think the app should be revised at some point to support a more dialplan oriented approach. Now, when a call comes in, I can att_xfer to a SIP user, but can't call out a cellphone using my dialplan logic with my multiple outbound providers.

I encourage you to give it a look and see if it's worth an upgrade.

Best as always, Emrah _________________________________________________________________________ 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

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

-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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

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

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

Dear Anthony, You're message did not come across very pleasantly, but as it is often the case in writing, sometimes the receiver does not perceive things as they were meant originally. I'll disregard the judgmental portion of your email. When you refer to the application as a whole, should I assume FreeSWITCH or ATT_XFER? When you mean thinking outside the box, am I to assume creating work arounds (e.g.: by using loopback calls?) I don't find that quite sexy to be honest. My previous message never demanded or even asked for an upgrade of a functionality. I stated my thoughts and encouraged the developers to consider my approach and see whether it was worth a revision. I obviously did not mean to attack your work in any way. So here are my 2 cents: The att_xfer feature has been implemented for a certain reason. I've seen it working differently on Asterisk where the dialplan is used all the time. Based on that, and as a personal thought worth mentioning, I suggested a similar approach. Leaving the feature as it is, and based on the limited knowledge I currently have on FreeSWITCH, it makes it unusable in any of my use cases. I divorced my Asterisk boxes and made a commitment to FS. You've built something amazing and I will always try to be constructive where I can. Best to you Anthony, and again congrats for the super initiative you took by creating FS. Emrah On Sep 6, 2012, at 3:23 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

Emrah,

I suggest you further study the application as a whole before making determinations on where improvements need to be made. You may need to think a bit more "out of the box" if you want to be successful.

On Thu, Sep 6, 2012 at 2:03 PM, João Mesquita <jmesquita@freeswitch.org> wrote: I do believe that there are some legit cases where att_xfer is an application that needs to be fully functional. The most obvious case is where analog phone are used with boards such as Sangoma, Khomp or Digium boards. It is in this instance arguable if that needs to be implemented as an application on the "core" so to speak on or the endpoint module.

It is not a trivial task (at least beyond my capabilities) to make some extra things work on att_xfer such as call return.

Nonetheless, Emrah, what you are asking is doable with the current implementation. Just use the loopback channel and make loopback_bowout=false. The downside in this case is that the loopback channel will be up during the entire duration of the call, but everything else will work.

Also, this adds some extra complexity to CDR processing, but I haven't worked on that to really know how much complexity.

I hope this works for you.

Regards, João Mesquita

On Thu, Sep 6, 2012 at 12:46 PM, Emrah <lists@kavun.ch> wrote: Hi Michael,

It was great to hear you as well, will try to be a regular. :)

I use a Polycom and it does have all the capabilities I need, but I wanted to have the PBX side working for a couple of scenarios where I thought I might need it. E.g.: pick up a call on your cellphone, walk into the office, att_xfer the call from your cell to your desk and continue the conversation. The reason of using att_xfer is to make sure to release the call when the line is properly established and prevent calls from landing in voicemail inadvertently.

And on a final note, I never had any issue transferring calls from my SIP phones, but for some reason I find the Polycom way somewhat cumbersome and repelling.

Best, Emrah On Sep 6, 2012, at 11:23 AM, Michael Collins <msc@freeswitch.org> wrote:

...

What kind of phone are you using? The reason I ask is that most desk phones have real transfer keys that do all of this. If you're stuck using something like x-lite then yeah, I can see the dilemma. In all honesty, the att_xfer app wasn't designed as the be all end all of call transfers. If you are in a scenario where your only option is to use att_xfer then I recommend solving that problem. In the long run it will be much better for you.

-MC

P.S. - It was nice having you on the conf call yesterday! Hope you can join more calls. :)

On Thu, Sep 6, 2012 at 7:38 AM, Emrah <lists@kavun.ch> wrote: Hi guys,

I just briefly tried the att_xfer app and it seems very limited to me. It seems to be either using a gateway or the db, but it never hits the dialplan at any point. I love the extra add-ons you guys built, especially the option to conference before finalizing the transfer, but I think the app should be revised at some point to support a more dialplan oriented approach. Now, when a call comes in, I can att_xfer to a SIP user, but can't call out a cellphone using my dialplan logic with my multiple outbound providers.

I encourage you to give it a look and see if it's worth an upgrade.

Best as always, Emrah _________________________________________________________________________ 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

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

-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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

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

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

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

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

Got it, and I appreciate that you took the time to get back to me. I agree with all your points and things make more sense now. Will keep on working my teeth on my FS box. You got a beer from me next time you swing by NYC! Cheers, Emrah On Sep 6, 2012, at 7:36 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

On Thu, Sep 6, 2012 at 3:09 PM, Emrah <lists@kavun.ch> wrote: Dear Anthony,

You're message did not come across very pleasantly, but as it is often the case in writing, sometimes the receiver does not perceive things as they were meant originally. I'll disregard the judgmental portion of your email.

I can see you might have considered what I said judgmental however its purely an observation. Had you contended that we must design ships to deal with the possibility of plummeting from the earth when they reached the edge and I suggested you study the world geography it would not be judgmental but rather an observation that you should learn more before making a suggestion. We do not mind criticism because feedback is the cornerstone of open source software. We just need to channel it to the right place and in this case its not helpful.

When you refer to the application as a whole, should I assume FreeSWITCH or ATT_XFER? When you mean thinking outside the box, am I to assume creating work arounds (e.g.: by using loopback calls?) I don't find that quite sexy to be honest.

I am referring to the application as a whole. att_xfer is one small app designed as a last resort for some specific situations. Your suggestion to engineer it differently is similar to saying you want your TV set to play movies some other way than by connecting it to a source of video. It suggests you need to study it closer to understand properly. The dialplan is something that happens when a call goes to the ROUTING state and collects a list of applications to execute. Some of these applications can execute more applications on top of each other such as running att_xfer from digit action while already in the EXECUTE state during a call bridge.

Now in this case you want to dial another new channel and bridge to it then subsequently either bridge it with the channel you are currently putting on hold or end the call and go back to the original call. So this concept of needing a new channel is basically a given and is absolute.

So, you want to be able to make a call based on your dial-plan logic? Right, so, If this call lead to another box it would be a given, you call it on sip or pstn etc, but since its on the same box its sort of a catch-22.

Ok so there is a loopback channel which is basically allowing you to call an extension on your own box in the context of a new channel so you can properly transfer it etc. The same thing can also be achieved by calling the extension over SIP in a loop back to your own box either way the point is you need to have another channel so you actually have something that can continue on its own when you decide to bridge it to the other leg. I can assure you I had no intention of making it sexy when I made the loopback module but I do often wish I never wrote it but then again it does solve a particular set of problems.

My previous message never demanded or even asked for an upgrade of a functionality. I stated my thoughts and encouraged the developers to consider my approach and see whether it was worth a revision. I obviously did not mean to attack your work in any way.

I never assumed that to be the case. Fret not.

So here are my 2 cents: The att_xfer feature has been implemented for a certain reason. I've seen it working differently on Asterisk where the dialplan is used all the time. Based on that, and as a personal thought worth mentioning, I suggested a similar approach. Leaving the feature as it is, and based on the limited knowledge I currently have on FreeSWITCH, it makes it unusable in any of my use cases.

You are probably not aware but I personally implemented that original feature in Asterisk "atxfer" in res_features and I can tell you that trying to get it to work and how horrible it was to get working on the inside was much more horrendous and as far from sexy as you can imagine even compared to your distain for loopback channel.

Oh yeah, what we call loopback in Asterisk is called chan_local (you may recall the Local/1234 type dial strings) and I can assure you that is the exact method it uses to make it possible to dial right to extensions for all the same rationale.

I divorced my Asterisk boxes and made a commitment to FS. You've built something amazing and I will always try to be constructive where I can.

Best to you Anthony, and again congrats for the super initiative you took by creating FS.

Thank you. I again encourage you to continue to study how things work so you can get the most out of your usage of our software and feel free to post any questions or comments you may have.

Emrah

On Sep 6, 2012, at 3:23 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

...

Emrah,

I suggest you further study the application as a whole before making determinations on where improvements need to be made. You may need to think a bit more "out of the box" if you want to be successful.

On Thu, Sep 6, 2012 at 2:03 PM, João Mesquita <jmesquita@freeswitch.org> wrote: I do believe that there are some legit cases where att_xfer is an application that needs to be fully functional. The most obvious case is where analog phone are used with boards such as Sangoma, Khomp or Digium boards. It is in this instance arguable if that needs to be implemented as an application on the "core" so to speak on or the endpoint module.

It is not a trivial task (at least beyond my capabilities) to make some extra things work on att_xfer such as call return.

Nonetheless, Emrah, what you are asking is doable with the current implementation. Just use the loopback channel and make loopback_bowout=false. The downside in this case is that the loopback channel will be up during the entire duration of the call, but everything else will work.

Also, this adds some extra complexity to CDR processing, but I haven't worked on that to really know how much complexity.

I hope this works for you.

Regards, João Mesquita

On Thu, Sep 6, 2012 at 12:46 PM, Emrah <lists@kavun.ch> wrote: Hi Michael,

It was great to hear you as well, will try to be a regular. :)

I use a Polycom and it does have all the capabilities I need, but I wanted to have the PBX side working for a couple of scenarios where I thought I might need it. E.g.: pick up a call on your cellphone, walk into the office, att_xfer the call from your cell to your desk and continue the conversation. The reason of using att_xfer is to make sure to release the call when the line is properly established and prevent calls from landing in voicemail inadvertently.

And on a final note, I never had any issue transferring calls from my SIP phones, but for some reason I find the Polycom way somewhat cumbersome and repelling.

Best, Emrah On Sep 6, 2012, at 11:23 AM, Michael Collins <msc@freeswitch.org> wrote:

...

What kind of phone are you using? The reason I ask is that most desk phones have real transfer keys that do all of this. If you're stuck using something like x-lite then yeah, I can see the dilemma. In all honesty, the att_xfer app wasn't designed as the be all end all of call transfers. If you are in a scenario where your only option is to use att_xfer then I recommend solving that problem. In the long run it will be much better for you.

-MC

P.S. - It was nice having you on the conf call yesterday! Hope you can join more calls. :)

On Thu, Sep 6, 2012 at 7:38 AM, Emrah <lists@kavun.ch> wrote: Hi guys,

I just briefly tried the att_xfer app and it seems very limited to me. It seems to be either using a gateway or the db, but it never hits the dialplan at any point. I love the extra add-ons you guys built, especially the option to conference before finalizing the transfer, but I think the app should be revised at some point to support a more dialplan oriented approach. Now, when a call comes in, I can att_xfer to a SIP user, but can't call out a cellphone using my dialplan logic with my multiple outbound providers.

I encourage you to give it a look and see if it's worth an upgrade.

Best as always, Emrah _________________________________________________________________________ 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

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

-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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

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

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

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

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

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

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