<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/1169/">https://reviewboard.asterisk.org/r/1169/</a>
     </td>
    </tr>
   </table>
   <br />


<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.orgrb/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 David Vossel.</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;">This patch fixes how chan_sip handles dynamic rtp payload types it does not understand.  At the moment if a dynamic payload&#39;s mime type does not match one we understand, the payload does not get removed from our payload table.  As a result of this, the payload is set to whatever dynamic codec we use internally for that payload number on outgoing INVITES.  This is incorrect.

For example.  Internally we advertise speex at payload 117 on outgoing INVITES.  If unknown codec BLAH is in a incoming INVITE&#39;s SDP at dynamic payload 117, we mark in our payload table that 117 exists, and by default we set that to type speex in our internal list.  Later we go back through and set the format for that payload to what it actually is when we parse the &quot;rtpmap&quot; part.  When we don&#39;t understand a format type, it never gets removed and often an incorrect format type is sent in response for that payload.

This patch fixes this by properly checking the rtpmap set function&#39;s return code to make sure it was found.  The function can return both -1 and -2 depending on the source of the mismatch.  We were just checking -1 explicitly.
</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 patch with Ekiga supporting g726 variants we do not support.  I verified Asterisk now responds correctly.</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>/branches/1.8/channels/chan_sip.c <span style="color: grey">(313187)</span></li>

 <li>/branches/1.8/include/asterisk/rtp_engine.h <span style="color: grey">(313187)</span></li>

 <li>/branches/1.8/main/rtp_engine.c <span style="color: grey">(313187)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/1169/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>




  </div>
 </body>
</html>