CNG and DTMF #2
Description
Testing out the idea of opening a github issue for discussion.
All RIPP implementations MUST support G.711 and Opus audio codecs.
All implementations MUST support [RFC2833] for DTMF, and MUST support
[RFC3389] for comfort noise, for both sending and receiving.
DTMF my mortal enemy lol.
Would this just be an encapsulation of the RTP payloads? There is a bunch of stuff involving the duration of DTMF and so many implementations do it so horribly wrong. Most things inject the DTMF into the RTP media stream as its kind of one of those side cases of having multiple codecs in use at the same time trying to decide what timestamps to use etc.
Since RIPP never allows a period of silence and some packet must always be transmitted it might also mess up CNG which was designed to slow the roll of RTP and send one packet every so often.
Both were designed with the idea of translating ip data to/from a generator to create actual tones or "silence"
Just thinking about being on both sides of the connection, maybe it would be nice to come up with a more succinct way to deal with both? CNG might be obsolete in this pathway because it can't really traverse from one phone to another across a trunk where, by design, it already deals with silence by sending packets at every interval. CNG is kind of a trick to avoid sending packets at all and isn't usually passed through.
DTMF will be pretty important as always and depending on the circumstances, is there a better way to communicate the desired digits and, gulp, the duration of the digits. A lot of times the timestamps in DTMF from rando RTP implementations is totally broken etc.
G711 and Opus will have considerations for timestamps as well. Since Opus believes all calls should have a base clock of 48khz and G711, of course, is 8khz. Sometimes the DTMF is still clocked at 8k even for opus calls and sometimes its clocked at 48k to match which sometimes breaks things yada yada.
In general, will we be trying to preserve the original RTP timestamps and the timing gaps? Will there be any new better strategies we can come up with to de-jitter the streams or do we make it a rule you have to put a jitter buffer on the inbound leg of the SIP2RIPP gateway?