Could you pastebin your dialplan? I'd like to let others try it out. Once it's confirmed we'll wikify it.<div>-MC<br><br><div class="gmail_quote">On Fri, Nov 19, 2010 at 9:08 AM, S W <span dir="ltr"><<a href="mailto:steve.d.ward@gmail.com">steve.d.ward@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Just as a comment, I have recently employed the functionality of force_transfer_context, and it is great exactly as it is.<br>
<br>In my scenario I need to control how the channel RECEIVING a transfer/REFER handles that transfer.<br>
<br>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). <br>
<br>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.<br>
<br>It's awesome!!! <br><br>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). <br>
<br>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. <br><br>Anyway, just a comment....<div><div></div><div class="h5">
<br><br><div class="gmail_quote">
On Fri, Nov 19, 2010 at 11:45 AM, François Delawarde <span dir="ltr"><<a href="mailto:fdelawarde@wirelessmundi.com" target="_blank">fdelawarde@wirelessmundi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Problem is those variables must be set on the channel that has to be<br>
transfered and not the channel that performs the transfer.<br>
<br>
I thought it would be more logical to use the transferer context by<br>
default (just like in attended xfers), and for those variables to be set<br>
on the transferer's side.<br>
<br>
François.<br>
<div><div></div><div><br>
<br>
On Fri, 2010-11-19 at 08:32 -0600, Brian West wrote:<br>
> force_transfer_dialplan<br>
> force_transfer_context<br>
><br>
><br>
> You can't tell if a transfer is blind or attended.<br>
><br>
><br>
> /b<br>
><br>
> On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > I pastebined a very simple configuration for you to reproduce:<br>
> > <a href="http://pastebin.freeswitch.org/14552" target="_blank">http://pastebin.freeswitch.org/14552</a><br>
> ><br>
> > We have user 100 in context "public", 101 and 102 in context<br>
> > "local".<br>
> ><br>
> > Scenario:<br>
> > 1. 100 calls destination "123"<br>
> > 2. 101 answers, and transfers to 102<br>
> ><br>
> > In step 2., if 101 does an attended transfer, it will of course use<br>
> > its<br>
> > own context (local) and the transfer will work. Now if 101 does a<br>
> > blind<br>
> > transfer instead, it will use the context of the other leg (100 =><br>
> > public) and it will not work.<br>
> ><br>
> > I think it should behave the same way for both types of transfer by<br>
> > default. A workaround is to set force_transfer_context (uncomment<br>
> > the<br>
> > line on the "public" dialplan) in the channel to be transfered,<br>
> > which<br>
> > can be a pain with more complex configurations.<br>
> ><br>
> > Thanks,<br>
> > François.<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>