[Freeswitch-users] blind transfer context

[S W]

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