[asterisk-bugs] [JIRA] (ASTERISK-27441) No audio after early media from external endpoint
lvl (JIRA)
noreply at issues.asterisk.org
Thu Nov 23 18:47:07 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-27441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240244#comment-240244 ]
lvl edited comment on ASTERISK-27441 at 11/23/17 6:46 PM:
----------------------------------------------------------
Fair point. The two snippets I added are from an actual pjsip log, but I'll add a longer log below for reference. As you can see, while the 200's SDP version is different from the 180's, it's not increased by one but it's a random (lower) number. Would that be grounds for Asterisk to silently ignore the 200's SDP contents? (Even though it does in fact trigger a _session_inv_on_media_update_ and _handle_negotiated_sdp_)
{code}
<--- Transmitting SIP request (1019 bytes) to UDP:1.6.1.6:8065 --->
INVITE sip:user at dev.com:8065 SIP/2.0
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
v=0
o=- 1120527176 1120527176 IN IP4 1.6.1.6
s=Asterisk
c=IN IP4 1.6.1.6
t=0 0
m=audio 31640 RTP/AVP 9 8 0 3 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<--- Received SIP response (1010 bytes) from UDP:1.6.1.6:8065 --->
SIP/2.0 183 Session Progress
To: <sip:user at dev.com>;tag=VhNaFWijiHt
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
v=0
o=root 1828559483 1828559483 IN IP4 1.1.1.2
s=Mediaserver
c=IN IP4 1.1.1.2
t=0 0
m=audio 16944 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<--- Received SIP response (1062 bytes) from UDP:1.6.1.6:8065 --->
SIP/2.0 200 OK
To: <sip:user at dev.com>;tag=as66679d74
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
v=0
o=root 4067 4067 IN IP4 8.2.1.8
s=session
c=IN IP4 8.2.1.8
t=0 0
m=audio 30874 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<--- Transmitting SIP request (635 bytes) to UDP:1.6.1.6:8065 --->
ACK sip:user at 8.2.1.8 SIP/2.0
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
{code}
was (Author: lvl):
Fair point. The two snippets I added are from an actual pjsip log, but I'll add a longer log below for reference. As you can see, while the 200's SDP version is different from the 180's, it's not increased by one but it's a random (lower) number. Would that be grounds for Asterisk to silently ignore the 200's SDP contents? (Even though it does in fact trigger a _session_inv_on_media_update_ and _handle_negotiated_sdp_)
{code}
<--- Transmitting SIP request (1019 bytes) to UDP:1.6.1.6:8065 --->
INVITE sip:user at dev.com:8065 SIP/2.0
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
v=0
o=- 1120527176 1120527176 IN IP4 1.6.1.6
s=Asterisk
c=IN IP4 1.6.1.6
t=0 0
m=audio 31640 RTP/AVP 9 8 0 3 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<--- Received SIP response (1010 bytes) from UDP:1.6.1.6:8065 --->
SIP/2.0 183 Session Progress
To: <sip:0900 at asterisk.dev.com>;tag=VhNaFWijiHt
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
v=0
o=root 1828559483 1828559483 IN IP4 1.1.1.2
s=Mediaserver
c=IN IP4 1.1.1.2
t=0 0
m=audio 16944 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<--- Received SIP response (1062 bytes) from UDP:1.6.1.6:8065 --->
SIP/2.0 200 OK
To: <sip:0900 at asterisk.dev.com>;tag=as66679d74
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
v=0
o=root 4067 4067 IN IP4 8.2.1.8
s=session
c=IN IP4 8.2.1.8
t=0 0
m=audio 30874 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<--- Transmitting SIP request (635 bytes) to UDP:1.6.1.6:8065 --->
ACK sip:user at 8.2.1.8 SIP/2.0
Call-ID: d205d496-618d-4c70-98ee-b4269c8e15eb
{code}
> 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)
More information about the asterisk-bugs
mailing list