[Freeswitch-users] blind transfer context
François Delawarde
fdelawarde at wirelessmundi.com
Mon Nov 22 01:23:28 PST 2010
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
More information about the FreeSWITCH-users
mailing list