Encoding/Transcoding issue for MoH

[Johanna Lämmel]

Hey all,

I am facing an issue for the encoding/transcoding of the MoH being played for an established call between and mo IMS UE and an offnet mt user using rtpengine version: 13.5.1.9+0~mr13.5.1.9.

The call is established and agreed transcoding is AMR-WB on the IMS UE side and G722 towards the offnet User.
Mo UE <-- AMR-WB --> RTPengine <-- G722 --> Mt Offnet User

Transcoding works perfectly fine for the Audio. Now when Mo UE triggers call hold towards the offnet user the RTPengine is playing back the configured audio file but sending it encoded as AMR-WB.

In the offer after re-invite all codecs offered from the UE are present again, so not only the agreed one from the  offer/answer of the initial invite.

I am not fully sure if it is an issue in the offer sent from P-CSCF upon receipt of the re-invite. But nonetheless the RTPengine starts playing the MoH on the offer, so before the answer from 200 OK of the re-invite arrives. Shouldn't it be using the agreed codec?

Attaching the RTPengine debug logs for reference. 

Please let me know if any more information is needed.

Best,
Johanna

[Richard Fuchs]

On 11/09/2026 07.10, Johanna Lämmel wrote:
> I am not fully sure if it is an issue in the offer sent from P-CSCF
> upon receipt of the re-invite. But nonetheless the RTPengine starts
> playing the MoH on the offer, so before the answer from 200 OK of the
> re-invite arrives. Shouldn't it be using the agreed codec?

I haven't checked, but I guess that the new set of codecs from the
re-invite offer is consumed first, and then the MoH is started, which
now sees AMR-WB as the first codec.

This isn't specific to MoH but can happen during a normal re-invite too,
but it would be very temporary, as the answer would then very quickly
get the codecs back on track.

This can definitely be improved (for both cases), but in the meantime
you can use one of the existing flags to prevent or discourage codec
renegotiation. I believe `static-codecs` is the appropriate flag for this.

Cheers

[Johanna Lämmel]

Thank you!

I finally have initial test results. With the statics-codec flag being sent on the re-invite offer this initial test went well.

Shall I open an issue for the improvment on github?

If you don't mind to cover it in this thread, one more question regarding the MoH:
I played around a bit with the file configuration. I understood from the documentation that the MoH capabilities  must be advertised in the initial offer to be added for the offerer side.
From the experiments I did so far I came to the conclusion that the file advertised in this initial offer cannot be changed later on with later offer/answer for the offerer side. 
Is that correct?
The use case is playing a certain soundfile based on user preferences which are not available when the initial offer is made.

Best,
Johanna

[Richard Fuchs]

On 15/09/2026 09.16, Johanna Lämmel wrote:
> Shall I open an issue for the improvment on github?

Not necessary, I'll track it internally.

> I played around a bit with the file configuration. I understood from
> the documentation that the MoH capabilities  must be advertised in the
> initial offer to be added for the offerer side.
> From the experiments I did so far I came to the conclusion that the
> file advertised in this initial offer cannot be changed later on with
> later offer/answer for the offerer side.

I'm not sure that's correct. It's not my own code, so I could be wrong,
but from reading the code it looks like the MoH flags get updated with
every offer/answer, not just the initial one.

It's always possible that something doesn't work correctly of course,
but in that case I'd say it's not intentional.

Cheers