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

Wed Nov 22 19:11:07 CST 2017

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

Richard Mudgett edited comment on ASTERISK-27441 at 11/22/17 7:10 PM:
----------------------------------------------------------------------

Yep.  The SDP version is not increased between the 183 Progress and the 200 OK response messages.  In fact they seems to have *no* relation to each other and the 200 OK's version is less than the 183 Progress message.

The SDP version is the third token after the '='.

The 183 Progress's version is {{1828559483}}
{noformat}
o=root 1828559483 1828559483 IN IP4 1.1.1.2
{noformat}
The 200 OK's version is {{4067}}
{noformat}
o=root 4067 4067 IN IP4 8.2.1.8
{noformat}

Please attach the log file of the call \[1] (verbose, debug and SIP messages included).  No shortcuts this time. :)  We need to see what Asterisk is thinking about the call and if the strictrtp learning is restarted when the 200 OK comes in.  Unless you have forced it otherwise, v15 uses bundled pjproject by default.  Are you using bundled?

\[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

P.S.  A pcap would also be good as we may need to see when the RTP streams switch to the new addresses in relation to the SIP messages.  The strictrtp learning only gives 1.5 seconds to learn a new address before locking to any learned address.

was (Author: rmudgett):
Yep.  The SDP version is not increased between the 183 Progress and the 200 OK response messages.  In fact they seems to have *no* relation to each other and the 200 OK's version is less than the 183 Progress message.

The SDP version is the third token after the '='.

The 183 Progress's version is {{1828559483}}
{noformat}
o=root 1828559483 1828559483 IN IP4 1.1.1.2
{noformat}
The 200 OK's version is {{4067}}
{noformat}
o=root 4067 4067 IN IP4 8.2.1.8
{noformat}

Please attach the log file of the call \[1] (verbose, debug and SIP messages included).  No shortcuts this time. :)  We need to see what Asterisk is thinking about the call and if the strictrtp learning is restarted when the 200 OK comes in.  Unless you have forced it otherwise, v15 uses bundled pjproject by default.  Are you using bundled?

\[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

> 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
>
> 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)