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@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@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
_______________________________________________ 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