[Asterisk-code-review] res pjsip/rtp: No joint capabilities between streams. (asterisk[16])

[Benjamin Keith Ford]

Benjamin Keith Ford has uploaded this change for review. ( https://gerrit.asterisk.org/9832


Change subject: res_pjsip/rtp: No joint capabilities between streams.
......................................................................

res_pjsip/rtp: No joint capabilities between streams.

When a conference contained a mixture of audio/video and audio-only
users, a NOTICE message would pop up stating there are no joint
capabilities between streams. This happens because streams can never be
removed, but they can be in a REMOVED state. If we have the scenario
where user A joins with audio/video, user B joins with audio-only, and
user C joins with audio/video, then user A leaves, the message would
be triggered. That removed stream is still in the SDP, but Asterisk
would pass it through, causing it to be seen as a ulaw stream. A check
has been added for removed streams, setting their status to REMOVED when
handling negotiated SDPs.

Also addressed an issue where user A joins, then user B joins but does
not receive video until much later. Full frames were not being sent,
cuasing some PLI for the browser. Because the video was flowing in one
direction, the browser sets the SSRC to 1, but Asterisk was dropping the
PLI because of that. Added a check to see if the SSRC is 1 or not, which
sends full frames and allows video to flow between user A and user B.

ASTERISK-27398

Change-Id: I26e7c6f101bc119549eeca406b5bcd25ad8ebc5e
---
M res/res_pjsip_session.c
M res/res_rtp_asterisk.c
2 files changed, 10 insertions(+), 1 deletion(-)



  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/32/9832/1

diff --git a/res/res_pjsip_session.c b/res/res_pjsip_session.c
index 1300850..fdbdb72 100644
--- a/res/res_pjsip_session.c
+++ b/res/res_pjsip_session.c
@@ -930,6 +930,15 @@
 		session_media = AST_VECTOR_GET(&session->pending_media_state->sessions, i);
 		stream = ast_stream_topology_get_stream(session->pending_media_state->topology, i);
 
+		/* Make sure that this stream is in the correct state. If we need to change
+		 * the state to REMOVED, then our work here is done, so go ahead and move on
+		 * to the next stream.
+		 */
+		if (!remote->media[i]->desc.port) {
+			ast_stream_set_state(stream, AST_STREAM_STATE_REMOVED);
+			continue;
+		}
+
 		/* The stream state will have already been set to removed when either we
 		 * negotiate the incoming SDP stream or when we produce our own local SDP.
 		 * This can occur if an internal thing has requested it to be removed, or if
diff --git a/res/res_rtp_asterisk.c b/res/res_rtp_asterisk.c
index 074bcea..fe0cef0 100644
--- a/res/res_rtp_asterisk.c
+++ b/res/res_rtp_asterisk.c
@@ -5802,7 +5802,7 @@
 		}
 
 		if (ssrc_valid && rtp->themssrc_valid) {
-			if (ssrc != rtp->themssrc && use_packet_source) {
+			if (ssrc != rtp->themssrc && use_packet_source && ssrc != 1) {
 				/*
 				 * Skip over this RTCP record as it does not contain the
 				 * correct SSRC.  We should not act upon RTCP records

-- 
To view, visit https://gerrit.asterisk.org/9832
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-MessageType: newchange
Gerrit-Change-Id: I26e7c6f101bc119549eeca406b5bcd25ad8ebc5e
Gerrit-Change-Number: 9832
Gerrit-PatchSet: 1
Gerrit-Owner: Benjamin Keith Ford <bford at digium.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180807/00b387c0/attachment-0001.html>