Telephone-Event not offered on fmtp mismatch

[Gustavo Almeida]

Hi Richard,

I hope you are doing well.

In using `Kamailio` as the middleware for `RTPEngine`, and using templates to achieve what i want. All works fine, but when i have a case where transcoding is applied, `telephone-event` is dropped from the `SDP`.

My templates in `rtpengine.conf`:

```sh
public-internal = transport-protocol=RTP/AVP codec-strip=all codec-except=PCMA,PCMU,telephone-event codec-transcode=g729,g722 replace-origin replace-session-connection via-branch=auto SDES-off direction=external direction=internal SIP-source-address
public-external = transport-protocol=RTP/AVP codec-strip=all codec-except=PCMA,PCMU,telephone-event codec-transcode=g729,g722 replace-origin replace-session-connection via-branch=auto SDES-off direction=internal direction=external SIP-source-address
```

And in `kamailio` i call the templates.

Example case:

Endpoint A offer:

```sh
m=audio 21326 RTP/AVP 8 0 9 3 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=ptime:20
```

RTPEngine offer to B:

```sh
m=audio 30002 RTP/AVP 8 0 18 9 101
c=IN IP4 xxx.xx.xx.xx
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 g729/8000
a=fmtp:18 annexb=yes
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:30019
a=ptime:20
```

B answer:

```sh
m=audio 30003 RTP/AVP 9 101
c=IN IP4 192.168.1.106
a=rtcp:30004
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
```

RTPEngine to A answer:

```sh
m=audio 30014 RTP/AVP 0
c=IN IP4 xxx.xx.xx.xx
a=sendrecv
a=rtcp:30015
a=ptime:20
```

If i avoid `G722` on B and use `PCMA,PCMU` all good.

Any hint to pass `telephone-event` in the `SDP` answer after transcoding?

---------

After some analysis, i take a look into `allow-asymmetric-codecs`, and have include them inside the templates.

But `rtpengine` seems to bypass it, no logs showing this parameter usage and RTP persists the same.

----------

versions:

- `rtpengine` -->  `14.1.1.5+0~mr14.1.1.5`;
- `kamailio` --> `6.0.5`;

[Ovidiu Sas]

Add 'codec-offer-telephone-event' to the list of flags.

-ovidiu

> --
> 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/6b55e8b0-6387-489d-aa93-df16dcefc8dbn%40googlegroups.com.

[Gustavo Almeida]

Hi,

Thank you for the reply.

Currently, i'm passing it via codec-except.

I can test your suggestion, but i think will result in the same.

I tried to use allow-symmetric-codecs, as seems to be the solution, because in the logs the telephone-event is removed because remote part declares 0-16 in fmtp instead of 0-15. But, rtpengine seems to disregard the parameter (allow-symmetric-codecs) on the template.

Thanks

You received this message because you are subscribed to a topic in the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtpengine/ugjrAhdi3Zw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/CAND0Lkvgu%2BnnDffgS-fG-S5oHYGQce9h30UhrOcsNP-fASx3OQ%40mail.gmail.com.

[Richard Fuchs]

On 14/04/2026 15.13, Gustavo Almeida wrote:
> public-external = transport-protocol=RTP/AVP codec-strip=all
> codec-except=PCMA,PCMU,telephone-event codec-transcode=g729,g722
> replace-origin replace-session-connection via-branch=auto SDES-off
> direction=internal direction=external SIP-source-address

The problem is that `codec-strip` is effective during an answer as well,
but `codec-transcode` is not. So these flags end up removing G.722 from
the answer SDP and not adding it back in, because it's not listed as
`except`, which leaves no codecs to work with.

Either list G.722 as `except` as well, or use different flags for offers
and answers.

Cheers

[Gustavo Almeida]

Ok, i see your point.

I'm using same templates for offer and answer, to make simpler the interaction between Kamailio and RTPEngine.

But, regarding your suggestion, it will work without passing allow-asymmetric-codecs? As telephone-event is my unique concern .

For curiosity do you recommend some improvements on my templates? Also, doing a separation of templates for offer and answer, makes more sense (if possible, i want to avoid different templates for answer and offer)?

[Richard Fuchs]

On 15/04/2026 10.06, Gustavo Almeida wrote:
> But, regarding your suggestion, it will work without passing
> allow-asymmetric-codecs? As telephone-event is my unique concern .

Yes it will. Your assumption was that the mismatched `fmtp` was the
reason for it being dropped, but that's not what was happening. It was
dropped because there was no codec left to associated it with.

> For curiosity do you recommend some improvements on my templates?
> Also, doing a separation of templates for offer and answer, makes more
> sense (if possible, i want to avoid different templates for answer and
> offer)?

Depends on what your goals ultimately are, but if you simply want to
allow G.722, then I would suggest to just add it as an `except` codec.

Cheers

[Gustavo Almeida]

Yes, i have tested again, and indeed it works.

Yes, my case is simple. I want to support PCMA, PCMU, G722 and G729 only for transcoding purposes (i don't want to offer it for my Freeswitch internal hop).

Based on this, i think passing G722 to except will solve my use-case, right? Or i'm missing something?

Thank you 

[Richard Fuchs]

On 15/04/2026 11.01, Gustavo Almeida wrote:
> Yes, i have tested again, and indeed it works.
>
> Yes, my case is simple. I want to support PCMA, PCMU, G722 and G729
> only for transcoding purposes (i don't want to offer it for my
> Freeswitch internal hop).
> Based on this, i think passing G722 to except will solve my use-case,
> right? Or i'm missing something?

Yes, that would be the correct way to do it 👍

Cheers

[Gustavo Almeida]

Thank you Richard.

Really nice your job and effort into this project.

Keep rocking.