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

[Alex Hermann (JIRA)]

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

Alex Hermann commented on ASTERISK-27056:
-----------------------------------------

Thanks for looking into it. 

I think the easiest solution is to just empty the codecs list manually while holding the codecs_lock, and not call {{ast_rtp_codecs_payloads_destroy()}} at all. That way the lock will survive and there is guaranteed no other thread accessing the codec list. I'll see if I can cook up some patch, but don't hold your breath.

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