order of flag impact to rtpengine

[Myng]

Hi Richard, 

I'm implementing honoring codec priority from client,
I'm not sure some how below flag it work for single call, but with highload rtpengine repeatedly restart after 1-2hours
codec-strip=G722 codec-transcode=opus codec-transcode=PCMA codec-transcode=PCMU codec-offer=telephone-event codec-accept-pcma

my flag oder before like and i did not get any issue with this (whenever I switch back to above setting, i got the issue)

codec-strip=G722 codec-accept-opus codec-transcode=opus codec-transcode=PCMA codec-transcode=PCMU codec-offer=telephone-event

Do the order of flags have an impact to rtpengine behaviour?  Could you please give some ideas on how to troubleshoot this?

Looking forward to hearing from you

[Richard Fuchs]

No, the order of flags should not may a difference (with some exceptions, e.g. codecs requested for transcoding will be presented in the order given).

The two flags strings are not equivalent though, one lists `codec-accept-pcma` and the other lists `codec-accept-opus`

You need to explain what "repeatedly restart" means. Does it crash? If so, you should have a core dump. As always, pull it up in gdb and post a full back trace together with all other relevant information (most importantly the version).

Cheers

[Myng]

Thanks Richard for quick answer. 

"repeatedly restart" I mean rtpengine restarted every 1-2 hours (depend on the load, 20 - 30 minutes in busy hour  ) and it restarted without any error print out.

I run with version mr11.5.1.2

this is log in at the time rtpengine restart, I think it crash but no error or coredump found then I can't say (if possible can you point me the document show me how to enable & collect codedump?)

2025-08-22T14:23:43.568208+00:00 rtpproxy-b1 rtpengine[2340916]: INFO: [4tqdgjl6ub4cqk10ns5m]: [control] Replying to 'delete' from 10.10.10.111:61306 (elapsed time 0.000237 sec)

2025-08-22T14:23:43.845343+00:00 rtpproxy-b1 rtpengine[2340916]: INFO: [ItNnsCEp9Z]: [control] Received command 'answer' from 10.10.10.111:3446

2025-08-22T14:23:49.126420+00:00 rtpproxy-b1 rtpengine[2341467]: INFO: [crypto] Generating new DTLS certificate

2025-08-22T14:23:49.170088+00:00 rtpproxy-b1 rtpengine[2341472]: INFO: [core] Startup complete, version mr11.5.1.2

2025-08-22T14:23:49.170975+00:00 rtpproxy-b1 rtpengine[2341472]: INFO: [http] Websocket listener thread running

2025-08-22T14:24:02.147365+00:00 rtpproxy-b1 rtpengine[2341472]: INFO: [http] HTTP GET from 127.0.0.1:34004: '/cli/list totals'

2025-08-22T14:24:02.147538+00:00 rtpproxy-b1 rtpengine[2341472]: INFO: [control] Got CLI command: list totals

[Richard Fuchs]

On 23/08/2025 05.07, Myng wrote:

"repeatedly restart" I mean rtpengine restarted every 1-2 hours (depend on the load, 20 - 30 minutes in busy hour  ) and it restarted without any error print out.

Well it doesn't just restart on its own. Something must make it restart, and for some good reason.

I run with version mr11.5.1.2

That's quite old on the 11.5 branch. You should update.

this is log in at the time rtpengine restart, I think it crash but no error or coredump found then I can't say (if possible can you point me the document show me how to enable & collect codedump?)

I can't tell you that because it depends on your system. On a modern systemd based system for example (and assuming you're running rtpengine under systemd) it might need installation and/or enabling of the systemd-coredump service. Consult the documentation of your distro/vendor.

Cheers

[Myng]

Hi Richard, 

I just tested and found that `codec-accept-pcma` is an invalid,  the correct one should be `codec-accept-PCMA`. (coincidentally,  as black box testing, the behavior is the same as expected. )
Do you think it could be the cause of the crash rtpengine? 

[Richard Fuchs]

On 24/08/2025 11.58, Myng wrote:

I just tested and found that `codec-accept-pcma` is an invalid,  the correct one should be `codec-accept-PCMA`. (coincidentally,  as black box testing, the behavior is the same as expected. )
Do you think it could be the cause of the crash rtpengine?

I really don't know. The way to find out is to look at the core dump.

Cheers

[Myng]

Hi Richard, 
I attached the output of `gdb -batch -ex "thread apply all bt full"`, It seems something with RTCP/SRTP and not related to codec-accept flag, 
Could you please have a look. I'm appreciate your help 

[Richard Fuchs]

This looks like what has been fixed by commit b56d11ea1 and subsequent related commits. As I said before, you should update.

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/CAGBhiAnCLXTjtTJs%2BAdwXW7mX7V%2BnT3Wqp5O4X62kcr7d-OdVw%40mail.gmail.com.

[Myng]

Hi Richard,  

Firstly, I’d like to thank you for your advice and support.

We tested the latest version 13.3.1.4, and it appears that the crash issue has been resolved. However, we are now experiencing a major problem with audio quality.
Both 13.3.1.4 and version 12 significantly degrade audio quality when transcoding between Opus and PCMA, even with only one active call. Specifically:

• Outbound RTP is delayed by more than 2 seconds.
• Audio exhibits crackling, sounding robotic.

There is no issue with version 11, or when transcoding is not used.
Do you have any insight into what might be causing this problem? I am not sure if any changes introduced in rtpengine 12/13 could be affecting this.

I am available to provide logs if needed, please let me know which logs would be most helpful.

Thanks again for your help.
Regards.

  

[Richard Fuchs]

On 04/09/2025 16.46, Myng wrote:

• Outbound RTP is delayed by more than 2 seconds.
• Audio exhibits crackling, sounding robotic.

There is no issue with version 11, or when transcoding is not used.
Do you have any insight into what might be causing this problem? I am not sure if any changes introduced in rtpengine 12/13 could be affecting this.

I am available to provide logs if needed, please let me know which logs would be most helpful.

That would be the first report of such serious issues, especially for an established LTS version.

Typically an investigation of audio problems involves enabling full debug logging and pulling a pcap off the wire and inspecting it. Wireshark can be very helpful in analysing RTP flows.

Ideally you'd be able to pinpoint where exactly the problem is before reporting it, or at least come up with a minimal example that allows one to reproduce it. That would be a lot more helpful than just posting raw logs and pcaps with a report of "audio is bad."

FTR the 11.5 branch also has the relevant fixes.

Cheers

[Myng]

Hello Richard,
RTPENGINE and client agreed to use OPUS, however wireshark shows  RTPENGINE sent PCMA, CLIENT sent OPUS.
Can I send pcap and rtpengine log privately to you if you require them for debugging? 


RTPENGINE v13: 

• OFFER

v=0

o=- 1757070846 1757070847 IN IP4 MY_SERVER_IP

s=-

t=0 0

m=audio 65270 RTP/AVP 96 8 0 97 101

c=IN IP4 MY_SERVER_IP

a=rtpmap:96 opus/48000/2

a=fmtp:96 useinbandfec=1

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:97 telephone-event/48000

a=fmtp:97 0-15

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=rtcp:65271

a=ptime:20

• OFFER

v=0

o=1746193290194-de9d3f150150-0001 3321 1053 IN IP4 192.0.2.1

s=Talk

c=IN IP4 192.0.2.1

b=AS:576

t=0 0

m=audio 7244 RTP/AVP 96 8 0 97 101

a=rtpmap:96 opus/48000/2

a=fmtp:96 useinbandfec=1

a=rtpmap:97 telephone-event/48000

a=rtpmap:101 telephone-event/8000

RTPENGINE v11: f008a5a2-0517-123f-acae-7a962613abe9

The issue does not happen on RTPENGINE 11

• OFFER

v=0

o=- 1757063533 1757063534 IN IP4 MY_SERVER_IP

s=-

c=IN IP4 MY_SERVER_IP

t=0 0

m=audio 44704 RTP/AVP 96 8 0 97 101

a=rtpmap:96 opus/48000/2

a=fmtp:96 useinbandfec=1

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:97 telephone-event/48000

a=fmtp:97 0-15

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=rtcp:44705

a=ptime:20

• ANSWER

v=0

o=1746193290194-de9d3f150150-0001 3389 1690 IN IP4 192.0.2.1

s=Talk

c=IN IP4 192.0.2.1

b=AS:576

t=0 0

m=audio 7242 RTP/AVP 96 8 0 97 101

a=rtpmap:96 opus/48000/2

a=fmtp:96 useinbandfec=1

a=rtpmap:97 telephone-event/48000

a=rtpmap:101 telephone-event/8000

[Myng]

Dear Richard, 
Just following up on my earlier question about rtpengine version 13. If you have a chance to share any guidance, it would be greatly appreciated.

Regards, 

[Richard Fuchs]

As I said, a minimal example to reproduce it would be a good start. The SDPs alone are not enough, the full set of flags would also be needed. It can all be found in the log with debugging enabled. The config file may also be relevant. Send what you have to the mailing list if you need help troubleshooting.

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/CAGBhiAkzr4RqHz8ikUMdnvR6dHzuuTzVV2UuQfJNskTg6ZP4cw%40mail.gmail.com.

[Myng]

Dear Richard, 

I attached an rtpengine config and log with debug. 
For minimal example, I think it should be:

A (offer PCMA only) ---> RTPENGINE (codec-strip=all codec-transcode=opus codec-transcode=PCMA codec-transcode=PCMU)  ---> B (answer with OPUS, PCMA, PCMU)

Thanks for your help again!

[Richard Fuchs]

On 11/09/2025 07.09, Myng wrote:

For minimal example, I think it should be:

A (offer PCMA only) ---> RTPENGINE (codec-strip=all codec-transcode=opus codec-transcode=PCMA codec-transcode=PCMU)  ---> B (answer with OPUS, PCMA, PCMU)

The crucial part actually is the `reuse-codecs` flag being used in the answer. It enables a different code path and as it turns out some flags were not being set there.

I'll have a fix submitted soon, but as a workaround I suggest you only use this flag when and if you really need it.

Cheers

[Myng]

Thanks so much Richards - please keep me posted,  
In the meantime, I will try your suggestion for work around

[Myng]

Hi Richard, 
Just want to update you, workaround fix the issue. 
May I ask you, if https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.8 include the "proper" fix? 

Regards,  

[Richard Fuchs]

The proper fix is https://github.com/sipwise/rtpengine/commit/176a834500b679be16d7ce18f1c120ce183d8326

It's included in 13.5, 13.4, 13.3, and 12.5, but not all of these branches have a tagged release yet. If you pull the branches from git you will have it included, but for prebuilt packages / tagged versions so far only 12.5.1.46+ has it included.

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/CAGBhiAkLvhfTQNeLXWwUDEOC%3DDHh8vJhdOCcQZDKSH0%3DiGDL2A%40mail.gmail.com.