<p>Jenkins2 <strong>merged</strong> this change.</p><p><a href="https://gerrit.asterisk.org/9833">View Change</a></p><div style="white-space:pre-wrap">Approvals:
Joshua Colp: Looks good to me, but someone else must approve
George Joseph: Looks good to me, approved
Jenkins2: Approved for Submit
</div><pre style="font-family: monospace,monospace; white-space: pre-wrap;">res_pjsip/rtp: No joint capabilities between streams.<br><br>When a conference contained a mixture of audio/video and audio-only<br>users, a NOTICE message would pop up stating there are no joint<br>capabilities between streams. This happens because streams can never be<br>removed, but they can be in a REMOVED state. If we have the scenario<br>where user A joins with audio/video, user B joins with audio-only, and<br>user C joins with audio/video, then user A leaves, the message would<br>be triggered. That removed stream is still in the SDP, but Asterisk<br>would pass it through, causing it to be seen as a ulaw stream. A check<br>has been added for removed streams, setting their status to REMOVED when<br>handling negotiated SDPs.<br><br>Also addressed an issue where user A joins, then user B joins but does<br>not receive video until much later. Full frames were not being sent,<br>causing some PLI from the browser. Because the video was flowing in one<br>direction, the browser sets the SSRC to 1, but Asterisk was dropping the<br>PLI because of that. Added a check to see if the SSRC is 1 or not, which<br>sends full frames and allows video to flow between user A and user B.<br>This should only happen when dealing with PSFB or FUR, and in the case<br>of PSFB, only for PLI.<br><br>ASTERISK-27398<br><br>Change-Id: I26e7c6f101bc119549eeca406b5bcd25ad8ebc5e<br>---<br>M res/res_pjsip_session.c<br>M res/res_rtp_asterisk.c<br>2 files changed, 23 insertions(+), 5 deletions(-)<br><br></pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;"><span>diff --git a/res/res_pjsip_session.c b/res/res_pjsip_session.c</span><br><span>index 1300850..3bb1ef4 100644</span><br><span>--- a/res/res_pjsip_session.c</span><br><span>+++ b/res/res_pjsip_session.c</span><br><span>@@ -930,10 +930,18 @@</span><br><span> session_media = AST_VECTOR_GET(&session->pending_media_state->sessions, i);</span><br><span> stream = ast_stream_topology_get_stream(session->pending_media_state->topology, i);</span><br><span> </span><br><span style="color: hsl(0, 100%, 40%);">- /* The stream state will have already been set to removed when either we</span><br><span style="color: hsl(0, 100%, 40%);">- * negotiate the incoming SDP stream or when we produce our own local SDP.</span><br><span style="color: hsl(0, 100%, 40%);">- * This can occur if an internal thing has requested it to be removed, or if</span><br><span style="color: hsl(0, 100%, 40%);">- * we remove it as a result of the stream limit being reached.</span><br><span style="color: hsl(120, 100%, 40%);">+ /* Make sure that this stream is in the correct state. If we need to change</span><br><span style="color: hsl(120, 100%, 40%);">+ * the state to REMOVED, then our work here is done, so go ahead and move on</span><br><span style="color: hsl(120, 100%, 40%);">+ * to the next stream.</span><br><span style="color: hsl(120, 100%, 40%);">+ */</span><br><span style="color: hsl(120, 100%, 40%);">+ if (!remote->media[i]->desc.port) {</span><br><span style="color: hsl(120, 100%, 40%);">+ ast_stream_set_state(stream, AST_STREAM_STATE_REMOVED);</span><br><span style="color: hsl(120, 100%, 40%);">+ continue;</span><br><span style="color: hsl(120, 100%, 40%);">+ }</span><br><span style="color: hsl(120, 100%, 40%);">+</span><br><span style="color: hsl(120, 100%, 40%);">+ /* If the stream state is REMOVED, nothing needs to be done, so move on to the</span><br><span style="color: hsl(120, 100%, 40%);">+ * next stream. This can occur if an internal thing has requested it to be</span><br><span style="color: hsl(120, 100%, 40%);">+ * removed, or if we remove it as a result of the stream limit being reached.</span><br><span> */</span><br><span> if (ast_stream_get_state(stream) == AST_STREAM_STATE_REMOVED) {</span><br><span> /*</span><br><span>diff --git a/res/res_rtp_asterisk.c b/res/res_rtp_asterisk.c</span><br><span>index 1327d71..1d1d66e 100644</span><br><span>--- a/res/res_rtp_asterisk.c</span><br><span>+++ b/res/res_rtp_asterisk.c</span><br><span>@@ -5802,7 +5802,17 @@</span><br><span> }</span><br><span> </span><br><span> if (ssrc_valid && rtp->themssrc_valid) {</span><br><span style="color: hsl(0, 100%, 40%);">- if (ssrc != rtp->themssrc && use_packet_source) {</span><br><span style="color: hsl(120, 100%, 40%);">+ /*</span><br><span style="color: hsl(120, 100%, 40%);">+ * If the SSRC is 1, we still need to handle RTCP since this could be a</span><br><span style="color: hsl(120, 100%, 40%);">+ * special case. For example, if we have a unidirectional video stream, the</span><br><span style="color: hsl(120, 100%, 40%);">+ * SSRC may be set to 1 by the browser (in the case of chromium), and requests</span><br><span style="color: hsl(120, 100%, 40%);">+ * will still need to be processed so that video can flow as expected. This</span><br><span style="color: hsl(120, 100%, 40%);">+ * should only be done for PLI and FUR, since there is not a way to get the</span><br><span style="color: hsl(120, 100%, 40%);">+ * appropriate rtp instance when the SSRC is 1.</span><br><span style="color: hsl(120, 100%, 40%);">+ */</span><br><span style="color: hsl(120, 100%, 40%);">+ int exception = (ssrc == 1 && !((pt == RTCP_PT_PSFB && rc == AST_RTP_RTCP_FMT_PLI) || pt == RTCP_PT_FUR));</span><br><span style="color: hsl(120, 100%, 40%);">+ if ((ssrc != rtp->themssrc && use_packet_source && ssrc != 1)</span><br><span style="color: hsl(120, 100%, 40%);">+ || exception) {</span><br><span> /*</span><br><span> * Skip over this RTCP record as it does not contain the</span><br><span> * correct SSRC. We should not act upon RTCP records</span><br><span></span><br></pre><p>To view, visit <a href="https://gerrit.asterisk.org/9833">change 9833</a>. To unsubscribe, or for help writing mail filters, 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/9833"/><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: merged </div>
<div style="display:none"> Gerrit-Change-Id: I26e7c6f101bc119549eeca406b5bcd25ad8ebc5e </div>
<div style="display:none"> Gerrit-Change-Number: 9833 </div>
<div style="display:none"> Gerrit-PatchSet: 3 </div>
<div style="display:none"> Gerrit-Owner: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@digium.com> </div>