DescribeRTCStreamState
https://rtc-api.zego.im/
This API supports querying the real-time status of a specified stream (whether it is active or exists). It only supports querying streams published to the ZEGOCLOUD media server (RTC service), and does not support querying streams published directly to the CDN or output from the stream mixing service.
It is recommended to prioritize using stream created callback and stream destroyed callback to asynchronously obtain current stream publishing information. This API is generally used as an auxiliary interface for stream created callback and stream destroyed callback, or when querying whether a specified single stream is active in the business backend.
This API supports querying stream status information after starting stream publishing by default.
In the test environment (see the IsTest common parameter description for details), the Stream ID must be prefixed with "zegotest-AppId-". For example, if the Stream ID is "test" and the AppId is "123456789" in the test environment, the Stream ID should be "zegotest-123456789-test".
Request
Query Parameters
Possible values: [DescribeRTCStreamState]
API prototype parameters
https://rtc-api.zego.im?Action=DescribeRTCStreamState
💡Public parameter. Application ID, assigned by ZEGOCLOUD. Get it from the ZEGOCLOUD Admin Console.
💡Common parameter. A 16-character hexadecimal random string (hex-encoded 8-byte random number). For the generation algorithm, refer to the signature example.
💡Common parameter. Current Unix timestamp in seconds. For the generation algorithm, refer to the signature example. A maximum deviation of 10 minutes is allowed.
💡Common parameter. Signature used to verify the legitimacy of the request. Please refer to the signature mechanism to generate it.
Possible values: [2.0]
Default value: 2.0
💡Public parameter. Signature version number.
Stream ID.
Request sequence number, customized by the user.
Note
For the same StreamId, within 10 consecutive seconds, the request sequence number issued for this StreamId must be strictly increasing; this avoids inconsistent operation order caused by inconsistent request timing received by the server.
If there is no concurrent scenario, using a timestamp (millisecond level) is recommended.
Responses
- 200
- application/json