[asterisk-bugs] [JIRA] (ASTERISK-24410) res_pjsip_session: Deferred SDP Answer received in ACK is not actually processed

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-24410:
-----------------------------------

    Assignee: Matt Jordan
      Status: Waiting for Feedback  (was: Open)

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?

> res_pjsip_session: Deferred SDP Answer received in ACK is not actually processed
> --------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24410
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24410
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_session
>    Affects Versions: 12.6.0, 13.0.0-beta2
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>         Attachments: uac-declined-delayed.xml
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)