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

[lvl (JIRA)]

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

lvl commented on ASTERISK-27441:
--------------------------------

Thanks, that's providing some useful additional debug information.

{code}
[Nov 23 23:29:08] DEBUG[30326]: pjproject:0 <?>:                sip_ua_layer.c ...Received forked Response msg 200/INVITE/cseq=15621 (rdata0x7f492001f4d8) for existing dialog dlg0x7f4928072848
[Nov 23 23:29:08] DEBUG[30326]: pjproject:0 <?>:                sip_ua_layer.c ...Unhandled forked Response msg 200/INVITE/cseq=15621 (rdata0x7f492001f4d8), response will be handed over to the first dialog
[Nov 23 23:29:08] DEBUG[30326]: res_pjsip_session.c:3359 session_inv_on_state_changed: Source of transaction state change is RX_MSG
[Nov 23 23:29:08] DEBUG[30326]: res_pjsip_session.c:3204 handle_incoming: Received response
[Nov 23 23:29:08] DEBUG[30326]: res_pjsip_session.c:3188 handle_incoming_response: Response is 200 OK
[Nov 23 23:29:08] DEBUG[30326]: pjproject:0 <?>:             inv0x7f4928072848 ....Received forked final response after SDP negotiation has been done in early media. Renegotiating SDP..
[Nov 23 23:29:08] DEBUG[30326]: pjproject:0 <?>:             inv0x7f4928072848 ....Got SDP answer in Response msg 200/INVITE/cseq=15621 (rdata0x7f492001f4d8)
[Nov 23 23:29:08] DEBUG[30326]: pjproject:0 <?>:             inv0x7f4928072848 ....SDP negotiation done, status=0
[Nov 23 23:29:08] DEBUG[30326]: res_pjsip_session.c:798 handle_negotiated_sdp: Pending topology was NULL for channel 'PJSIP/proxy-0000000a'
[Nov 23 23:29:08] DEBUG[30326]: pjproject:0 <?>:             inv0x7f4928072848 ....Received Response msg 200/INVITE/cseq=15621 (rdata0x7f492001f4d8), sending ACK
{code}

Even though Asterisk might be doing the technically correct thing, I suspect it's not doing so for the right reasons.

As far as I can see, the 200's SDP is not explicitly discarded by Pjsip nor Asterisk based on the SDP version number. In fact, Pjsip appears to indicate that it's handling the SDP answer normally and is calling the on_media_update callback in Asterisk. The only thing blocking the SDP from being handled (which would re-start strict RTP learning thus fix the problem) is _session->pending_media_state->topology_ being NULL in _handle_negotiated_sdp_.

That brings me back to the original question: which code is normally responsible for creating a _pending_media_state->topology_ that isn't triggered in this specific scenario?

> 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
>            Assignee: Unassigned
>         Attachments: asterisk-sdpversion.log
>
>
> 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)