[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:
-----------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

> 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: Joshua Colp
>         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)