[QUESTION] Busy signal when max connections reached?

[thinkski]

samples/Samples.h has a constant #define DEFAULT_MAX_CONCURRENT_STREAMING_SESSION 10. However, once 10 concurrent sessions are reached, a received SDP offer should generate some kind of busy signal, although none appears to exist within src/source/Signaling.

Similarly, a device may wish to only support a single concurrent "call", particularly with two-way audio. Or it may flat out reject an offer (e.g. in the IP camera case, a 'privacy' button has been enabled). How is a "busy/reject-offer" signal intended to be communicated?

@disa6302 or @MushMal Am I missing something? How are rejected offers designed to be handled in the context of Kinesis Video Streams with WebRTC? Custom messages appear to be blocked by the signaling channel, as is the GO_AWAY message type.

[github-actions[bot]]

It looks like this issue has not been active for a long time. If the issue is not resolved, please add an update to the ticket, else it will be automatically resolved in a few days.

[disa6302]

@thinkski ,
I think this is similar to the question here: #1386

By spec, setting m=0 is a way to reject an offer and since this line is hard coded within the codebase, there isnt a way to set this up in the application. It should be a simple change to incorporate this, but, we do not have an ETA on this yet.

As far as sending a busy signal, we do not have that support. 10 is a soft KVS defined limit. https://docs.aws.amazon.com/kinesisvideostreams-webrtc-dg/latest/devguide/kvswebrtc-limits.html.
You can have a timer based approach on the viewer end and if it does not receive an answer in the stipulated time, then desired action can be taken.

[disa6302]

Resolving due to no response.

[Matsoosterlaken]

Similar to Issue #1386, we have an application that wants to offer <10 maximum client sessions and send a busy signal or rejection message to any clients that connect beyond that number. The timer based solution does not seem good enough because in our embedded application we want to differentiate to the user when the stream is down due to the embedded system being disconnected from the network versus rejected due to maximum client session having been reached. These 2 issues seems to have been closed due to staleness and lack of response so I just wanted to re-up the attention on it and say that this is still an issue.