Hello we’re currently working with a vendor to add a 16kHz sampled codec to their hardware, but we’re experiencing duplicate DTMF digits when used in conjunction with asterisk 13. Looking at the relevant code they appear to be interpreted as “new” digits here , and removing that code works around the issue.
Having examined the RTP events they’re being sent with a duration of 160ms, however as they share the SSRC with the RTP stream I’d expect them to share the same clocking with a 16kHz sample rate and a duration of 320ms. The vendor is insisting that they’re compliant with the RFC, but my interpretation is they should be offering and using rtp-events with a 16khz sample rate - this is how endpoints from other vendors are handling it.
Does anyone have any experience with this kind of issue, or input on how the RFC should be interpreted?
There is supposed to be 8kHz and 16kHz in the SDP, and then depending on which codec is in use the respective one is used for DTMF. Asterisk 13, and chan_sip, have no such support. It was somewhat recently added to chan_pjsip[1].
Named telephone events are carried as part of the audio stream and
MUST use the same sequence number and timestamp base as the regular
audio channel to simplify the generation of audio waveforms at a
gateway. The named telephone-event payload type can be considered to
be a very highly-compressed audio codec and is treated the same as
other codecs.
If you want further details I’ll have to ask the person who did the work when they return next week, or you can dig through the RFC and comments online sooner.
On my first pass at adding multi-rate dtmf to Asterisk, (current Asterisk versions, pjsip only as @jcolp indicated) I read the specification as not allowing a mismatch in bit rates between the audio and dtmf - so in your example, RTP event digits would only be used if the negotiation settled on the matching PCMA.
In practice what it actually looks like to send different rate packets within the same stream isn’t really clear… but after that change the reporter(s) indicated it resolved their issue.
If possible, I would try using the latest Asterisk 20 (or newer) release with pjsip to see if this works with the vendor implementation. If it doesn’t, if you can supply a pcap with the mixed rtp stream we can test it locally and figure out where to go from there.
