That's entirely true and it's one reason why I hesitated before nitpicking. That said, I think that the distinction should be properly made when someone is discussing a new way to sling data over a network from the application layer. If the author had written what you'd written, I'd have let my reply go.
(Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)
But we already knew that. It's in the article, so again there is a story here that you're missing. We want a client/server protocol that is encrypted and simple -- not requiring ICE/STUN/TURN (OMG).
If you already have Websockets, then Simple-Peer makes it very easy to deal with WebRTC negotiation. As I've mentioned elsewhere, I've created a 4 process WebRTC UDP proxy with that running under nodejs. My use case is precisely client-server.
(Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)