[asterisk-bugs] [JIRA] (ASTERISK-27441) PJSIP: Need ignoresdpversion option that chan_sip has for parity.

[lvl (JIRA)]

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

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

Just adding to highlight that the outbound INVITE is forked by the remote party - as indicated by the separate to-tag for the 183 and the 200 responses. Since that makes them separate dialogs, you could argue that there are two separate SDP sessions as well where the version check shouldn't apply.

If you look at the pjproject debug lines, it appears to realise as much ("Unhandled forked Response msg, response will be handed over to the first dialog" - see https://trac.pjsip.org/repos/ticket/657) and process the SDP normally. I did look at the code and couldn't find any indication that Asterisk (chan Pjsip) is performing SDP version checks for itself.

That still leads me to believe that the problem is caused by something else.

> PJSIP: Need ignoresdpversion option that chan_sip has for parity.
> -----------------------------------------------------------------
>
>                 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.txt
>
>
> 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)