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

["Wyss, Felix" <[e-mail]>]

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

--Felix