[Asterisk-code-review] res pjsip session: properly handle SDP from a forked call wi... (asterisk[master])

Jenkins2 asteriskteam at digium.com
Mon Mar 12 07:23:27 CDT 2018


Jenkins2 has submitted this change and it was merged. ( https://gerrit.asterisk.org/8379 )

Change subject: res_pjsip_session: properly handle SDP from a forked call with early media
......................................................................

res_pjsip_session: properly handle SDP from a forked call with early media

In handle_negotiated_sdp(), use session->active_media_state when
session->pending_media_state is empty.  The 200's SDP should be fed into
handle_negotiated_sdp_session_media() together with the already negotiated
state, which is now in session->active_media_state instead.  Only if both
the session's pending and active media are empty should
handle_negotiated_sdp() abort.

ASTERISK-27441

Change-Id: If0d5150ffe6f38d8a854831fef37942258d4629c
---
M res/res_pjsip_session.c
1 file changed, 23 insertions(+), 8 deletions(-)

Approvals:
  Richard Mudgett: Looks good to me, but someone else must approve
  Joshua Colp: Looks good to me, approved
  Jenkins2: Approved for Submit



diff --git a/res/res_pjsip_session.c b/res/res_pjsip_session.c
index fcd190b..f252017 100644
--- a/res/res_pjsip_session.c
+++ b/res/res_pjsip_session.c
@@ -876,15 +876,30 @@
 	struct ast_stream_topology *topology;
 	unsigned int changed = 0;
 
-	/* This situation can legitimately happen when an SDP is received in a
-	 * 183 Session Progress message.  In that case, everything's been done
-	 * by the time this function is called and there are no more pending
-	 * streams.
-	 */
 	if (!session->pending_media_state->topology) {
-		ast_debug(1, "Pending topology was NULL for channel '%s'\n",
-			session->channel ? ast_channel_name(session->channel) : "unknown");
-		return 0;
+		if (session->active_media_state->topology) {
+			/*
+			 * This happens when we have negotiated media after receiving a 183,
+			 * and we're now receiving a 200 with a new SDP.  In this case, there
+			 * is active_media_state, but the pending_media_state has been reset.
+			 */
+			struct ast_sip_session_media_state *active_media_state_clone;
+
+			active_media_state_clone =
+				ast_sip_session_media_state_clone(session->active_media_state);
+			if (!active_media_state_clone) {
+				ast_log(LOG_WARNING, "Unable to clone active media state for channel '%s'\n",
+					session->channel ? ast_channel_name(session->channel) : "unknown");
+				return -1;
+			}
+
+			ast_sip_session_media_state_free(session->pending_media_state);
+			session->pending_media_state = active_media_state_clone;
+		} else {
+			ast_log(LOG_WARNING, "No pending or active media state for channel '%s'\n",
+				session->channel ? ast_channel_name(session->channel) : "unknown");
+			return -1;
+		}
 	}
 
 	/* If we're handling negotiated streams, then we should already have set

-- 
To view, visit https://gerrit.asterisk.org/8379
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-MessageType: merged
Gerrit-Change-Id: If0d5150ffe6f38d8a854831fef37942258d4629c
Gerrit-Change-Number: 8379
Gerrit-PatchSet: 5
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Reviewer: lvl <digium at lvlconsultancy.nl>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180312/c65a785f/attachment-0001.html>


More information about the asterisk-code-review mailing list