Session setup with multiple web clients

[ModalityZ]

I have a few questions about a scenario in which all clients will usually be browser-based (but sometimes some of them might be in a headless browser). Before the questions, here's the scenario:

1. To keep AWS credentials safe, let's assume they are used only by a server component that receives:
   • A Cognito access token
   • A session ID
   • KVSW role "MASTER" or "VIEWER"
2. If the access token is valid, the server does:
   1. Creates a channel named according to the session ID and for the given KVSW role
   2. Looks up the HTTPS endpoint of the channel in the current region
   3. Looks up ICE server config for the current region for this channel
   4. Returns the channel ARN, HTTPS endpoint, and ICE server config

Here are the questions:

1. Because all of the clients will need the values returned by the server function above, it seems they all need to send a request to the server that is similar for all of them except that only one of those requests will indicate it is from the MASTER, correct?
2. We don't want to duplicate the server work for each of those requests, because it would be unnecessary, correct? That is, just because the role or clientId might differ across the requests, there is no need to try to create the channel again, nor create another signed url, nor lookup ICE server config, correct?
3. If that's so, then it's not clear what the purpose of passing-in the role and clientId might be. Instead it seems the return value should be cached so it can be provided to all later requests about that session ID.
4. An AWS doc says "A viewer cannot discover or interact with other viewers through a given signaling channel." But if a session has two VIEWERs, won't the audio of one viewer be sent to the other viewer as well as to the master? What about their video?

[ModalityZ]

For questions 1 through 3, I found:
A. The clientId is baked into the signed url, so it seems each client needs its own signed url and no caching should be done as I suggested.
B. The role is used to lookup a signaling channel endpoint for the channel. This implies that there is a different endpoint for masters and viewers. It is not clear to me why that would be.

[stefankiesz]

Hi @ModalityZ, that is correct, there are separate endpoints for master and viewers please see the WebSocket API Reference.

A distinction is made between the two roles due to the differences in permissions/behaviors that they will have, please see the GetSignalingChannelEndpoint Documentation for more details.

If a session has multiple viewers, there will be no data nor media sent between the viewers - only between the master and each of the viewers.

[ModalityZ]

I really appreciate your response @stefankiesz I consider it the answer.

But some comments: I can see that the endpoints for masters and viewers are different, but from a design standpoint it is not clear to me why. To accommodate more use-cases, I would have expected all endpoints to be the same but the first for a channel would be permitted to request "host" permissions. This would allow the host to transfer those permissions later in a session. The current design seems limited to use-cases similar to a music concert or lecture where no flexibility is needed to change the host. Similarly, it's not clear to me why the design is to prevent non-hosts from hearing and seeing each other, if that is what the host would want. My use-case fits KVSW's design, but I think KVSW is a potentially more attractive option than Chime because KVSW allows keeping all data within the region.