Could you pastebin your dialplan? I&#39;d like to let others try it out. Once it&#39;s confirmed we&#39;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">&lt;<a href="mailto:steve.d.ward@gmail.com">steve.d.ward@gmail.com</a>&gt;</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&#39;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&#39;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">&lt;<a href="mailto:fdelawarde@wirelessmundi.com" target="_blank">fdelawarde@wirelessmundi.com</a>&gt;</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&#39;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>
&gt; force_transfer_dialplan<br>
&gt; force_transfer_context<br>
&gt;<br>
&gt;<br>
&gt; You can&#39;t tell if a transfer is blind or attended.<br>
&gt;<br>
&gt;<br>
&gt; /b<br>
&gt;<br>
&gt; On Nov 19, 2010, at 5:04 AM, François Delawarde wrote:<br>
&gt;<br>
&gt; &gt; Hello,<br>
&gt; &gt;<br>
&gt; &gt; I pastebined a very simple configuration for you to reproduce:<br>
&gt; &gt; <a href="http://pastebin.freeswitch.org/14552" target="_blank">http://pastebin.freeswitch.org/14552</a><br>
&gt; &gt;<br>
&gt; &gt; We have user 100 in context &quot;public&quot;, 101 and 102 in context<br>
&gt; &gt; &quot;local&quot;.<br>
&gt; &gt;<br>
&gt; &gt; Scenario:<br>
&gt; &gt; 1. 100 calls destination &quot;123&quot;<br>
&gt; &gt; 2. 101 answers, and transfers to 102<br>
&gt; &gt;<br>
&gt; &gt; In step 2., if 101 does an attended transfer, it will of course use<br>
&gt; &gt; its<br>
&gt; &gt; own context (local) and the transfer will work. Now if 101 does a<br>
&gt; &gt; blind<br>
&gt; &gt; transfer instead, it will use the context of the other leg (100 =&gt;<br>
&gt; &gt; public) and it will not work.<br>
&gt; &gt;<br>
&gt; &gt; I think it should behave the same way for both types of transfer by<br>
&gt; &gt; default. A workaround is to set force_transfer_context (uncomment<br>
&gt; &gt; the<br>
&gt; &gt; line on the &quot;public&quot; dialplan) in the channel to be transfered,<br>
&gt; &gt; which<br>
&gt; &gt; can be a pain with more complex configurations.<br>
&gt; &gt;<br>
&gt; &gt; Thanks,<br>
&gt; &gt; François.<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; FreeSWITCH-users mailing list<br>
&gt; <a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
&gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
&gt; <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>