Real telephone-event RTP payload type remapping — asymmetric PT per leg?

[David Escartín]

Hi,

I'd like to confirm whether rtpengine, running Version: 12.5.1.48+0~mr12.5.1.48 git-mr12.5.1-16dc953b, supports real RTP payload type rewriting for telephone-event / RFC 2833 DTMF while keeping DTMF as telephone-event on both legs.

Scenario:

UAC <-> Kamailio + rtpengine <-> UAS/provider

The UAC-facing leg negotiates telephone-event as PT 96, while the UAS/provider answers telephone-event as PT 101:

UAC leg: m=audio ... RTP/AVP 8 96 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 UAS leg: m=audio ... RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16

What I would like to achieve is RTP payload type rewriting per direction, while keeping DTMF as telephone-event:

UAC -> rtpengine (telephone-event PT=96) rtpengine -> UAS (telephone-event PT=101) UAS -> rtpengine (telephone-event PT=101) rtpengine -> UAC (telephone-event PT=96)

What I have observed / tried:

• In my current setup, rtpengine appears to handle telephone-event in passthrough mode, so passthrough alone does not seem to perform RTP payload type rewriting.
• In this specific case, the UAS renumbers telephone-event in the answer. I offer PT 96, but it answers with PT 101 and fmtp 0-16.
• rtpengine then drops it as a stray answer codec:

Not adding stray answer codec telephone-event/8000/0-16 (101)

• I have seen the allow-asymmetric-codecs option. My understanding is that it relaxes SDP-level validation, so the mismatched PT may not be discarded, but it does not rewrite the actual RTP payload type number in the media stream. Please correct me if that is wrong.
• My understanding is that DTMF transcoding mainly refers to telephone-event <-> in-band audio conversion. That is not what I want here. I want to keep DTMF as telephone-event on both legs and only remap the RTP PT.

Questions:

1. Is real RTP payload type remapping for telephone-event, while keeping it as telephone-event on both legs, supported by rtpengine?
2. If it is supported, which options should be used?
3. Does allow-asymmetric-codecs ever rewrite the RTP PT, or does it only affect SDP handling?
4. Would any combination such as codec-strip=telephone-event with codec-offer=telephone-event or codec-transcode=telephone-event make rtpengine own/regenerate the telephone-event stream and rewrite the PT per leg, or is that not how these options work?
5. If PT remapping is not supported, is the recommended approach to handle this at the B2BUA/SBC layer, or to fall back to in-band DTMF transcoding?
6. Is there any known workaround for this interop case where one leg uses telephone-event PT=96 and the other leg requires PT=101?

Thanks in advance.
david escartín

[Richard Fuchs]

To my knowledge, PT rewriting as such is not supported, although I could be wrong (there have been several contributed patches related to DTMF, but AFAIK none of them facilitated actual PT rewriting).

The "allow asymmetric codecs" flag merely allows passing through the mismatched PT numbers. It requires end UAs to support this: If a UA which has offered PT 96 is willing to accept PT 101, then DTMF should work.

DTMF rewriting is supported between codecs requiring different clock rates, say between PCMA/8000 and AMR-WB/16000, which will necessarily involve different PT numbers. But if the clock rate is identical then only strict pass-through without renumbering is supported.

The recommended solution is to fix the UA not to use hard-coded PT numbers. 😄

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/8dadcc73-7df4-4409-8c24-ed9717f5f355n%40googlegroups.com.

[David Escartín]

thanks a lot , we will test the flag allow asymmetric codecs flag

best regards

david