[Freeswitch-users] blind transfer context
François Delawarde
fdelawarde at wirelessmundi.com
Mon Nov 22 05:39:06 PST 2010
It's a very cool feature to be able to force this transfer context, and
there are several options indeed for my scenario. I currently have to
use a lua script that is called "on_answer" and sets the
force_transfer_context to the other leg's context.
I don't argue that it can't be done, but I believe that in most
situations you would want blind transfer and attended transfer to behave
the same way: using the transferer's context. It would be nice to have
that behavior by default.
François.
On Mon, 2010-11-22 at 05:13 -0800, S W wrote:
> Francois,
>
> Thanks for the example in your situation. I think that, to control
> what you want the channel to do on a transfer, still does not need to
> be overly complex.
>
> It looks like you are first bridging to specific endpoints. You have
> various options available to you for setting force_transfer_context on
> the a-leg when the bridge happens (even an using execute_on_answer or
> api_on_answer or whatever). The b-leg that answers can execute the
> appropriate set onto the a-leg (even using uuid_setvar or something
> else). Then, any subsequent transfer would involve the context you
> desire.
>
> - Steve
>
> On Mon, Nov 22, 2010 at 1:23 AM, François Delawarde
> <fdelawarde at wirelessmundi.com> wrote:
> Hi Steve,
>
> Thanks for your view on this. My point was that by default a
> blind
> transfer acts differently from an attended transfer as it uses
> the
> transferee's context instead of the transferer's.
>
> It can in some way be controlled as you mention, but having to
> implement
> something quite complex only to have blind and attended xfers
> behaving
> in the same way seems a bit overkill.
>
>
> For example, if I wish to use the B-leg's context as
> transfer_context
> for the A-leg (as in attended xfers), then when bridging to a
> group it
> can become a bit complicated:
>
> <action application="bridge"
> data="user/100 at example.com,user/101 at example.com,..."/>
>
> In that case, I would have to use a lua script to set the
> force_transfer_context to the B-leg's context on answer
> (because
> beforehand you wouldn't know who is going to take the call),
> so that if
> a transfer happens, it goes in the correct context.
>
> François.
>
>
>
>
>
> On Fri, 2010-11-19 at 15:39 -0500, S W wrote:
> > And here we have a start on the wiki page
> >
> >
> http://wiki.freeswitch.org/wiki/Force_transfer_context_example
> >
> > On Fri, Nov 19, 2010 at 3:34 PM, S W
> <steve.d.ward at gmail.com> wrote:
> > I can go ahead and start a wiki page on this.
> Feedback is
> > welcome.
> >
> > I tried to make a general template-type single code
> file
> > people can use and work with.
> >
> > http://pastebin.freeswitch.org/14560
> >
> >
> >
> >
> >
> > On Fri, Nov 19, 2010 at 2:48 PM, Michael Collins
> > <msc at freeswitch.org> wrote:
> > Could you pastebin your dialplan? I'd like
> to let
> > others try it out. Once it's confirmed we'll
> wikify
> > it.
> > -MC
> >
> >
> >
> > On Fri, Nov 19, 2010 at 9:08 AM, S W
> > <steve.d.ward at gmail.com> wrote:
> > Just as a comment, I have recently
> employed
> > the functionality of
> force_transfer_context,
> > and it is great exactly as it is.
> >
> > In my scenario I need to control how
> the
> > channel RECEIVING a transfer/REFER
> handles
> > that transfer.
> >
> > For example, I never want incoming
> calls to
> > directly access certain call paths
> on my box.
> > But, if a channel receives a REFER
> to off-box
> > destination X, I want to handle that
> (even
> > though my default context for
> incoming calls
> > doesn't allow for destination X).
> >
> > So I have a context that is not
> associated
> > with my SIP profile for incoming
> calls. And
> > that context has routing logic for
> destination
> > X. And I use force_transfer_context
> so that,
> > when a channel is bridged and gets a
> REFER to
> > destination X, the ROUTING state
> sends the
> > channel through my special context
> for
> > handling transfers.
> >
> > It's awesome!!!
> >
> > And just as another note on your
> comment,
> > Francois - a transferer has total
> control over
> > where he transfers another channel
> (e.g. you
> > can use dialplan context and
> extension, etc
> > etc. right in transfer app).
> >
> > These channel vars -
> force_transfer_context
> > and force_transfer_dialplan - allow
> for
> > controlling how a channel reacts to
> getting a
> > transfer/REFER thrown at it.
> >
> > Anyway, just a comment....
> >
> >
> >
> > On Fri, Nov 19, 2010 at 11:45 AM,
> François
> > Delawarde
> <fdelawarde at wirelessmundi.com>
> > wrote:
> > Problem is those variables
> must be set
> > on the channel that has to
> be
> > transfered and not the
> channel that
> > performs the transfer.
> >
> > I thought it would be more
> logical to
> > use the transferer context
> by
> > default (just like in
> attended xfers),
> > and for those variables to
> be set
> > on the transferer's side.
> >
> > François.
> >
> >
> >
> > On Fri, 2010-11-19 at 08:32
> -0600,
> > Brian West wrote:
> > > force_transfer_dialplan
> > > force_transfer_context
> > >
> > >
> > > You can't tell if a
> transfer is
> > blind or attended.
> > >
> > >
> > > /b
> > >
> > > On Nov 19, 2010, at 5:04
> AM,
> > François Delawarde wrote:
> > >
> > > > Hello,
> > > >
> > > > I pastebined a very
> simple
> > configuration for you to
> reproduce:
> > > >
> >
> http://pastebin.freeswitch.org/14552
> > > >
> > > > We have user 100 in
> context
> > "public", 101 and 102 in
> context
> > > > "local".
> > > >
> > > > Scenario:
> > > > 1. 100 calls destination
> "123"
> > > > 2. 101 answers, and
> transfers to
> > 102
> > > >
> > > > In step 2., if 101 does
> an
> > attended transfer, it will
> of course
> > use
> > > > its
> > > > own context (local) and
> the
> > transfer will work. Now if
> 101 does a
> > > > blind
> > > > transfer instead, it
> will use the
> > context of the other leg
> (100 =>
> > > > public) and it will not
> work.
> > > >
> > > > I think it should behave
> the same
> > way for both types of
> transfer by
> > > > default. A workaround is
> to set
> > force_transfer_context
> (uncomment
> > > > the
> > > > line on the "public"
> dialplan) in
> > the channel to be
> transfered,
> > > > which
> > > > can be a pain with more
> complex
> > configurations.
> > > >
> > > > Thanks,
> > > > François.
> > >
> > >
> >
> > >
> >
> _______________________________________________
> > > 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
> >
> >
> >
> >
> _______________________________________________
> > 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
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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
More information about the FreeSWITCH-users
mailing list