[Freeswitch-users] att_xfer limitations

Fri Sep 7 03:36:53 MSD 2012

On Thu, Sep 6, 2012 at 3:09 PM, Emrah <lists at 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 at 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 at 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 at 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 at 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 at 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 at freeswitch.org
> > > http://www.freeswitchsolutions.com
> > >
> > > 
> > > 
> > >
> > > Official FreeSWITCH Sites
> > > http://www.freeswitch.org
> > > http://wiki.freeswitch.org
> > > http://www.cluecon.com
> > >
> > > 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
> > >
> > >
> > >
> > > --
> > > Michael S Collins
> > > Twitter: @mercutioviz
> > > http://www.FreeSWITCH.org
> > > http://www.ClueCon.com
> > > http://www.OSTAG.org
> > >
> > >
> > >
> _________________________________________________________________________
> > > Professional FreeSWITCH Consulting Services:
> > > consulting at freeswitch.org
> > > http://www.freeswitchsolutions.com
> > >
> > > 
> > > 
> > >
> > > Official FreeSWITCH Sites
> > > http://www.freeswitch.org
> > > http://wiki.freeswitch.org
> > > http://www.cluecon.com
> > >
> > > 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
> >
> >
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > 
> > 
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > 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
> >
> >
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > 
> > 
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > 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
> >
> >
> >
> >
> > --
> > Anthony Minessale II
> >
> > FreeSWITCH http://www.freeswitch.org/
> > ClueCon http://www.cluecon.com/
> > Twitter: http://twitter.com/FreeSWITCH_wire
> >
> > AIM: anthm
> > MSN:anthony_minessale at hotmail.com
> > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> > IRC: irc.freenode.net #freeswitch
> >
> > FreeSWITCH Developer Conference
> > sip:888 at conference.freeswitch.org
> > googletalk:conf+888 at conference.freeswitch.org
> > pstn:+19193869900
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > 
> > 
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > 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
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120906/390d3333/attachment-0001.html 