Recording silence

[Kristian Høgh]

Hi group,

I use rtpengine-recording daemon to record calls in mixed mode.

When a channel is silent, nothing is recorded in the wave file.

Meaning the channels get out of sync.

I might do something wrong or I might misunderstand https://github.com/sipwise/rtpengine/blob/master/docs/rtpengine-recording.md

"Audio mixing takes RTP timestamping into account, so gaps and pauses in the RTP media are reflected in the output audio to keep the multiple audio sources in sync."

The codec used is g722 (transcoded from amr-wb).

When the codec from upstream is alaw we don't transcode and the recorded file is fine.

I get lots of lines like

rtpengine-recording[886500]: DEBUG: [C 5a481f89-0b5c-4dc1-8a43-500348e7e981-d349e9b485142872.meta] [S tag-1-media-1-component-1-RTP-id-0] [0xe1f4e90f] [core] [mix.c:302] pushing silence frame into stream 1 (28
80 < 3200)
rtpengine-recording[886500]: DEBUG: [C 5a481f89-0b5c-4dc1-8a43-500348e7e981-d349e9b485142872.meta] [S tag-1-media-1-component-1-RTP-id-0] [0xe1f4e90f] [core] [mix.c:302] pushing silence frame into stream 1 (30
40 < 3200)
rtpengine-recording[888805]: DEBUG: [C 19a358b7-2f73-4e66-82a9-aa8a09dd2a32-cad5783567f7da66.meta] [S tag-0-media-1-component-1-RTP-id-2] [0xe0c84806] [core] [mix.c:302] pushing silence frame into stream 1 (0
< 320)
rtpengine-recording[888805]: DEBUG: [C 19a358b7-2f73-4e66-82a9-aa8a09dd2a32-cad5783567f7da66.meta] [S tag-0-media-1-component-1-RTP-id-2] [0xe0c84806] [core] [mix.c:302] pushing silence frame into stream 1 (16
0 < 320)

rtpengine-recording is using the following options:
output-format=wav
output-single = false
output-mixed = true
mix-method = channels
resample-to=16000
mix-num-inputs = 2
output-mixed-per-media = false

Which info do I need to provide or how do I debug the problem?

Best regards,

Kristian Høgh

[Richard Fuchs]

On 01/09/2025 04.41, Kristian Høgh wrote:

I use rtpengine-recording daemon to record calls in mixed mode.

When a channel is silent, nothing is recorded in the wave file.

Meaning the channels get out of sync.

Not sure if this is relevant to your case, but silence audio fill-in happens not during the silent period, but rather when audio comes back, and/or when the delay becomes too large.

The codec used is g722 (transcoded from amr-wb).

When the codec from upstream is alaw we don't transcode and the recorded file is fine.

Have you tried other codecs? If it happens only with G.722 then that would indicate a bug in the G.722 processing. The fact that G.722 is special by advertising a clock rate that is off by a factor of 2 would be a likely candidate.

Which info do I need to provide or how do I debug the problem?

Best if you could narrow down the issue (e.g. confirm that it is in fact just with G.722) and then provide a minimal example that would reproduce the problem, e.g. with a pcap that contains RTP affected by it.

Even better of course would be if you could point out where in the code the problem lurks 🤡

Cheers

[Kristian Høgh]

Hi Richard,

Thanks for your answer. I can confirm the problem is in G.722 and opus.
I made two test calls and play a count from 1 to 20 (https://freesound.org/people/EnjoyPA/sounds/203066/)
One phone is put away between count from 6 to 15.
Both calls are around 23 seconds, and the resulting wave file have all talk, but the file is only around 12 seconds.

I attach ingress pcap, rtpengine log and wave file for each call.

On INVITE/SDP offer i call rtpengine_manage("metadata=anum:<phone>|bnum:<phone>")

On 200 OK/SDP answer i call rtpengine_manage("record-call=on metadata=anum:<phone>|bnum:<phone>")

 
[rtpengine-recording]
table = 0
flush-packets = true
log-level = 7
output-format = wav

output-single = false
output-mixed = true
mix-method = channels
resample-to = 16000
mix-num-inputs = 2
output-mixed-per-media = false

spool-dir = /var/spool/rtpengine
output-dir = /var/lib/rtpengine-recording
output-pattern = %Y%m%d/%Y%m%d-%H:%M:%S-%{anum}-%{bnum}-%t-%r-%c
notify-command=/usr/local/bin/rec-notify.sh

Regards,
Kristian Høgh
 

[Richard Fuchs]

This seems to be rather a case of the RTP timestamps in the received streams themselves being out of sync.

In both cases it looks like the timestamp increases by a fixed amount for each packet (160 for G.722 and 960 for Opus) regardless of how much time has actually elapsed between packets, or which real time the audio in the packet corresponds to.

So the timestamps from the packets are correctly taken into account, but since the timestamps don't correspond to real time, the mixed output is out of sync.

My guess is that it's a side effect of transcoding AMR without taking its DTX behaviour into account.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/66372795-bbd2-4540-83cc-9176aa994114n%40googlegroups.com.

[Kristian Høgh]

Thanks Richard
I am transcoding the call from AMR-WB to opus/G.722 in an rtpengine instance on the other side of an asterisk b2bua.
I call
rtpengine_manage("replace-origin codec-strip-all codec-transcode-opus codec-transcode-PCMA codec-except-telephone-event RTP/AVP");
or
rtpengine_manage("replace-origin codec-strip-all codec-transcode-G722 codec-transcode-PCMA codec-except-telephone-event RTP/AVP");

I have no dtx options enabled in rtpengine.conf:
[rtpengine]
...
# dtx-delay = 50
# max-dtx = 600
# dtx-buffer = 5
# dtx-lag = 100
# dtx-shift = 0
# amr-dtx = native
# dtx-cn-params = 60
# silence-detect = 0.05
# cn-payload = 60

Which DTX options do you think I should use?

Regards,
Kristian Høgh

[Richard Fuchs]

On 05/09/2025 03.55, Kristian Høgh wrote:

I have no dtx options enabled in rtpengine.conf:
[rtpengine]
...
# dtx-delay = 50
# max-dtx = 600
# dtx-buffer = 5
# dtx-lag = 100
# dtx-shift = 0
# amr-dtx = native
# dtx-cn-params = 60
# silence-detect = 0.05
# cn-payload = 60

Which DTX options do you think I should use?

You can start by just uncommenting these options, they should be reasonable defaults. Perhaps leave `silent-detect` commented out if you don't need it since it causes extra load.

Inspect the generated output RTP in Wireshark to see if it's clean. In particular the "skew" in the RTP analyser should not be increasing (much).

Cheers

[Kristian Høgh]

Thanks a lot, I'll give it a shot :-)