Is this a stupid idea? Using RTCDataChannel to take over from WebSockets once connected

[ryk...@gmail.com]

Background:

We have a webRTC based app that also requires sending secure text messages.

RTCDataChannel sounds great for that!

Implementation:

1. So we set up the Peer Connection using websockets
2. When sending any message:
   1. If a RTCDataChannel is established and readyState == "open"
      1. All messages are sent over RTCDataChannel
   2. Else
      1. Send via websocket

Question:

Is this stupid? Is there something i'm forgetting or missing here?

It's currently working fine (apart from one mistake due to my bad code).

But considering that this approach means that we would use the RTCDataChannel to send offers, answers, icecandidates etc etc.

Are we destined for trouble? E.g. in the case of any renegotiations?

Should i just filter out various messages so that they always send via WS? IF so, which ones do you think.

[Oscar Brito]

This is something I've considered not long ago. The conclusion I got to is that using RTCDataChannel is a good fit for sending big payloads, otherwise WS are good enough.
The drawbacks of using data channels left me with doubts when comparing to WS, like ICE disconnections and STUN/TURN usage and network traffic shaping.

Would love to hear other opinions.

[ryk...@gmail.com]

Yeah, would like to hear others' thoughts.

We found this the easiest way of getting encrypted messages.

Also, we use a WS provider that charges per message (well per 1,000,000), we send a lot of little messages, so even TURN costs for us would be lower than WS.

I'd hope that our little check above should detect ice disconnections and revert to WS.

But i'm still not sure about renegotiations (i must read up more) whether an ice failed would fire first before negotiation needed.

Or whether it would just try to send over a new offer over a data channel that doesn't work any more?

Hmm...

[jno...@hirevue.com]

I'm personally a big fan of separating signaling from application network activity.

I think the biggest mistake most WebRTC deploys make is repurposing the signaling layer for general "application" messages.  The big issue with having application messages happen over the signaling channel is it creates ambiguity when the signaling channel fails but the peer connection does not (or vice-versa).

Also, moving to an architecture like this with a media server in the mix allowed us to create a RESTful interface for signaling, which I think is also preferable to websockets.  It's much lower complexity, and more transaction and easy to reason about.

The one drawback is: there isn't a bidirectional channel available if you're unable to establish a peer connection