<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 16, 2013 at 6:31 AM, Olle E. Johansson <span dir="ltr">&lt;<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
16 sep 2013 kl. 11:40 skrev Saúl Ibarra Corretgé &lt;<a href="mailto:saghul@gmail.com">saghul@gmail.com</a>&gt;:<br>
<div class="im"><br>
&gt;<br>
&gt; [snip]<br>
&gt;<br>
&gt;&gt; After reading your e-mail and the RFCs, I don&#39;t have a clear<br>
&gt;&gt; understanding either of all of the issues surrounding usage of a SIPS<br>
&gt;&gt; URI instead of a SIP URI with TLS as transport. The fact that SIPS does<br>
&gt;&gt; not equate to &quot;best-effort&quot; TLS obviously has implications if hops in<br>
&gt;&gt; the middle don&#39;t support TLS (you either think you&#39;re secure but aren&#39;t,<br>
&gt;&gt; or your calls fail, or... something else perhaps?). What I don&#39;t have a<br>
&gt;&gt; clear understanding of is why we should prefer SIP with TLS as the<br>
&gt;&gt; transport over SIPS. Couldn&#39;t a user make the argument that they really<br>
&gt;&gt; don&#39;t want &quot;best-effort&quot; - that is, if they asked for secure<br>
&gt;&gt; communication, they want secure communication along the entire path?<br>
&gt;&gt; What explicit pitfalls are we running into by using SIPS in the URI in<br>
&gt;&gt; the contact header?<br>
&gt;<br>
&gt; FWIW, I&#39;ll just throw here what we do in Blink. I know it&#39;s not kosher as per the standard, but oh well, world is not perfect: we ignore SIPS. We basically treat it as it were &quot;sip:&quot;. And we use transport=tls.<br>

&gt;<br>
&gt; I know Olle will want to slap me in the wrist, but that&#39;s what has worked so far out there in the wild. Sue me! ;-)<br>
<br>
</div>I&#39;ll take care of the slapping when we&#39;re on tour. :-)<br>
<br>
We are several who have voted for deprecating SIPS: totally. The meaning is very unclear and the<br>
benefits of using it even more so.<br>
<br>
The important fact is that in this case we don&#39;t know if the other UA used udp, tcp or TLS - just the<br>
fact that we get a request over a TLS connection doesn&#39;t mean that we can upgrade to SIPS:.<br>
Could be a proxy or a b2bua that upgraded to TLS based on NAPTR or policy. Adding sips: in a<br>
contact without getting an inbound complete SIPS: request (with all the right headers in place) will break<br>
communication.<br></blockquote><div><br></div><span style="font-family:arial,sans-serif;font-size:13px">Based on your above comment - and since </span><span style="font-family:arial,sans-serif;font-size:13px">this particular commit is concerned with generating Contact headers when creating a server side SIP dialog when using TLS - I think we can break down our questions into three categories:</span></div>
<div class="gmail_quote"><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">1. The Contact header URI scheme. Should we mirror Blink&#39;s behavior and just use SIP URIs for all Contact headers? Should we, under certain circumstances, generate a SIPS URI in our Contact header? Under what circumstances should we feel it safe to do so?</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">2. The Contact header transport parameter. Should we ever put &quot;;transport=tls&quot; in our Contact header? When we wish to be contacted over TLS, should we put any sort of transport parameter in our Contact header? If not, how do we indicate that we wish to be contacted over TLS?</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">3. The potential effects that 1. and 2. have on the rest of the SIP traffic Asterisk generates for this dialog. What other areas do you have in mind that might be affected? Some headers are likely taken care of for us by the SIP stack, (Route, Via, etc.)  but there may be others that we are not thinking of.</span><br style="font-family:arial,sans-serif;font-size:13px">
<br></div><div class="gmail_quote" style><font face="arial, sans-serif">Thanks!</font></div><div class="gmail_quote" style><font face="arial, sans-serif"><br></font></div><div class="gmail_quote" style><font face="arial, sans-serif">Matt</font></div>
<div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> &amp; <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>