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@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@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org