traud / asterisk-evs Goto Github PK

The patch for rtp_engine.c is :
--- main/rtp_engine.c (Asterisk 13.13.1)
+++ main/rtp_engine.c (working copy)
@@ -2307,2 +2307,4 @@
add_static_payload(107, ast_format_opus, 0);
+

•   ast_rtp_engine_load_format(ast_format_evs);
  

Fuzz of 1 causes this to misapply in Asterisk 18.

Changing the line numbers to:
@@ -3720,2 +3720,4 @@

before applying the patch is necessary for Asterisk 18.

Hello!

As stated in the README, AMR-WB IO is not supported. However, I wonder a bit how this would work in Asterisk. I've not found much details regarding how clients behave.

Will this primarily be a change in res_format_attr_evs.c or the codec module itself?
For example, will the EVS decoder produce AMR-WB frames instead of slin?

The last versions of the RI being compatible are:

• 12.12.0
• 13.8.0
• 14.4.2
• 15.2.2
• 16.1.0

Those versions are still available at ETSI and 3GPP, and the module builds/works just fine with one of those.

However, the RI saw a major change request in September 2021. As a side-effect, that changed/extended the API of read_indices_from_djb(…) with three more parameters. Consequently, this project here does not build with the very latest versions of the RI. I have still to investigate whether

• I have to use those new parameters (= complex, meaningful values), or
• I can simply define those (= static values), or
• that avoids a long-standing issue with unneeded double shuffling in the mode AMR-IO (and therefore not just different parameters but a completely different code flow in my Asterisk module).

Although I consider that Change Request critical security-wise, although I know that

• Digium Asterisk within an IMS, or
• Digium Asterisk with guest access enabled,

an audio-codec implementation is exposed to the public, I do not fix but just note this issue for now. If you need an urger fix for this, please, give this issue report a thumps-up or contact me directly so I know that anyone still uses this module.

Patch installed on Red Hat 8.8. Asterisk version is 16.18.0. In core show codecs EVS exists, but do not see him in translation list

asterisk16_vm_1 -rx "core show codecs" | grep evs 3 audio evs evs (3GPP EVS)

` Translation times between formats (in microseconds) for one second of data
Source Format (Rows) Destination Format (Columns)

        amr amrwb  ulaw  alaw   gsm  g726 g726aal2 adpcm slin8 slin12 slin16 slin24 slin32 slin44 slin48 slin96 slin192 lpc10  ilbc  g722 testlaw
  amr     - 23000 15000 15000 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250   15000
amrwb 23500     - 23500 23500 23500 23500    23500 23500 17500  17500   9000  17000  17000  17000  17000  17000   17000 23500 23500 15000   23500
 ulaw 15000 23000     -  9150 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250   15000
 alaw 15000 23000  9150     - 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250   15000
  gsm 15000 23000 15000 15000     - 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250   15000
 g726 15000 23000 15000 15000 15000     -    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250   15000

g726aal2 15000 23000 15000 15000 15000 15000 - 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 17250 15000
adpcm 15000 23000 15000 15000 15000 15000 15000 - 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 17250 15000
slin8 6000 14000 6000 6000 6000 6000 6000 6000 - 8000 8000 8000 8000 8000 8000 8000 8000 6000 6000 8250 6000
slin12 14500 14000 14500 14500 14500 14500 14500 14500 8500 - 8000 8000 8000 8000 8000 8000 8000 14500 14500 14000 14500
slin16 14500 6000 14500 14500 14500 14500 14500 14500 8500 8500 - 8000 8000 8000 8000 8000 8000 14500 14500 6000 14500
slin24 14500 14500 14500 14500 14500 14500 14500 14500 8500 8500 8500 - 8000 8000 8000 8000 8000 14500 14500 14500 14500
slin32 14500 14500 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 - 8000 8000 8000 8000 14500 14500 14500 14500
slin44 14500 14500 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 - 8000 8000 8000 14500 14500 14500 14500
slin48 14500 14500 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 - 8000 8000 14500 14500 14500 14500
slin96 14500 14500 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 8500 - 8000 14500 14500 14500 14500
slin192 14500 14500 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 8500 8500 - 14500 14500 14500 14500
lpc10 15000 23000 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 - 15000 17250 15000
ilbc 15000 23000 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 - 17250 15000
g722 15600 15000 15600 15600 15600 15600 15600 15600 9600 17500 9000 17000 17000 17000 17000 17000 17000 15600 15600 - 15600
testlaw 15000 23000 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 17250 -`

When Asterisk started the call but the remote party sends a re-INVITE on the SIP layer, the call might face one-way audio. One such a call scenario is call hold, for example. One-way audio happens because this codec here uses a dynamic RTP payload type in SDP negotiation, which Asterisk 13 LTS does not support correctly. Complete details are documented in ASTERISK-27056. Even if you are not affected, applying the patch provided there is recommended for any user. If you face an issues with that patch, report in ASTERISK-27056, please. If possible, consider upgrading to a newer Asterisk branch.

Although there is no limitation to force continuous transmission anymore (dtx=0), DTX is still not recommended for Asterisk. Asterisk does not generate Comfort Noise (CNG) while decoding SID frames of EVS. You hear nothing on the non-EVS side of the call. Because of this, the call quality would suffer with DTX. Because of this, dtx=0 remained in force_limitations.patch.

However with the latest release of 3GPP TS 26.445, a new section was introduced (A.3.3.3). With that new section, dtx=0 is not allowed for Asterisk as SDP answerer, when the SDP offerer stated dtx-recv=1. To avoid any incompatibilities but still cope with the fact that Asterisk does not have a CNG, force_limitations.patch should be changed from dtx=0 to dtx-recv=0.

Even then, one incompatible case remains: When the SDP offerer states dtx=1, Asterisk (the SDP answerer) should cope with DTX (= is not allowed to answer with dtx-recv=0). Consequently with dtx=1, the offerer does not ask for but requests DTX. This implies that all implementations have a CNG, which Asterisk does not have. Furthermore, this new section adds another state, a third state, to the DTX parameter:

• not present (not included in SDP)
• 1
• 0

Previously, ‘not present’ had the same semantic as ‘1’. Now, 1 requests DTX. Furthermore, any party should be able to control the receiving of DTX via dtx-recv=0. However with this new section, when the SDP offerer asks for dtx=1, Asterisk has to cope with incoming DTX.

It is believed that this is a regression introduced into the specification. Therefore, this is going to be discussed with the respective 3GPP working group. Until this is resolved, Asterisk still sends dtx-recv=0 even when dtx=1 was received. Nevertheless as stated in the second paragraph, force_limitations.patch can be changed from dtx=0 to dtx-recv=0 which avoids incompatibilities in other cases.

Hello!

Samsung (at least Galaxy S7) do not accept "evs/16000" in lower-case.
All documentation I've seen has EVS in upper-case. However, I do not know if that's required.

Adding this line to rtp_engine.c did the trick:
set_next_mime_type(ast_format_evs, 0, "audio", "EVS", 16000);

Have you had the opportunity to test ?