<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/2099/">https://reviewboard.asterisk.org/r/2099/</a>
</td>
</tr>
</table>
<br />
<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 Matt Jordan.</div>
<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;">Handling for multiple SRTP keys and re-negotiation of the SRTP keys was fixed in previous versions of Asterisk 1.8. In the process, it became apparent that in certain re-INVITE scenarios, with certain models of phones, re-negotiating the keys caused issues when the phones were taken off hold. Specifically, certain models of phones would send RTP packets to Asterisk that failed the authentication check, even though the policy had been renewed with the newly agreed upon keys.
In addition, while testing, it was found that phones that offer AST_AES_CM_128_HMAC_SHA1_32 will end up with no audio if the phone is the initiator of the call. The phone will send an INVITE request specifying that AST_AES_CM_128_HMAC_SHA1_32 be used for the cryptographic policy; Asterisk will set its policy to that value. Unfortunately, when the call is Answered and a 200 OK is sent back to the UA, the policy sent in the 200's SDP will the be hard coded AST_AES_CM_128_HMAC_SHA1_80. This is only a problem in Asterisk 1.8, as Asterisk 10 fixed this problem when it introduced the ability to have the cryptographic policy configurable.
This patch fixes both problems: first, it caches the remote key received from the UA and only re-creates the SRTP session if the UA has sent a new remote key. Second, it caches the crypto policy sent by the UA (which is what Asterisk will use internally for the SRTP session already), and responds with that crypto policy in the response to the INVITE.</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;">Tested with Aastra and SNOM 320 model phones. While the initial bug that the issue reporter had could not be reproduced with these phones (and firmware revisions), with this patch calls could be established between the two phones (using different crypto policies) and re-INVITEs could be sent without causing issues.
The issue reporter also confirmed that the patch resolved the issue they were experiencing with their phone models.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20194">ASTERISK-20194</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>./branches/1.8/channels/sip/sdp_crypto.c <span style="color: grey">(371988)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2099/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>