Play media and AMR(WB) codec

[russagit]

rtpengine version the issue has been seen with

12.4.1.7+0~mr12.4.1.7

Used distribution and its version

AlmaLinux 8.10

Linux kernel version used

4.18.0-553.5.1

CPU architecture issue was seen on (see uname -m)

x86_64

Expected behaviour you didn't see

We have a call between A and B with media passing through rtpengine (12.4.7.1) and with the same codec on both sides "AMR/8000/mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1; max-red=0".
Then during the call we need to block media toward B and play some media wav file to A.
In the log I see following after play media command:

[core] Output codec for media playback is AMR/8000
[codec] Creating SSRC transcoder from PCM-S16LE/8000/1 to AMR/8000/1
[internals] supported sample format for output codec libopencore_amrnb: s16
[internals] using output sample format s16 for codec libopencore_amrnb
[core] Using 5900 as initial AMR bitrate based on mode-set
[core] Initialized encoder with frame size 160 samples
[internals] supported sample format for input codec pcm_s16le: s16
[codec] Encoder created with clockrate 8000, 1 channels, using sample format 1 (ptime 20 for 160 samples per frame and 160 samples (40 bytes) per packet, bitrate 6700)
[codec] Created media playback context for PCM-S16LE/8000/ -> AMR/8000/mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1; max-red=0

After that A hears that playing media ok but in RTP dump I see that rtpengine keeps enconding rate constant during the whole playing (FT bits: AMR 5,90 kbit/s (2)) despite the fact that the peer CMR from A allows encoder to switch to a higher speed rate.
Please advice if it's possible for encoder to follow the CMR from the peer during play media.
It looks that the behaviour is the same with AMR-WB codec and it does not depend on rtpengine version, we tested also with 11.2.1.5.
Is there additional data I need to provide?

Unexpected behaviour you saw

No response

Steps to reproduce the problem

No response

Additional program output to the terminal or logs illustrating the issue

No response

Anything else?

No response

[rfuchs]

CMR should be honoured. Is this something specific to media playback? Is this a transcoding scenario or is AMR passthrough?

[russagit]

It is passthrough AMR from the call start, then after the "play media" command it becomes transcoding. Yes, the problem is specific to "play media" only

[russagit]

Is any additional information required from my side?

[rfuchs]

Actually I have to take back what I said earlier. In a passthrough scenario, CMR isn't currently honoured for media playback. Reason being that CMR is decoded by the AMR decoder, and in a passthrough scenario there is no AMR decoder. I believe there isn't even a way to set the encoding bit rate just for the media player, and so the default bit rate (6.7k for AMR, mode 3) would be used, or rather the next-lower allowed match in your case (mode 2).

Supporting CMR in this scenario might be difficult without a major rework, but at least setting the bit rate should be possible via a new option given to play_media, so that you could start your media playback at a desired higher bit rate.