Joachim Bauch

> My self built 0.4.1 n-s-s: > > ``` > 2022-08-04 13:09:59.061240 I | client.go:282: Client from 31.220.65.91 has RTT of 90 ms (90.206084ms) > 2022-08-04 13:09:59.063608 I | hub.go:809:...

The signaling server itself requires very little resources (CPU / bandwidth) as it's only forwarding the messages between clients. In most cases, the environment will be network-bound for streaming the...

@jakobroehrl yes, these settings apply to all streams of the signaling server instance. Changing the stream per connection is more a client-side thing, you can follow https://github.com/nextcloud/spreed/pull/5535 for the implementation...

Each client that publishes needs the configured bandwidth as upstream and N times the number of streams he needs to subscribe as downstream, i.e. in a meeting with 5 users...

Well, that's how peer-to-peer works. A client might have different connections to the different other participants, so it makes sense to potentially send different streams to the different other peers.

> Would it be possible to send all data to the server an not directly to all the users? With the HPB this is what already happens. A publisher only...

Please double-check the shared secrets match (Nextcloud Talk admin / backend configuration of signaling server in https://github.com/strukturag/nextcloud-spreed-signaling/blob/2ac58a3360e0059ff6f12ccec4987211c6906840/server.conf.in#L83). Also the signaling server must be able to access the URL of Nextcloud.

The `url` configured for the backends must be the public URL of Nextcloud, i.e. the same URL users will enter in their browser when connecting to Nextcloud. Clients will include...

Could also be this issue: https://github.com/nextcloud/spreed/pull/7437 Feel free to reopen if the problem still exists.

What are you using as frontend webserver? Could it be this closes the websocket connection between the client / browser and the signaling server?