Custom signaling messages support

[rcm-bor]

I could find any documentation on this topic.

Is it possible to extend the signaling protocol with custom/app specific message types in any way?

enum MessageType {
    SDP_ANSWER = 'SDP_ANSWER',
    SDP_OFFER = 'SDP_OFFER',
    ICE_CANDIDATE = 'ICE_CANDIDATE',
    CUSTOM_MESSAGE = 'CUSTOM_MESSAGE'
}

When we experiment, it looks like the signaling server is rejecting the message, thus client side never receives it.

[niyatim23]

Hi @rcm-bor, you can use the data channel to send custom messages perhaps. If not, can you please explain your use-case further?

[nat-bor]

Hi @niyatim23 we have found several use cases where we need to send custom messages via the signaling channel instead of the data channel because we have a case where the latter breaks at some point but the signaling connection stays stable

[niyatim23]

Unfortunately, there is no way to do that via signaling channel Closing assuming answered. Feel free to open an new issue in case of a problem / questions

[jeryini]

Hello @niyatim23 !

We've also came across needing this feature. In our case, we would like to leverage existing secure WebSocket connection to exchange password that is required for joining a session via signalling messages . Unfortunately at the moment this means we have to go with a separate solution just for this purpose. Do you have any information if this is in the future plan?

[sirknightj]

While not officially supported, you can put your custom message in the payload field. You would need to create some scheme to determine whether your message is a real ice candidate message vs. your custom message and modify the SIgnalingClient accordingly.

https://docs.aws.amazon.com/kinesisvideostreams-webrtc-dg/latest/devguide/kvswebrtc-websocket-apis5.html

{
    "action": "ICE_CANDIDATE",
    "recipientClientId": "string",
    "messagePayload": "<Custom message would go in here>",
    "correlationId": "string"
}

messagePayload - The base64-encoded message content.
- Type: String
- Length constraints: Minimum length of 1. Maximum length of 10K.
- Required: Yes

As to why adding a custom action wouldn't work is because it doesn't fit in the allowed possibilities:

action - Type of the message that is being sent.
- Type: ENUM
- Valid values: SDP_OFFER, SDP_ANSWER, ICE_CANDIDATE
- Length constraints: Minimum length of 1. Maximum length of 256.
- Pattern: [a-zA-Z0-9_.-]+
- Required: Yes

For sending messages back and forth after the peer connection has been established, data channels should be the way to go.

[jeryini]

Hello @sirknightj !

Thank you for the proposal. Yes we actually went with using DataChannels sending the password from the client side immediately after it opens the channel and only then enabling audio/video track on the master side after password is verified.