CloudHub Docs
Download Documents

RTC


CloudHub JSSDK

Constants in the SDK

How to use it: CloudHubRTC.CONSTANTS.CONSTANTS_NAME, eg：CloudHubRTC.CONSTANTS.MSG_TO_ALLUSER

Send messages

nametypedescription
MSG_TO_ALLUSERstringSend a message to everyone in the channel
MSG_TO_ALLEXCEPTSENDERstringSend messages to everyone in the channel except yourself.
MSG_TO_NONEUSERstringOnly send messages to the signaling server, not to anyone
userIdstringuser ID。Note: Send information only to this user

Additional notes

Description of chat message forwarding rules

If there are more than 100 chat messages in 1 second, the chat messages after 100 are discarded. For example, if you send 150 pieces of data in one second, users on the channel receive only the first 100 pieces of data. If you send 90 pieces of data in one second, everyone will receive 90 pieces of data.

Description of the usage scenario of the channel

  1. In the live broadcast scene, there are two user roles, the host and the audience, and the roles of the host and the audience can be set through the Client.setClientRole method. The host can send and receive voice/video streams, while the audience can only receive voice/video, not sending. Live scenes have the following limitations:

    • The join/leave message of the audience in the live broadcast scene will not be triggered. which is client.on(“peer-join”) and client.on(“peer-leave”) do not trigger a callback.
    • Call the setProperty interface in the live broadcast scene, If the change is a viewer, it will not notify the custom user attribute change. which is Client.on(“user-properties-update”) do not trigger a callback.
    • In the live broadcast scene, it is recommended that only some people (hosts or authorized viewers, etc.) be able to send pubMsg/delMsg, and not everyone can actively send pubMsg/delMsg [For example: a channel with 100,000 people and an audience of 99 million people, then these people should not have the ability to actively send pubMsg/delMsg, but should let the anchor authorize a certain audience, and this audience can send pubMsg/delMsg].

  2. In the communication scenario, any user in the channel can send and receive voice/video streams, and there are no restrictions in the live broadcast scene. The only restriction is that too many users are not allowed to enter. This scenario is suitable for one-to-one calls or group chats.

Description of signaling channel and media transmission channel

  1. The signaling channel is the basic channel of the client and the signaling server, and any communication behavior of the channel relies on this channel.
  2. The media transmission channel is a channel established by the client’s stream and the media server, which is used for the transmission of audio and video.
  3. The disconnection of the signaling channel will cause the media transmission channel to disconnect. The disconnection of the media transmission channel will not affect the signaling channel.
  4. stream publish、subscribe、unpublish、unsubscribe depends on the signaling channel, because the media transmission channel needs to be communicated through the signaling channel before the media transmission channel is established, and the mute operation of the stream also depends on the signaling channel.
  5. Once the signaling channel is disconnected, please do not perform any communication activities (such as pubMsg, delMsg, etc.). It is recommended that the interface appears floating and do not allow users to perform operations on the interface until the signaling channel connection is restored.

Single stream mode description

  1. Single stream mode means that only one device stream can be released.
  2. The channel uses single stream mode by default.

Multi stream mode description

  1. Multi-stream mode means that multiple device streams can be published.
  2. Need to enable multiple stream mode, call enableMultiStream method before joinChannel.
  3. call enableMultiStream method after joinChannel will be invalid.
  4. Multi-stream mode and single-current mode are not supported in channel switching.
  5. Multi-stream mode is not supported on mobile.
  6. Multi-stream mode does not support switching video devices.

Browser getUserMedia interface failed error type

Although both the user and the operating system have granted the right to access the device hardware, and there are no hardware problems that may throw NotReadableError exceptions, there are still some problems that make the device unusable.

The user rejects the access request of the current browser instance; or the user rejects the current session access; or the user rejects all media access requests in the global scale.

Older version of the specification is used SecurityError, But in the new version SecurityError Has been given a new meaning.

Can’t find the media type that meets the request parameters.

Although users have authorized using corresponding devices, an error that occurs on a hardware, browser or web level on the operating system causes the device to be accessible.

The specified requirement cannot be satisfied by the device. This exception is an object of type OverconstrainedError, which has a constraint property that contains the constraint object that cannot be satisfied at present, and also has a message property that contains a reading-friendly character string. To illustrate the situation.

Because this exception can even throw in the case where the user has not authorized using the current device, it should be used as a means of detecting device capability attributes.[fingerprinting surface].

On the Document(The Document interface represents any web page loaded in the browser and serves as the entry point for the content of the web page, that is, the DOM tree) where getUserMedia() is called, the use of device media is prohibited. Whether this mechanism is turned on or off depends on the preferences of individual users.

constraints object is not set [empty], or both are set to false。

Because the getUserMedia interface call may have success/failure callbacks that are not triggered (getUserMedia issues inside the browser), the SDK adds a timeout period of 15 seconds to getUserMedia. Once more than 15 seconds, there is no success/failure callback and the callback is considered to be timed out.

Because obtaining the camera requires manual authorization by the user, and the authorization box does not operate within 15 seconds, the getUserMedia request is considered to have timed out (ie: even if the user allows authorization after 15 seconds of timeout, getUserMedia is considered to be a failure).

getUserMedia default timeout time is 15 seconds, if you need to modify this time, please set CloudHubRTC.DEVICE_ADAPTER_CONFIG.GET_USER_MEDIA_TIMEOUT_TS(Millisecond level), eg: CloudHubRTC.DEVICE_ADAPTER_CONFIG.GET_USER_MEDIA_TIMEOUT_TS = 30000 Indicates that the timeout period is set to 30 seconds.

Probably because the results returned by the built-in getUserMedia interfaces of various systems and browsers are not standard, the SDK will uniformly identify all types of errors that are not above as undefined errors.