I have started to move some of this information into the wiki.<div><br></div><div>However, my previous comments about forcing sip_auth_realm/sip_auth_username are generally considered unsafe from a security point of view.</div>
<div><br></div><div>If you force those variables, under some circumstances a blind transferred call from an external gateway could later on be considered an authorized internal user and lead to undesired behaviour.</div><div>
<br></div><div>Forcing sip_invite_domain however is acceptable, as some request context will lose this information during a blind transfer or bridge.</div><div><br></div><div>I am currently building up a spreadsheet of different call scenarios, along with the request variables for each one, so it is easy to see how the variables change depending on what event is happening.</div>
<div><br></div><div>Cal</div><div><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 1:21 PM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr">&lt;<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Anthony,<div><br></div><div>Thanks for the reply, yeah I spent some time looking at alternative ways and came up with one that seems to get the job done</div>
<div><br></div><div>I am convinced now that there is no bug as such - but one thing that is absolutely clear, is that mod_xml_curl is in desperate need of normalization.. even if it was fully documented, some of the variants don&#39;t make logical sense. However, the information is there, and as long as you do the correct conditional checks, then it will work flawlessly.</div>

<div><br></div><div>To make the authenticated domain stick when passing through to a gateway, we use the following;</div><div><br></div><div>&lt;action application=&quot;bridge&quot; data=&quot;{sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}sofia/gateway/{{<a href="http://dst.gateway.name" target="_blank">dst.gateway.name</a>}}/{{dst.gateway.fs_dial_prefix}}{{dst.dst_number_e164}}&quot;/&gt;<br>

<br>The most important part of the above being;</div><div>{sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}</div><div><br></div><div>However, this alone doesn&#39;t deal with the fact that you have to look in different places for the correct variables depending on what the current call context is.</div>

<div><br></div><div>To a certain extent, your own business logic will also determine which variables should be used, and a combination of conditional checks may need to be used in order to figure out which variable you should be using in the first place lol.</div>

<div><br></div><div>Here are the patterns we have found so far - this is just an information dump for now, and later down the road I will update the mod_xml_curl documentation.</div><div><br></div><div># Ensure that variable_sip_auth_username / variable_sip_auth_realm</div>

<div>#</div><div># If Call-Direction is inbound, then;</div><div># src_user = variable_sip_auth_username</div><div># src_domain = variable_sip_auth_realm</div><div># dst_user = variable_sip_to_user</div><div>#</div><div>
# If Call-Direction is outbound, then;</div>
<div># originate_user = variable_sip_auth_username</div><div># originate_domain = variable_sip_auth_realm</div><div># src_user = variable_sip_to_user</div><div># src_domain = variable_sip_to_host</div><div># dst_user = Caller-Destination-Number</div>

<div><br></div><div>* gateway to gateway (442476100401 &gt; 442476100402)</div><div>* domain to gateway - blind xfer to gateway (2000 &gt; 442476100401 &gt; 442476100402)</div><div>* domain to gateway - blind xfer to domain (2000 &gt; 442476100401 &gt; 2002)</div>

<div>* domain to gateway (2000 &gt; 442476100401)</div><div>* domain to domain (2000 &gt; 2001)</div><div><br></div><div>----</div><div><br></div><div># Check if variable_sip_to_host is present and known gateway</div><div>

#</div><div># If variable_dialed_user and variable_dialed_domain are present;</div><div># originate_user = variable_dialed_user</div><div># originate_domain = variable_dialed_domain</div><div># src_user = variable_sip_from_user</div>

<div># src_domain = variable_sip_to_host</div><div># dst_user = Caller-Destination-Number</div><div>#</div><div># If not present;</div><div># src_user = variable_sip_from_user</div><div># src_domain = variable_sip_to_host</div>

<div># dst_user = variable_sip_to_user</div><div><br></div><div><div>* gateway to domain (442476100401 &gt; 2002)</div><div>* gateway to domain - blind xfer to gateway (442476100401 &gt; 2000 &gt; 442476100402)</div></div>

<div>* gateway to domain - blind xfer to domain (442476100401 &gt; 2000 &gt; 2002)</div><div><br></div><div>----</div><div><br></div><div># check for variable_dialed_domain</div><div># If match;</div><div># src_user = variable_dialed_user</div>

<div># src_domain  = variable_dialed_domain</div><div># dst_user = Caller-Destination-Number</div><div><br></div><div><div>* domain to domain to gateway (2000 &gt; 2001 &gt; 442476100402)</div></div><div class="HOEnZb"><div class="h5">
<div><br></div><div><br>
<div class="gmail_quote">On Tue, Nov 20, 2012 at 2:55 AM, Anthony Minessale <span dir="ltr">&lt;<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@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">

One thing you can do is set the variable when you do know it, from the dialplan.  So it will be there in all the subsequent events.<div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>
On Mon, Nov 19, 2012 at 1:34 AM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr">&lt;<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>&gt;</span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Last update, then I&#39;m really going to sleep!<div><br></div><div><div>Apologies for the noise btw, in hindsight I should have collected all this info and posted in one go.</div>


<div><br></div><div>I&#39;ve tried enabling auth-all-packets (along with auth_calls), as I thought maybe having authentication on REFER packets might make a difference, but sadly it had no effect (the SIP headers show proxy-authorization in the REFER, but nothing extra showed in mod_xml_curl)</div>




<div><br></div><div>I&#39;ve managed to narrow down the circumstances in which this happens;</div><div><br></div><div>CORRECT:</div><div><br>* User receives call from gateway, blind transfer to another user (shows correctly as variable_dialed_user/variable_dialed_domain)</div>




<div>* User receives call from another user, blind transfer to gateway (shows correctly as variable_dialed_user/variable_dialed_domain)</div><div>* User receives call from another user, blind transfer to another user (shows correctly as variable_dialed_user/variable_dialed_domain)</div>




<div>* User makes call to another user, blind transfer to another user (shows correctly as variable_dialed_user/variable_dialed_domain)</div><div>* User makes call to another user, blind transfer to a gateway (shows correctly as variable_dialed_user/variable_dialed_domain)</div>




<div><br></div><div>MISSING:</div><div><br></div><div>* User makes call to a gateway, blind transfer to another gateway (no clean variables for domain)</div><div>* User makes call to a gateway, blind transfer to another user (no clean variables for domain)</div>




<div><br></div><div>So, the problem seems to happen specifically when you blind transfer a call that is already in progress on a gateway, where the call was originated by a user and not a gateway.</div><div><br></div><div>



I did a bit more looking through code, added a few switch_log_printf() calls, and found that the following method is NOT called in those two scenarios where these variables are missing;</div><div>mod_dptools.c: &quot;switch_call_cause_t user_outgoing_channel&quot;</div>



<div><br></div><div>This is about as far as I can go on this, as I just don&#39;t know enough about C to give any more in-depth info :/</div><span><font color="#888888"><div><br></div><div>Cal</div></font></span><div>
<div><div><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 5:52 AM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr">&lt;<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>&gt;</span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry, another update.. after tinkering with the SIP headers, we found that we&#39;re able to pass any user/host along in an INVITE, and this is passed onto mod_xml_curl.<div>




<br></div><div>To fix this particular part of the problem, we enabled auth_calls and this gives us correct/clean variables we can trust, specifically;</div>
<div><br></div><div><div> u&#39;variable_sip_auth_username&#39;: u&#39;2000&#39;,</div><div> u&#39;variable_user_name&#39;: u&#39;2000&#39;,</div><div><br></div><div>However, when attempting to do the blind transfer again, this variables are all missing.</div>





<div><br></div><div>At this point I&#39;m convinced that attempting to extract the user/domain from the Refer headers is probably not the right thing to do... But I&#39;m still no closer to figuring out what the correct approach should be to expose the authenticated user/domain to mod_xml_curl.</div>




<span><font color="#888888">
<div><br></div><div>Cal</div></font></span><div><div><div><br></div><div><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 4:58 AM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr">&lt;<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>&gt;</span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another quick update on this before I pass out from lack of sleep..!<div><br></div><div>Just had a look through the mod_sofia.c/h source and found the following;</div>





<div><br></div><div><div>mod_sofia.c/mod_sofia.h</div><div>
#define SOFIA_REFER_TO_VARIABLE &quot;sip_refer_to&quot;</div><div>if (!zstr(full_ref_by)) {</div><div><span style="white-space:pre-wrap">        </span>switch_channel_set_variable(t_channel, SOFIA_SIP_HEADER_PREFIX &quot;Referred-By&quot;, full_ref_by);</div>






<div>}</div><div>if (!zstr(full_ref_to)) {</div><div><span style="white-space:pre-wrap">        </span>switch_channel_set_variable(t_channel, SOFIA_REFER_TO_VARIABLE, full_ref_to);</div><div>}</div><div>if (!zstr(full_ref_to)) {</div>






<div><span style="white-space:pre-wrap">        </span>switch_channel_set_variable(t_channel, SOFIA_REFER_TO_VARIABLE, full_ref_to);</div><div>}</div><div>switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG, &quot;Process REFER to [%s@%s]\n&quot;, exten, (char *) refer_to-&gt;r_url-&gt;url_host);</div>






<div><br></div><div>If the correct approach is deemed to be patching code, then I figured it could be as simple as this;</div><div><br></div><div><div>switch_channel_set_variable(t_channel, &quot;Referred-By-User&quot;, exten);</div>






<div>switch_channel_set_variable(t_channel, &quot;Referred-By-Domain&quot;, (char *) refer_to-&gt;r_url-&gt;url_host);</div></div><div><br></div><div>This is pretty much where my knowledge of C ends, I can (just about) read and copy chunks of C code, but that&#39;s about it :)</div>





<span><font color="#888888">
<div><br></div><div>Cal</div></font></span><div><div><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 4:38 AM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr">&lt;<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>&gt;</span> wrote:<br>






<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not sure if this is relevant but thought I&#39;d point it out.<div><br></div><div>The following field seems to contain the IP of the domain we were expecting (&#39;<a href="http://c1881.voiceflare.co.uk/" target="_blank">c1881.voiceflare.co.uk</a>&#39;)</div>







<div><br></div><div><div> u&#39;variable_sip_from_host&#39;: u&#39;89.238.182.137&#39;,</div><div><br></div><div>Normally, this field would contain the hostname and not the IP.</div><span><font color="#888888"><div>
<br></div><div>Cal</div></font></span><div><div><br><div class="gmail_quote">
On Mon, Nov 19, 2012 at 4:34 AM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr">&lt;<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>&gt;</span> wrote:<br>






<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi guys,<div><br></div><div>In a nut shell, it appears that when attempting to perform a blind transfer under certain conditions (explained below), mod_xml_curl does not expose the originating domain in a clean format.</div>








<div><div><br></div><div><div>My initial plan was to find the point where these variable were being generated, look at what was available, then add an extra variable for the domain and submit a patch.</div></div><div><br>








</div><div>Sadly my C isn&#39;t great and I hit a brick wall, so if anyone can help out, I will ensure the mod_xml_curl documentation is updated and/or assist with any patching/testing required.</div><div><div><br></div>







</div>
<div>Please take the following scenario;</div><div><br></div><div>* Extension 2000 calls an external number via a gateway (i.e. bridge sofia/gateway/name/e164_number_here).</div><div>* Call connects fine, audio stays good, no disconnection problems etc.</div>








<div>* Call is blind transferred to another extension</div><div><br></div><div>As a result, the following is determined;</div><div><br></div><div>* User initiating the blind transfer is 2000</div><div>* Domain initiating the blind transfer is <a href="http://c1881.voiceflare.co.uk" target="_blank">c1881.voiceflare.co.uk</a></div>








<div>* Destination number of the call is 447866123456</div><div>* Number to blind transfer to is 2001</div><div>* Call to mod_xml_curl is made</div><div><br></div><div>It makes reference to the User in the following &#39;clean&#39; variables (by clean, I mean variables that just contain 2000 and don&#39;t require mangling to extract the info);</div>








<div><br></div><div><div> u&#39;Caller-ANI&#39;: u&#39;2000&#39;,</div></div><div><div> u&#39;Caller-Username&#39;: u&#39;2000&#39;,</div></div><div><div> u&#39;Caller-Caller-ID-Number&#39;: u&#39;2000&#39;,</div></div><div>








<div> u&#39;Hunt-ANI&#39;: u&#39;2000&#39;,</div></div><div><div> u&#39;Hunt-Caller-ID-Number&#39;: u&#39;2000&#39;,</div></div><div><div> u&#39;Hunt-Username&#39;: u&#39;2000&#39;,</div></div><div><div> u&#39;variable_last_sent_callee_id_number&#39;: u&#39;2000&#39;,</div>








</div><div><div><div> u&#39;variable_sip_from_user&#39;: u&#39;2000&#39;,</div><div></div></div><div><br></div><div>It also has the User in the following unclean variables;</div><div><br></div><div> u&#39;variable_bridge_channel&#39;: u&#39;sofia/external/<a href="http://2000@c1881.voiceflare.co.uk:5060" target="_blank">2000@c1881.voiceflare.co.uk:5060</a>&#39;,</div>








<div></div></div><div><div> u&#39;variable_sip_from_uri&#39;: <a href="mailto:u%272000@89.238.182.137" target="_blank">u&#39;2000@89.238.182.137</a>&#39;,</div><div> u&#39;variable_sip_full_from&#39;: u&#39;&quot;foxx&quot; &lt;<a href="mailto:sip%3A2000@89.238.182.137" target="_blank">sip:2000@89.238.182.137</a>&gt;;tag=XryjFQp3rB2NF&#39;,</div>








</div><div><div> u&#39;variable_sip_h_Referred-By&#39;: u&#39;&quot;foxx&quot; &lt;<a href="http://sip:2000@c1881.voiceflare.co.uk:5060" target="_blank">sip:2000@c1881.voiceflare.co.uk:5060</a>&gt;&#39;,</div></div><div>







<br></div><div>However, it only references the domain in the following unclean variables;</div>
<div><br></div><div> u&#39;variable_bridge_channel&#39;: u&#39;sofia/external/<a href="http://2000@c1881.voiceflare.co.uk:5060" target="_blank">2000@c1881.voiceflare.co.uk:5060</a>&#39;,</div><div> u&#39;variable_sip_h_Referred-By&#39;: u&#39;&quot;foxx&quot; &lt;<a href="http://sip:2000@c1881.voiceflare.co.uk:5060" target="_blank">sip:2000@c1881.voiceflare.co.uk:5060</a>&gt;&#39;,</div>








<div> u&#39;variable_sip_refer_to&#39;: u&#39;&lt;<a href="http://sip:2001@c1881.voiceflare.co.uk:5060" target="_blank">sip:2001@c1881.voiceflare.co.uk:5060</a>&gt;&#39;,</div><div><br></div><div>Lets say that we want to determine the user/domain that has initiated this transfer, doing so would mean mangling with one of those above variables, which seems a bit dirty (plus it is not clear which is the correct one to use).</div>








<div><br></div><div>I have attached the SIP trace of the entire blind transfer event, and the full mod_xml_curl request being sent.</div><div><br></div><div><div>If anyone could answer the following, it&#39;d be much appreciated;</div>








<div><br></div><div>* Should there be an improvement patch that exposes the domain of the user that originated the blind transfer?</div><div>* Are there better/alternative ways to extracting the domain of the user that originated the blind transfer?</div>








</div><div><br></div><div>Many thanks</div><span><font color="#888888"><div><br>Cal</div><div><br></div></font></span></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></div>
<br></div></div>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>


Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>

GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>

<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:<a href="tel:%2B19193869900" value="+19193869900" target="_blank">+19193869900</a><br>
</div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>