<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/1811/">https://reviewboard.asterisk.org/r/1811/</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 and opticron.</div>
<div>By Kevin Fleming.</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 improves the warning messages generated during SDP parsing when various problems are found:

* &#39;Unsupported media type&#39; is only reported when that is in fact the case, not when a supported media type is included in an &#39;m&#39; line that has an invalid format.

* All warning messages related to parsing &#39;m&#39; lines now include the &#39;m&#39; line contents.

* (minor bugfix) newline added to port-number-zero warning messages.

* Warning messages improved to use RFC-specified terminology for various items.

Kinsey: It&#39;s not quite clear to me what the difference between using &#39;continue&#39; in the &#39;m&#39;-line processing loop and returning from the function (as is done when a secondary offer an already-seen media type is seen) is; I&#39;m primarily concerned with the effect on the response the Asterisk will generate, because returning from the function would guarantee that our response would *not* include &#39;m&#39; lines matching each of the &#39;m&#39; lines in the offer. In addition, we should probably update the testsuite tests that exercise the SDP parser to ensure that these new cases are caught. If you want to give me some pointers on where that stuff lives, I&#39;d be happy to take a stab at it.</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;">Compile testing only.</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">(358762)</span></li>

</ul>

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




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




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