[asterisk-bugs] [JIRA] (ASTERISK-27056) codec_opus responds with incorrect RTP Payload Type

[Alexander Traud (JIRA)]

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

Alexander Traud commented on ASTERISK-27056:
--------------------------------------------

Puh. Good question. I recommend to escalate this question to the [mailing list for developers|http://lists.digium.com/mailman/listinfo/asterisk-dev] (and do not mention you still use Asterisk 13 because it is end-of-life, or you are about this issue here because it is closed – but ask more general). Sounds like a generic question to me. {{ast_rtp_codecs_payloads_destroy}} is a public function. There is no note in its Doxygen about this. And yes, I assumed it does not destroy if there is a lock still active. Looking at its code, on the first glance, it looks like it does destroy anyway, exactly as mentioned in your StackOverflow question. It calls ast_rwlock_destroy which calls pthread_rwlock_destroy.

If you enable {{DEBUG_THREADS}} in the compiler options via {{make menuselect}}, you might see more (afterwards you have to {{make clean}} and re-make). So, please, ask this on the mailing list to get other opinions or in-sights. Then, please, update here. Might be a bug in {{ast_rtp_codecs_payloads_destroy}}. Or might be a bug in my patch. In the latter case,
{code}
ast_rtp_codecs_payloads_destroy(dest);
ast_rtp_codecs_payloads_initialize(dest);
{code}
have to be moved not before but after the while loop. In any case, great finding, thanks for reporting!

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