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?

Trunk creation, call creation, and signaling byways are basically HTTP RPCs, and there are many existing frameworks for doing such things, e.g., https://grpc.io, https://thrift.apache.org/, etc. I'd suggest that we not reinvent this particular wheel.

The document explains how it replaces several previous specs:

In this regard, RIPP replaces the usage of SIP, SDP offer/answer [RFC3264] and RTP [RFC3550] for this particular use case.

I think each of these will require specific work to handle the general case and I tend to think we should split the document accordingly, perhaps with an overview doc to knit them all together.

Specifically, I think the encapsulation of media over QUIC will be complex and will definitely want to live as its own doc.