Summary:	ASTERISK-24410: res_pjsip_session: Deferred SDP Answer received in ACK is not actually processed
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2014-10-10 09:09:49	Date Closed:	2015-02-14 18:47:56.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip_session
Versions:	12.6.0 13.0.0-beta2	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) uac-declined-delayed.xml
Description:	When an inbound {{INVITE}} request is received without an SDP, Asterisk correctly sends an initial SDP Offer in the {{200 OK}}. If an endpoint responds with an {{ACK}}, two things should occur: * If the SDP received in the {{ACK}} is valid, the Answer should be merged with the Offer to set the appropriate formats on the channel. * If the SDP received in the {{ACK}} is not valid (such as declining the media stream), or if no SDP is received in the {{ACK}}, the call should be torn down. As it stands, while the ACK is received in {{res_pjsip_session}}, the SDP is not processed. Hence, Asterisk uses whatever was sent in the Offer, and doesn't bother looking at the Answer. The attached SIPp scenario demonstrates this. The ACK contains an SDP that declines the only offered audio media stream, which should result in the call being hung up. Instead, Asterisk continues on, sending audio to a UA that just declined the audio stream.
Comments:	By: Joshua C. Colp (jcolp) 2015-02-14 14:41:17.442-0600 The attached SIPP scenario is actually incorrect. The SIP message in the ACK does not contain: Content-Type: application/sdp As a result the code ignores the contents. Fixing this causes it to behave as described. Should this remain open? By: Joshua C. Colp (jcolp) 2015-02-14 18:47:56.052-0600 I harassed Matt directly. He said nah, it can be closed. By: Friendly Automation (friendly-automation) 2017-05-17 10:42:24.122-0500 Change 5633 merged by Jenkins2: testsuite: Fix test because original issue was not a bug. [https://gerrit.asterisk.org/5633|https://gerrit.asterisk.org/5633]