[Freeswitch-users] blind transfer context

[Michael Collins]

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