WebRTC：Support Cluster over QUIC.

[yzw607]

Two questions:

1. Does WebRTC not function on an Edge server?
2. Does WebRTC also not function on an Origin server?

How can WebRTC be supported in a cluster configuration?

[winlinvip]

The Edge is just designed for live streaming, that is RTMP, so the Edge only supports RTMP/HTTP-FLV. Neither WebRTC nor HLS is not supported by Edge, it's the features of Origin.

The cluster for HLS is regular HTTP file-based server, like Nginx or ATS. And cluster for WebRTC is called Cascading over QUIC, it's actually an OriginCluster connected with QUIC not RTMP.

Right now, most of WebRTC server does not support cluster, or does not work well, because WebRTC is too complex. We need time to design the arch carefully, especially we support both live streaming and WebRTC.

Note that TURN server is also could use as "Edge-like" for WebRTC origin server, but it does not support stream aggregation, which means it by-pass all connections and streams to SRS, so it won't help to extend the capability, it only works as a "by-pass proxy" over TCP or UDP. In one word, TURN is not a WebRTC cluster, it's a proxy near user to improve the network quality.

We may support WebRTC cluster, the OriginCluster over QUIC, in SRS 5.0 or later. It depends on our time resource, and whether we get a stable and simple enough arch.

The arch for WebRTC Cluster：

• No edge for WebRTC.
• Origin works for LiveStreaming and WebRTC, it holds the stream.
• The OriginCluster for LiveStreaming is based on RTMP302, while OriginCluster for WebRTC is based on QUIC.

TRANS_BY_GPT3

[winlinvip]

Moved to #2091 (comment)

[winlinvip]

@wangjin TURN is not used for clustering, but for traversing firewalls, such as using the TCP protocol or as an exit gateway. Since TURN only forwards traffic and does not aggregate, it cannot be expanded. Therefore, the traffic after TURN will not decrease, and with SFU, clients do not need to have so many uplinks, and the same is true for clusters.

@phusinh Clusters often have a service discovery mechanism. Simply put, you can use configuration files to discover each other and define the worker network within the cluster. You can also use a separate backend service for service discovery. You can refer to this article StackOverflow

[lovetian0910]

How is the current development progress of RTC cascading?
Is there a separate branch for joint development now?

[zxk69809]

There hasn't been much progress on RTC clustering lately. It would be great if you could first outline the ideas and architecture, and everyone can participate.

[winlinvip]

Update: I think we should support proxy for origin servers, which is much more useful than WebRTC cascading. Proxy is designed for origin server and all protocols, so we can use proxy to build RTMP/FLV cluster, or SRT cluster, or WebRTC cluster, or GB28181 cluster.

[jeckee]

@winlinvip SRS5 has been released now, does it support WebRTC clustering?

[andyzheung]

Does this mean that RTC does not support the Origin and Edge mode? I saw an article before that said WebRTC can also expand the streaming capability through Edge.
https://mp.weixin.qq.com/s/pd9YQS0WR3hSuHybkm1F7Q

[winlinvip]

Update as of 2023.07.18:

1. SRS Edge is designed for live streaming and not for WebRTC. Although some articles suggest that Edge can be modified to support WebRTC, it is not currently supported and there are no plans to implement it.

2. There are no current plans for a WebRTC cluster that cascades between origin servers using the QUIC protocol. This is because it is highly complex and will not be supported.

3. We will support a proxy cluster, which will also serve as a cluster for all protocols. The proxy cluster is not cascading and does not use QUIC. It is significantly simpler in comparison.

[miaulightouch]

1. Like OvenMediaEngine, they use a redis to register, stream id as key , origin ip/path as value, when encoder publish stream to origin. all edges just need to check the id to pull stream from specific origin.
2. leave the complex logic out of the edge cluster, in k8s, let stunner do the job for us.

[winlinvip]

Firstly, the SRS (Simple Real-time Server) employs a Proxy to enhance system capacity. This approach is definitive and will be implemented within the SRS Stack. For more details, please refer to the discussion at #3634.

Secondly, the Forward feature has been continuously proven to be another effective method for expanding downstream capacity in practice. However, currently, Forward supports RTMP forwarding. If forwarding via QUIC or WHIP is supported, it would effectively enhance the playback capabilities for RTC (Real-Time Communication).

I personally have a preference for WHIP over QUIC. Of course, if in ten years WHIP can also be based on QUIC, then we can discuss it again.

TRANS_BY_GPT4

[slps970093]

I saw a solution recently. I wonder if this solution can be applied to the existing SRS5.

https://github.com/l7mp/stunner?tab=readme-ov-file#installation