Re: [AVTCORE] Comments on draft-lennox-rtcweb-rtp-media-type-mux-00

[Jonathan Lennox <[e-mail]>]

(I'm cutting down this conversation heavily, to respond to just one point...)

Magnus Westerlund wrote:

> - If it is non mixing entity like an RTP mixer that switches media streams, i.e. sends them out using the Mixer's SSRCs. Then you still have the decryption and encryption cycle even if the media mixing, encoding and decoding goes away. So this is clearly less complex, but still more heavy than just forward the packet.]

I think, in practice, that an RTP mixer *inevitably* has to have at least this capability, and a pure transport translator is impossible for multipoint conferences, assuming that the endpoints' sessions with the central point are negotiated by SDP offer/answer.

The primary reason is that offer/answer allows each receiver to pick its own RTP payload type values.  This means the mixer has to re-write RTP headers, and also means it can't blindly forward unknown RTCP packets (since some RTCP extensions refer to the session's payload types). 

Additionally, both SDES and DTLS keying negotiate keys point-to-point, and offer/answer allows endpoints to pick their own b= receive bandwidth, which means different RTCP timings.  Both of these can be worked around to some extent (SRTP EKT is almost done, and having minorly-inconsistent RTCP timings is usually harmless), but it's not clear how much point there is to working around these issues, given the first one.

In practice, though, decryption and re-encryption isn't that expensive, particularly on modern CPUs with built-in crypto accelerators.  It's certainly tiny compared to the cost of media transcoding.


Thus, I think trying to design an architecture that makes pure-transport translation possible is a lost cause, if your primary use cases are offer/answer based, and so there's no point in creating new mechanisms in an attempt to support it.

Unless I'm missing something, SHIM falls in this category -- the benefits of SHIM over single-session muxing are largely for transport translation.

-- 
Jonathan Lennox
[e-mail]