Stream Mixing Stopped Callback
Description
When developers need to know the stream mixing status of the current App, they can first configure callbacks. When there is a stream mixing stopped on the stream mixing server of the App, a POST request will be made to the callback URL.
When the following situations occur:
- When the stream mixing stop request processing fails, there is no callback.
- When the stream mixing process is abnormally terminated, there is no callback.
Callback instructions
- Request method: POST.
The callback data format is JSON. You need to perform UrlDecode decoding on it.
- Request URL: Please contact ZEGOCLOUD Technical Support to configure the callback URL.
- Transfer protocol: HTTPS/HTTP. HTTPS is recommended.
Callback parameters
| Parameter | Type | Description |
|---|---|---|
| appid | String | App identifier. |
| event | String | Callback event. This callback returns mix_stop. |
| seq | String | Sequence number of the stream mixing request, ensuring the order in which stream mixing requests are executed, auto-incrementing and unique. |
| task_id | String | Stream mixing ID. If the task_id parameter is included in the stream mixing start request, ZEGO will add the appid prefix to form a new stream mixing ID. Otherwise, the stream mixing ID will be formed by splicing other parameters such as mix_url. |
| channel_id | String | Channel ID, corresponds to the client's RoomID, not exceeding 255 bytes. |
| publish_id | String | Publisher ID, corresponds to the client's UserID, not exceeding 255 bytes. |
| mix_url | String | The final output URL of the stream mixing, RTMP protocol URL, not exceeding 255 bytes. |
| mix_stream_alias | String | The final output stream name of the stream mixing, not exceeding 255 bytes. |
| timestamp | String | Server current time, Unix timestamp. |
| nonce | String | Random number. |
| signature | String | Verification string. For details, see Callback instructions - Verification instructions. |
It is recommended that you convert some parameters to Int for logical processing. Related fields include appid, seq, and timestamp.
Data example
{
"appid": "111111",
"channel_id": "2222",
"event": "mix_stop",
"mix_stream_alias": "aaa",
"mix_url": "rtmp://rtmp.wsdemo.zego.im/zegodemo/aaa",
"nonce": "7257787020413449571",
"publish_id": "abc",
"seq": "1234",
"signature": "fadc2c4abb5714c30a711b3ad6f7783e37531263",
"task_id": "111111:1111",
"timestamp": "1689835223"
}Return response
Return HTTP status code 2XX (e.g., 200) indicates success, and other responses indicate failure.
Callback retry strategy
If the ZEGO server does not receive a response, or the received HTTP status code is not 2XX (e.g., 200), it will attempt to retry, up to 5 retries. The interval between each retry request and the previous request is 2s, 4s, 8s, 16s, and 32s respectively. If the 5th retry still fails, no more retries will be made, and the callback will be lost.