[AVTCORE] Offer/Answer and Transport Translators was: Re: Comments on draft-lennox-rtcweb-rtp-media-type-mux-00

[Magnus Westerlund <[e-mail]>]

On 2011-11-10 17:02, Jonathan Lennox wrote:
> (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.

I would disagree with you here. I think it is very much possible. Yes 
the PT picking is an issue, but if the translator is the inviting party 
and the responder doesn't renumber it will work. Having the translator 
or application server start the media invite is actually easier in the 
WebRTC context, than it is in normal SIP, as there you likely need to 
accept an initial invite from the client and then re-offer from the 
server to get things correct.

The renumbering of payload is introduced because of something in the H. 
suite, is it really commonly happening?

> 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.

This I agree is the other hazzle, but with EKT we do resolve it. And the 
transport translators only task beyond forwarding media in such a 
session will be to inject keys from the other legs towards each end-point.

>
> 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.

I agree it is tiny to transcoding. But is not tiny in comparision to 
packet forwarding.

>
>
> 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.

We are definitely disagreeing on this point.

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

Not at all. It benefits any usage where you want to have an additional 
demultiplexing point based on purpose. The alternative is to classify 
each and every SSRC into a role, then process them differently in any 
node. That is under the assumption you want to avoid multiple transport 
flows.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------