[Freeswitch-users] blind transfer context
S W
steve.d.ward at gmail.com
Mon Nov 22 05:13:39 PST 2010
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20101122/45f8cd96/attachment-0001.html
More information about the FreeSWITCH-users
mailing list