<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1756/">https://reviewboard.asterisk.org/r/1756/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On February 21st, 2012, 8:35 a.m., <b>Simon Perreault</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I have two questions...
1. CRLF keep-alives are supported only for connection-oriented transports. Not UDP. Excerpt from RFC 5626:
4.4.1. Keep-Alive with CRLF
This approach MUST only be used with connection oriented transports
such as TCP or SCTP; it MUST NOT be used with connection-less
transports such as UDP.
This is because of RFC 3261 section 7.5. Excerpt:
Implementations processing SIP messages over stream-oriented
transports MUST ignore any CRLF appearing before the start-line
[H4.1].
A CRLF transported over UDP is just plain wrong. It is not valid SIP.
So, question: did I miss something? Did I not understand what you're sending over UDP?
2. If Asterisk is talking over TCP or TLS to a UA that supports RFC 5626, that UA would echo the CRLF back to Asterisk. Is Asterisk prepared to handle that?</pre>
</blockquote>
<p>On February 21st, 2012, 8:45 a.m., <b>Joshua Colp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1. I was under the impression that this was also for UDP, at least that is what the discussion I was in on led to. Unfortunately I wasn't at the Asterisk dev cons so I don't know what was discussed there about it. I can say though that other clients do use CRLFs for this purpose, even on UDP transports.
2. Yes. We will accept CRLF over any transport, that was done long long ago.
</pre>
</blockquote>
<p>On February 21st, 2012, 9:12 a.m., <b>Simon Perreault</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">RFC 5626 defines lightweight keep-alives for UDP using STUN multiplexed on the SIP port. The problem is that this can only be used with UAs implementing RFC 5626.
There is also RFC 6223 which somehow decouples the keep-alive mechanism from the rest of RFC 5626. Basically it looks like you could signal support for STUN keep-alives and start using that with UAs that also advertise support for RFC 6223. It looks very easy to implement: a new Via header flag for the signaling, and STUN Binding requests for the keep-alives.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">While it's certainly true that the mechanism being implemented here is not necessarily RFC compliant, it is being implemented here for Asterisk because it already exists in many UAs that are widely deployed, and there's very little cost to implementing it (and certainly very low risk of regression or interoperability issues).</pre>
<br />
<p>- Kevin</p>
<br />
<p>On February 21st, 2012, 7:26 a.m., Joshua Colp wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Joshua Colp.</div>
<p style="color: grey;"><i>Updated Feb. 21, 2012, 7:26 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This patch implements extremely lightweight NAT support, specifically sending a CRLF at a defined interval to keep the NAT mapping open. It does not use this mechanism to determine if the remote server is available or not, that is the trade off.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Confirmed packet is sent at default interval as well as configured interval. Also wrote testsuite test which will be in another review.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/channels/chan_sip.c <span style="color: grey">(355996)</span></li>
<li>/trunk/channels/sip/include/sip.h <span style="color: grey">(355996)</span></li>
<li>/trunk/configs/sip.conf.sample <span style="color: grey">(355996)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1756/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>