[Freeswitch-users] blind transfer context

[S W]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20101119/a3e0ff86/attachment.html