Commenter: Hi, can I ask a WebRTC related question?
Commenter: My name is Garfield.
WebRTC forum moderator: Ahh OK, are you related to the cat?
Commenter: Seriously? When’s the last time a cat asked questions in the WebRTC forum?
WebRTC forum moderator: Good point. How can I assist you today, Mr. ahh Garfield?
Commenter: I have a problem with a family secret which has been passed down from mouth to ear for centuries.
WebRTC forum moderator: And how is it related to the WebRTC forum?
Commenter: Well, I am quite old and I realized that this is a good time to pass the secret to the next generation. I have been told that WebRTC has the most secured media channel there is. So I thought this would be a good place to do it.
WebRTC forum moderator: If I may ask, how old are you?
Commenter: 15 years old.
WebRTC forum moderator: Excuse me? Ahh. Why don’t you pass your secret to your children?
Commenter: They’re on the other side of the ocean and I am afraid to do it on an international call.
WebRTC forum moderator: Why?
Commenter: Hey, I may be old but I’m not so naive to let the NSA learn about my grandmother’s secret lasagna recipe.
WebRTC forum moderator: I get your point. You heard right about WebRTC. Let me explain: The security mechanism in WebRTC is quite different than other calling systems. WebRTC mandates all media channels voice, video and data using DTLS protocol for security.
The browsers exchange a Datagram Transport Layer Security (DTLS) handshake on every media (voice, video and data) channel. Once these DTLS handshakes are completed, the media is encrypted and begins flowing between the browsers using Secure Real-time Protocol (SRTP).
Other calling systems are using SDES (used by SIP); in SDES the crypto is forwarded in the SDP via the signaling interface and can be used by the servers in the signaling path to decrypt the media.
SDES, which is used more in the SIP world, would help interface more easily to existing SIP-based infrastructure. Although there is consensus that DTLS will be mandatory for WebRTC to support, until two weeks ago, Google Chrome supported both SDES and DTLS. The most recent Chrome version no longer supports SDES. Mozilla Firefox never supported SDED.
In short, when using WebRTC end-to-end, eavesdropping is not an option; your grandmother’s lasagna secret recipe is safe.
Commenter: Many thanks, by the way, what happens if recording is a necessity such as in Contact Centers or where regulation requires it?
WebRTC forum moderator: In such cases, there are a few options. One option is using WebRTC client API for recording, however it’s a local solution. An organization straight forward approach is to use a WebRTC GW with forking abilities, or a Session Border Controller which supports SIPREC for recording with WebRTC termination capabilities. The SBC then maintains two DTLS call legs toward each party of the call and in the middle; it forks the call to the recording server using a standard SIPREC protocol.
Commenter: It’s strange that you are mentioning SBC’s in this context, since a few weeks ago I read in BlogGeek.me that SBCs are not required in the WebRTC world.
WebRTC forum moderator: That’s true when making a call between two browsers but there will be a need for a border element to be between the WebRTC world and the SIP world, WebRTC GW (SBC), to terminate WebSocket, DTLS, ICE and OPUS transcoding.
Commenter: That’s very intriguing! So do you think it is safe to send Pomodoro Siciliano over the WebRTC data channel too?
WebRTC forum moderator: I would recommend starting moderately with the basil.
WebRTC forum moderator: Oh my……..