[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:all-tabpanel ]

Alexander Traud updated ASTERISK-27056:
---------------------------------------

    Attachment: payload_dynamic_reINVITE.patch

I am able to reproduce this consistently in Asterisk 13 with both SIP channel drivers, chan_sip and pjsip_sip, even with {{directmedia=no}}, even with any dynamic payload type, not only the Opus Codec. Consequently, this affects all media formats which do not have a static payload type [assigned|https://www.iana.org/assignments/rtp-parameters]. In the world of Asterisk, those are G.726-32, iLBC, Speex and the optional Codec2, SiLK, Siren, GSM-EFR, AMR, AMR-WB, 3GPP-EVS, and Opus Codec.

Again direct media is disabled. However, a re-iNVITE from the remote party is required. For example, Asterisk offers the call, the remote party answers the call, and then the remote party puts the call on hold by sending a re-INVITE (see [RFC 5359 Section 2.1|https://datatracker.ietf.org/doc/html/rfc5359#section-2.1]). In that re-INVITE, the remote party does not re-use the dynamic payloads of the SDP offer from Asterisk but uses its own. In that re-INVITE, the payload type is higher than it was in the previous SDP transaction. Finally, the remote party has no other payload type which overwrites the payload type used in the previous SDP transaction. With chan_sip, the problem is {{ast_rtp_codecs_payload_code}}.

Example, which is broken:
# Asterisk offers a call with Opus Codec at payload type 107.
# Unify answers that call with Opus Codec at payload type 107.
# Unify puts the call on hold.
# Unify unholds the call, with an SDP offer with Opus Codec at payload type 124.

Although the Unify expects RTP frames on payload type 124, Asterisk sends its RTP frames with payload type 107.

Example, which works:
# Asterisk offers a call with Opus Codec at payload type 107.
# Unify answers that call with Opus Codec at payload type 107.
# Unify puts the call on hold.
# Unify unholds the call, with an SDP offer with Opus Codec at payload type 106.

Now, Asterisk uses 106 because that is the first Opus Codec it has in its internal list.

Example, which works:
# Asterisk offers a call with Opus Codec at payload type 107.
# Unify answers that call with Opus Codec at payload type 107.
# Unify puts the call on hold.
# Unify unholds the call, with an SDP offer with Opus Codec at payload type 124 and iLBC at payload type 107

Now, Asterisk uses 124 because its previous Opus Codec was overwritten by iLBC.

There are many more examples that simply work, showing how impossible derivation is in the world of SIP and SDP:
* Although it works with many phones, the concept was broken in Asterisk.
* Although it does not work with just a few phones, those phones are not to blame but Asterisk.

*Workaround A*
One workaround is to use the payload types, Asterisk is using. For example, if you configure your phone to send Opus Codec at 107, no issue arises. This is possible in Polycom UC and Grandstream.

*Workaround B*
Another workaround for the phone is to re-use the payload types of the previous session. For example, if the call was established with Opus Codec at 107, the phone continues to use that payload type even in a re-INVITE. 

*Workaround C*
Another workaround for the phone is to start at the lowest possible payload type (96) and have no gaps in the types. For example, all types from 96 to 124 are used, then the phone can use payload type 125 for Opus Codec because Asterisk overwrote all its previous assignments.

Many of my phones use the latter two strategies. Of mine, the relatively new ALE Cloud Edition and Unify, which added Opus Codec just months ago, were not fixable. However, more platforms are expected to be affected. Actually, when manually increasing the default payload type for Opus Codec of a Digium D phone, even that platform is affected.

*Solution A*
One solution in Asterisk is to delete all assignments when a re-INVITE arrives; see the attached patch {{payload_dynamic_reINVITE.patch}}. This does not fix another issue: When the remote party answers the call with a different, higher payload type, Asterisk is still sending with its lower one.

*Solution B*
As [~fortytwo] mentioned, another solution is to use Asterisk 14 or newer because that uses two lists, one for sending aka transmission (TX) and one for expecting aka receiving (RX), see [commit 1a549ed|https://github.com/asterisk/asterisk/commit/1a549ed]. That is just one part of the change. Over the years, at least three changes have been made around this. So backporting that is not so easy.

@ Bug Marshals
Because Asterisk 13 receives no bug fixes anymore, just security fixes, and because this issue is believed to be fixed since Asterisk 14, please, consider to close this issue here. For those forced to use Asterisk 13, like me, have a look at my attached patch.

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