<p>Benjamin Keith Ford <strong>posted comments</strong> on this change.</p><p><a href="https://gerrit.asterisk.org/9225">View Change</a></p><p>Patch set 4:</p><p style="white-space: pre-wrap; word-wrap: break-word;">Everything else is updated, but curious on your thoughts about error handling with the generation of the RTCP packet before pushing up again.</p><p>(2 comments)</p><ul style="list-style: none; padding-left: 20px;"><li><p><a href="https://gerrit.asterisk.org/#/c/9225/4/res/res_rtp_asterisk.c">File res/res_rtp_asterisk.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/9225/4/res/res_rtp_asterisk.c@4402">Patch Set #4, Line 4402:</a> <code style="font-family:monospace,monospace">      if (res == 0 || res == 1) {</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">This is probably silly, but unless we're actually using both failure values</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">So the issue here is that there are 2 different things that can happen that would cause these functions to fail. If 1 is returned as the error code, there was an allocation error (rtcp_report is NULL). If 0 is returned, then something else went wrong and RTCP is halted for the session. res < 0 should never happen, so the only other option is res > 1, which would probably be fine. I'm happy to change it to that if you think that's the right approach here. Thoughts?</p></li><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/9225/4/res/res_rtp_asterisk.c@4419">Patch Set #4, Line 4419:</a> <code style="font-family:monospace,monospace">                ast_rtp_instance_get_remote_address(instance, &remote_address);</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Why do we have to update remote_address here?</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">This was done when ast_rtcp_write_report was one function, it sent it out in there too instead of allowing for the structuring of the report and then deciding what to do. If rtp->bundled exists, this is the primary transport and it should be used instead of what we originally intended to use.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.asterisk.org/9225">change 9225</a>. To unsubscribe, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/9225"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: Idab644b08a1593659c92cda64132ccc203fe991d </div>
<div style="display:none"> Gerrit-Change-Number: 9225 </div>
<div style="display:none"> Gerrit-PatchSet: 4 </div>
<div style="display:none"> Gerrit-Owner: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Kevin Harwell <kharwell@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Matthew Fredrickson <creslin@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 28 Jun 2018 15:50:30 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>