[asterisk-bugs] [JIRA] (ASTERISK-27056) codec_opus responds with incorrect RTP Payload Type
Alex Hermann (JIRA)
noreply at issues.asterisk.org
Tue Jan 11 05:13:06 CST 2022
[ https://issues.asterisk.org/jira/browse/ASTERISK-27056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257692#comment-257692 ]
Alex Hermann edited comment on ASTERISK-27056 at 1/11/22 5:12 AM:
------------------------------------------------------------------
Hi [~traud],
In your patch, is just destroying the payloads considered safe? I'm testing your patch (amongst others) on a system and I see crashes with unlocking the codecs_lock. Could it be your patch causes the payloads (including the lock) to be ripped away under some thread (or maybe even the same thread) still holding the codecs_lock?
I have not fully traced the crash yet, but below seems to occur on receiving early media RTP.
{code}
#1 0x0000556b15153fa4 in __ast_rwlock_unlock (filename=0x556b1528986b "rtp_engine.c", line=1073, func=0x556b1528ad50 <__PRETTY_FUNCTION__.16814> "ast_rtp_codecs_payload_code",
t=0x7f4e6a81c2e0, name=0x556b15289acc "&codecs->codecs_lock") at lock.c:823
res = 0
#2 0x0000556b151b9652 in ast_rtp_codecs_payload_code (codecs=0x7f4e6a81c2c0, asterisk_format=1, format=0x556b17765510, code=0) at rtp_engine.c:1073
type = 0x7f4e69037880
i = 8
payload = 8
__PRETTY_FUNCTION__ = "ast_rtp_codecs_payload_code"
#3 0x00007f4eea2b1f10 in ast_rtp_write (instance=0x7f4e6a81c0f8, frame=0x7f4f192e0088) at res_rtp_asterisk.c:4344
rtp = 0x7f4f1a0befe0
remote_address = {ss = {ss_family = 2, __ss_padding = "?\300\271`\224\211", '\000' <repeats 111 times>, __ss_align = 0}, len = 16}
format = 0x3f860f0fa707e425
codec = 0
__PRETTY_FUNCTION__ = "ast_rtp_write"
#4 0x0000556b151b721a in ast_rtp_instance_write (instance=0x7f4e6a81c0f8, frame=0x7f4f192e0088) at rtp_engine.c:520
res = 32591
__PRETTY_FUNCTION__ = "ast_rtp_instance_write"
#5 0x00007f4eecb49b3f in chan_pjsip_write (ast=0x7f4f1b13bd78, frame=0x7f4f192e0088) at chan_pjsip.c:880
channel = 0x7f4f1a02e6d8
pvt = 0x7f4f1afda7e8
media = 0x7f4f188f6838
res = 0
__PRETTY_FUNCTION__ = "chan_pjsip_write"
#6 0x0000556b150ca02a in ast_write (chan=0x7f4f1b13bd78, fr=0x7f4f192e0088) at channel.c:5630
res = -1
f = 0x7f4f192e0088
count = 0
hooked = 0
__PRETTY_FUNCTION__ = "ast_write"
#7 0x00007f4eec9347cb in wait_for_answer (in=0x7f4f1b13bd78, out_chans=0x7f4e6d1b2c40, to=0x7f4e6d1b28f8, peerflags=0x7f4e6d1b3790, opt_args=0x7f4e6d1b2fb0, pa=0x7f4e6d1b3050,
num_in=0x7f4e6d1b2c60, result=0x7f4e6d1b2900, dtmf_progress=0x0, ignore_cc=1, forced_clid=0x7f4e6d1b2c80, stored_clid=0x7f4e6d1b2cd0) at app_dial.c:1679
f = 0x7f4f192e0088
c = 0x7f4f2802c508
o = 0x7f4f28021390
pos = 2
<snipped the rest>
{code}
was (Author: gaaf):
Hi @traud,
In your patch, is just destroying the payloads considered safe? I'm testing your patch (amongst others) on a system and I see crashes with unlocking the codecs_lock. Could it be your patch causes the payloads (including the lock) to be ripped away under some thread (or maybe even the same thread) still holding the codecs_lock?
I have not fully traced the crash yet, but below seems to occur on receiving early media RTP.
{code}
#1 0x0000556b15153fa4 in __ast_rwlock_unlock (filename=0x556b1528986b "rtp_engine.c", line=1073, func=0x556b1528ad50 <__PRETTY_FUNCTION__.16814> "ast_rtp_codecs_payload_code",
t=0x7f4e6a81c2e0, name=0x556b15289acc "&codecs->codecs_lock") at lock.c:823
res = 0
#2 0x0000556b151b9652 in ast_rtp_codecs_payload_code (codecs=0x7f4e6a81c2c0, asterisk_format=1, format=0x556b17765510, code=0) at rtp_engine.c:1073
type = 0x7f4e69037880
i = 8
payload = 8
__PRETTY_FUNCTION__ = "ast_rtp_codecs_payload_code"
#3 0x00007f4eea2b1f10 in ast_rtp_write (instance=0x7f4e6a81c0f8, frame=0x7f4f192e0088) at res_rtp_asterisk.c:4344
rtp = 0x7f4f1a0befe0
remote_address = {ss = {ss_family = 2, __ss_padding = "?\300\271`\224\211", '\000' <repeats 111 times>, __ss_align = 0}, len = 16}
format = 0x3f860f0fa707e425
codec = 0
__PRETTY_FUNCTION__ = "ast_rtp_write"
#4 0x0000556b151b721a in ast_rtp_instance_write (instance=0x7f4e6a81c0f8, frame=0x7f4f192e0088) at rtp_engine.c:520
res = 32591
__PRETTY_FUNCTION__ = "ast_rtp_instance_write"
#5 0x00007f4eecb49b3f in chan_pjsip_write (ast=0x7f4f1b13bd78, frame=0x7f4f192e0088) at chan_pjsip.c:880
channel = 0x7f4f1a02e6d8
pvt = 0x7f4f1afda7e8
media = 0x7f4f188f6838
res = 0
__PRETTY_FUNCTION__ = "chan_pjsip_write"
#6 0x0000556b150ca02a in ast_write (chan=0x7f4f1b13bd78, fr=0x7f4f192e0088) at channel.c:5630
res = -1
f = 0x7f4f192e0088
count = 0
hooked = 0
__PRETTY_FUNCTION__ = "ast_write"
#7 0x00007f4eec9347cb in wait_for_answer (in=0x7f4f1b13bd78, out_chans=0x7f4e6d1b2c40, to=0x7f4e6d1b28f8, peerflags=0x7f4e6d1b3790, opt_args=0x7f4e6d1b2fb0, pa=0x7f4e6d1b3050,
num_in=0x7f4e6d1b2c60, result=0x7f4e6d1b2900, dtmf_progress=0x0, ignore_cc=1, forced_clid=0x7f4e6d1b2c80, stored_clid=0x7f4e6d1b2cd0) at app_dial.c:1679
f = 0x7f4f192e0088
c = 0x7f4f2802c508
o = 0x7f4f28021390
pos = 2
<snipped the rest>
{code}
> codec_opus responds with incorrect RTP Payload Type
> ---------------------------------------------------
>
> Key: ASTERISK-27056
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27056
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/CodecInterface, Core/General
> Affects Versions: 13.16.0
> Environment: x64 CentOS
> Reporter: Luke Escude
> Assignee: Unassigned
> Severity: Major
> Labels: patch
> Target Release: 14.0.0
>
> Attachments: asterisk_opus.txt, asterisk.pcap, grandstream.pcap, payload_dynamic_reINVITE.patch
>
>
> A phone call to an Opus extension works just fine (Asterisk sends an invite with 107 opus). Two-way audio and all that jazz.
> However, if the Asterisk endpoint puts the call on hold, then retrieves the call (the endpoint sends an INVITE to retrieve the call with 123 opus) Asterisk agrees to use 123 opus, however it continues to send 107 opus instead.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list