[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=257706#comment-257706 ] 

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

Actually, I copied {{ast_rtp_codecs_payloads_clear}}. Not sure, why I did not use it. {{ast_rtp_codecs_payloads_destroy}} is a public API used even in Asterisk itself, in the channel drivers SIP, PJSIP, MGCP, Motif, as destructor for an RTP engine, and the newly added Stream API. Consequently, this should be looked at first. It could be the cause for zillion of other issues not investigated that well, yet. If you are not planning to contact the mailing list, please say so. Because it is your finding, the honors are yours.

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