[asterisk-bugs] [JIRA] (ASTERISK-27441) No audio after early media from external endpoint

[lvl (JIRA)]

lvl created ASTERISK-27441:
------------------------------

             Summary: No audio after early media from external endpoint
                 Key: ASTERISK-27441
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27441
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_pjsip
    Affects Versions: 15.1.2
            Reporter: lvl


The scenario:

1. Asterisk dials outbound using chan_pjsip
2. The remote party sends an 183, with IP address 1.2.3.4 in the SDP *1
3. RTP is now flowing between Asterisk and 1.2.3.4
4. The remote party sends a 200, with a *new* IP address 5.6.7.8 in the SDP *2
5. Asterisk is not applying the new SDP details. 5.6.7.8 will start sending RTP to Asterisk, which is rejected:

{code}
[Nov 22 14:29:48] DEBUG[8280][C-00000001]: res_rtp_asterisk.c:5743 ast_rtp_read: 0x7f021c0286e0 -- Received RTP packet from 5.6.7.8:9898, dropping due to strict RTP protection.
{code}

The following log lines hint at the root cause:

{code}
[Nov 22 14:29:46] DEBUG[8237]: res_pjsip_session.c:3187 handle_incoming: Received response
[Nov 22 14:29:46] DEBUG[8237]: res_pjsip_session.c:3171 handle_incoming_response: Response is 200 OK
[Nov 22 14:29:46] DEBUG[8237]: res_pjsip_session.c:798 handle_negotiated_sdp: Pending topology was NULL for channel 'PJSIP/proxy-00000001'
{code}

The message is triggered by the code in https://github.com/asterisk/asterisk/blob/15.1/res/res_pjsip_session.c#L796. Because there is no "session->pending_media_state->topology" at this point, the *handle_negotiated_sdp* function is aborted and RTP from the new IP address is ignored as the session is not moved to the STRICT_RTP_LEARN state.

This behavior was introduced in commit https://github.com/asterisk/asterisk/commit/40de3a12e0caddec0be31aa4ad996c22fc716be5. Reverting that code will however cause Asterisk to segfault on the scenario as described.

It's not clear to me yet why *session->pending_media_state->topology* is null in this scenario, as opposed to all other scenarios where SDP is updated for an existing session.

*1
{code}
SIP/2.0 183 Session Progress

v=0
o=root 1910284739 1910284739 IN IP4 1.2.3.4
c=IN IP4 1.2.3.4
{code}

*2
{code}
SIP/2.0 200 OK

v=0
o=root 4067 4067 IN IP4 5.6.7.8
c=IN IP4 5.6.7.8
{code}



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