Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

[Randell Jesup <[e-mail]>]

On 10/21/2014 4:58 PM, Wyss, Felix wrote:
>>> Yes, that's the intended use-case: The middlebox is a trusted man-in-the-
>> middle.  In order to record and/or perform analytics on the media flowing
>> through it, it obviously has to decrypt it.  That can only be done by
>> terminating DTLS (and decrypting/re-encrypting SRTP.)
>>
>> If the middle box is trusted, only interested in media and known about by
>> the application, then the application should create a separate direct data
>> channel only DTLS connection between the endpoints that bypasses the
>> middle box, with a small amount of extra application effort we remove the
>> need for even more random extra SDP lines. Remember these are
>> programmable endpoints - not dumb SIP devices with fixed behaviours.
>>
>> Unless the middle box is performing 'analytics' on the DC data too, but that
>> isn't the use-case you mentioned.
> Having to use one of the endpoints to fork the media for recording and analytics is not acceptable for us.  Many of our customers require that all interactions are recorded exactly as they occur between the endpoints.  Often they are required to do that for legal or compliance reasons.  It's actually pretty certain that some of them will want the data streams recorded too.

I had a suspicion that this was the intended use-case - and it's a real 
use-case for certain applications/industries.

So, for those applications (remembering that webrtc applications are not 
random external devices, but basically code linked to the usage) just 
either use pre-defined or external negotiation for channel assignments, 
or implement *in the application* allocation-choosing strategy.  Such as:

middlebox: offer to A and B (actpass)
A: accept (active)
B: accept (active)
ok, now both are on the same "evenness"
both statically open (pre-defined) channel 0 always
Both send a random token value
The side with the lower random value is even, and the other is odd
All channel allocations are preceeded by message on channel 0 that 
amounts to an "I'm opening channel N with these params" that takes the 
place of DCEP
Encapsulate this behavior in some simple functions that take the place 
of the default createDataChannel()/etc

There are other solutions of course for glare resolution.  If you want, 
if the two sides chose the opposite evenness, you just leave 
createDataChannel alone.  There are a LOT of ways to deal with this at 
the application level, since the application "should" know it's talking 
to (or may be talking to) a middlebox that will decrypt/forward things.

-- 
Randell Jesup -- rjesup a t mozilla d o t com