[asterisk-bugs] [JIRA] (ASTERISK-29014) res_pjsip_session: Re-INVITE collisions aren't handled correctly

[Alexei Gradinari (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251648#comment-251648 ] 

Alexei Gradinari commented on ASTERISK-29014:
---------------------------------------------

Is it related to ASTERISK-28865?

> res_pjsip_session: Re-INVITE collisions aren't handled correctly
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-29014
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29014
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_session
>    Affects Versions: 13.35.0, GIT, 16.12.0, 17.6.0
>            Reporter: George Joseph
>            Assignee: George Joseph
>
> When both Asterisk and a UA send re-invites at the same time, both send 491 "Transaction in progress" responses to each other and back off a specified amount of time before retrying.   When Asterisk prepared to send its re-invite, it set up the session's pending media state with the new topology it wanted, then sent the re-invite.  When it received the re-invite from the UA, it partially processed the media in the re-invite and reset the pending media state _before_ sending the 491 losing the state it set in _its_ re-invite.   When the backoff timer expires and Asterisk it re-sends the re-invite it originally sent, the pending media state is empty and the re-invite's sdp shows the streams as dropped.
> Asterisk needs to do 2 things...
> * Respond with a 491 _before_ making any changes to the session and media state.
> * Save the media state when it queues the retry.



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