Cloudflare Calls private beta
Cloudflare published a blog post today titled Build real-time video and audio apps on the world’s most interconnected network
In keeping with Clouflare's tradition of substantive, creative developer marketing, there's a lot of good explainer material about how WebRTC works and some fun framing. (The post says that Cloudflare is building the "biggest WebRTC server in the world.")
I'm interested in other people's thoughts about the Cloudflare's WebRTC announcements. I love that more people are building innovative WebRTC infrastructure.
Has anyone used Cloudflare's "WebRTC Components" managed TURN service?
It was announced a year ago, but is apparently still in private beta. I talked to the Cloudflare team when it was launched, but there were some gaps in functionality at that time (understandable at launch) and we never prioritized looking at it again.
There's a discussion on Hacker News about the Cloudflare Calls announcement.
Comments
-
Oh, I have thoughts, lots of them :)
I am glad and agree with @kwindla's sentiment that it is exciting to see many more companies building tools to make real-time video more accessible to developers. The announcement also shows, to get a meaningful Video SDK that incorporates real-time video, it requires a few independent parts. My personal opinion is that these announcements validate Daily's mental model of how to build real-time apps, which is fairly similar.
I will start with the technical aspects first, because their announcements were very developer focussed. And I think there is a lot of interesting things happening in the announcements.
Before the Cloudflare Calls, which was announced this week, they had a potpourri of protocols
- Stream Connect, allows ingesting media, typically, using the RTMP(S) protocol. This would be great for co-watching sports or a movies. However, there is a protocol mismatch with RTMP and RTP/WebRTC.
- Stream Live their live streaming product, would allow streaming the live call to 1000s of endusers, uses HLS or RTMP and this would again be a mismatch with RTP/WebRTC, when live streaming the Cloudflare calls to 1000s of endusers.
Their WebRTC Ingest and WebRTC Egress solves for the protocol mismatch, it is all RTP/WebRTC from the ingested livestream to the real-time call and to the livestream to the viewers. I hope these announcements excite the video production equipment manufacturers, which generally only support RTMP to incorporate WHIP into their hardware/software.
I have not seen the data or protocol dumps of Cloudflare's signalling protocol, but what I find exciting is the possibility that all the media streams - live ingest, live egress, individual participant RTP streams -- are all named data objects. If my speculation is correct, this would help with cacheability of real-time streams. Caching would add latency but it would make scaling more easy to do. (This is something that the Content-centric Networking folks have worked on but hasnt seen wide adoption). For example, I am curious what these URLs return.
{ "webRTC": { "url": "https://customer-<CODE>.cloudflarestream.com/<SECRET>/webRTC/publish" }, "webRTCPlayback": { "url": "https://customer-<CODE>.cloudflarestream.com/<INPUT_UID>/webRTC/play"},}The business aspects, there is not much in terms of pricing. Since Argo's pricing is gigabytes transferred over the network, it is likely that all components, ingress, egress, and the calls are all bandwidth based pricing. Which means that streaming high quality would definitely result in higher operational cost compared to streaming lower quality.
Time will answer these questions, I am excited and curious to see how this shakes out
5 -
Detailed analysis from Philipp Hancke and Gustavo Garcia:
https://webrtchacks.com/how-cloudflare-glares-at-webrtc-with-whip-and-whep/
1
