[Freeswitch-users] blind transfer context

[S W]

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