<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/13/2013 11:31 AM, Olle E.
Johansson wrote:<br>
</div>
<blockquote
cite="mid:62C9B425-6872-4BDA-AA10-B7EC1A2DEE5B@edvina.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>13 sep 2013 kl. 17:08 skrev Joshua Colp <<a
moz-do-not-send="true" href="mailto:jcolp@digium.com">jcolp@digium.com</a>>:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Olle E. Johansson wrote:<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">- When do you add ;transport ? -
When do you use sips: ?<br>
</blockquote>
I assume you mean the code since this can't be set by the
user.<br>
Transports within pjsip have different properties about
them -<br>
whether they are secure, whether they are TCP, UDP, TLS,
etc. The<br>
code above uses these properties to know what to add and
when. This<br>
code is based on code that already existed within the
pjsua library<br>
itself.<br>
<br>
</blockquote>
Right. But you avoided to answer my questions, that are
quite<br>
important to get right. Can you show some examples?<br>
</blockquote>
<br>
If the transport is TLS (or otherwise marked as secure) then
sips is added. If the transport is not UDP then transport is
added.<br>
</blockquote>
If you add sips: you are in a whole other division. You should
no do that, it will just cause trouble. It impacts a lot of
other headers and is in this case propably a big mistake. Read
the RFCs on TLS to get the full picture, RFC 3261 has an update
and clarification on the usage. Just assuming that you should
use SIPS: in this case will lead to broken communication. SIPS:
is not an equivalent of HTTPS:, it's much more and pretty bad.</div>
</blockquote>
<br>
I skimmed RFC 5630, which I can only assume is the update to RFC
3261 you were talking about.<br>
<br>
The gist of what I read is that using a SIPS URI requires that all
hops over which the message travels use a secure transport, such as
TLS. We can't necessarily always use a SIPS URI in the Contact
header of a 200 OK because we don't necessarily know that all
involved hops (including the UAC that originated the request)
support TLS. Is this what you were talking about when you said "It's
much more and pretty bad"? Are there other more specific problems
that you were thinking of? The fact that other headers are impacted
is actually outside of our concern and should be handled by PJSIP.
So if you were worried about Via headers or other headers that also
need SIPS URIs, then that shouldn't arise as an issue.<br>
<br>
Based on what I'm reading, as a UAS, we should only use a SIPS URI
in the Contact header if the Request-URI in the dialog-initiating
request was a SIPS URI. Otherwise, we should use a SIP URI in the
Contact header of the 200 OK. Is this what you would suggest as at
least a baseline determiner for whether to include a SIPS URI in the
Contact header? Or are you instead suggesting that we simply *never*
use a SIPS URI in the Contact header? If not, why?<br>
<br>
<blockquote
cite="mid:62C9B425-6872-4BDA-AA10-B7EC1A2DEE5B@edvina.net"
type="cite">
<div><br>
</div>
<div>If you add a transport you will prevent upgrades from UDP to
TCP, which is not a good thing. UDP is always the fallback when
someone contacts you, we should encourage if someone prefers to
contact us over TLS or TCP to the contact we send.</div>
</blockquote>
<br>
I don't understand what you mean here. The two sentences seem to
contradict each other. The first seems to imply that adding a
transport parameter to the Contact header is bad, but the second
seems to be encouraging us to add a transport parameter. Can you
clarify what you were trying to say? For clarity, the current code
will add a ;transport parameter to the Contact header if the
transport to be used is not UDP.<br>
<br>
Interestingly, the deprecation of ";transport=tls" is upgraded in
RFC 5630 to be "MUST NOT use the transport=tls parameter" (Sections
5.1.1, 5.1.1.1, 5.1.2, 5.3, and 5.4). So what is the preferred
method by which we indicate that we wish for the ACK, BYE, and
session refreshes to arrive using TLS if we don't use a SIPS URI and
can't use ";transport=tls" in the Contact? Is there a different,
more standardized way to encourage TLS usage when sending SIP
traffic to us?<br>
<br>
<blockquote
cite="mid:62C9B425-6872-4BDA-AA10-B7EC1A2DEE5B@edvina.net"
type="cite">
<div><br>
</div>
<div>
<blockquote type="cite"><br>
This is the above logic in the code you mentioned. I don't
know what else you are looking for...<br>
</blockquote>
I just wanted to understand if you where doing this right or
wrong, but you confirmed that you did it wrong. Please fix.</div>
</blockquote>
<br>
We certainly want to get it right, but we also would like more
constructive criticism on the matter. Saying that things are "bad"
and "wrong" without providing clear suggestions or alternatives is
not helpful. Nor is saying that something "will cause trouble"
without stating what said trouble actually is. I'd rather have a
clear idea of what it is we have done wrong instead of trying to
guess.<br>
<br>
Mark Michelson<br>
<br>
<blockquote
cite="mid:62C9B425-6872-4BDA-AA10-B7EC1A2DEE5B@edvina.net"
type="cite">
<div><br>
</div>
<div>/O<br>
<blockquote type="cite"><br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a moz-do-not-send="true"
href="http://www.digium.com">www.digium.com</a> & <a
moz-do-not-send="true" href="http://www.asterisk.org">www.asterisk.org</a><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a
moz-do-not-send="true" href="http://www.api-digital.com">http://www.api-digital.com</a>
--<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a moz-do-not-send="true"
href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote>
</div>
<br>
<div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: auto; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0;
">
<div>---</div>
<div>* Olle E Johansson - <a moz-do-not-send="true"
href="mailto:oej@edvina.net">oej@edvina.net</a></div>
<div>* Cell phone +46 70 593 68 51, Office +46 8 96 40 20,
Sweden</div>
<div><br class="webkit-block-placeholder">
</div>
</span><br class="Apple-interchange-newline">
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></pre>
</blockquote>
<br>
</body>
</html>