Audio Streaming Moderation

DeepCleer Audio Streaming Moderation continuously moderates a live audio source — a public stream URL or a recorded RTC channel — and pushes per-segment results to your callback URL as they're produced. It detects political content, pornography, advertising, prohibited content, violence, abuse, moaning, top-leader voiceprint, national anthem, prohibited songs, copyrighted songs, and synthesized human-voice attributes; it can also identify speaker gender, age, timbre, language, audio scene, singing, and minor speakers.

The streaming surface is exposed through two complementary endpoints. One opens the moderation task and starts the stream pull; the other closes it. They share the same authentication envelope and requestId lifecycle.

API Description

Choose an endpoint based on which side of the moderation lifecycle you're acting on:

• Request API — submit a stream (public URL or RTC channel binding) for moderation. DeepCleer maintains the pull, segments the audio, and continuously delivers per-segment moderation results to your callback URL until the stream ends naturally or you stop the task.
• Close Stream API — notify the server to terminate an in-progress moderation task before it ends naturally. Releases stream-pull resources and (when returnFinishInfo: 1 was set on the original Request) triggers the final stream-end callback to your callback URL.

Both endpoints share the canonical request envelope (accessKey / appId / eventId for Request; accessKey for Close) and operate on the same requestId — the identifier returned by the Request API is the key you pass to the Close API.

Endpoints at a Glance

When to Use Which

Request API

Use when:

• You have a live audio stream — a public rtmp / http / hls URL, or an RTC channel from Agora, Zego, TRTC, Volcengine, Giants, Aliyun, or NetEase Yunxin — that you want DeepCleer to moderate continuously.
• You can host a public HTTPS endpoint to receive callback deliveries.
• You need per-segment moderation as the audio is produced, not after the stream has ended.

The Request endpoint accepts the stream descriptor (with provider-specific *Param objects when using an RTC SDK), maintains the pull, and continuously delivers per-segment results to your callback URL. The synchronous response is an acknowledgement only — it confirms that DeepCleer has accepted the moderation task and contains the requestId you'll need for any later Close Stream call. callback is required for the Request endpoint — without it there is no way to receive results.

Close Stream API

Use when:

• The upstream live room has ended on your side and you want to release DeepCleer stream-pull resources immediately.
• You no longer need moderation results for a stream that's still being pulled.
• The original Request returned a duplicate-submission dupRequestId and you need to close the duplicate before resubmitting.

The Close Stream endpoint is fully synchronous: it acknowledges that the close request was accepted. Once accepted, DeepCleer stops pulling the stream and (when returnFinishInfo: 1 was set on the original Request) delivers a final stream-end callback to the original callback URL with statCode = 1 and the appropriate auxInfo.errorCode.

Lifecycle

┌─────────────────────────────────────────────────────────────────────────┐
│  1. Client → POST /audiostream/v4 (Request API)                         │
│     ↓                                                                   │
│  2. DeepCleer → 200 OK { requestId } (synchronous ack)                  │
│     ↓                                                                   │
│  3. DeepCleer pulls the stream and segments the audio                   │
│     ↓                                                                   │
│  4. DeepCleer → POST {callback} { audioDetail, statCode: 0 }   (loops)  │
│     ↓                                                                   │
│  5a. Stream ends naturally OR                                           │
│  5b. Client → POST /finish_audiostream/v4 { requestId }                 │
│     ↓                                                                   │
│  6. DeepCleer → POST {callback} { auxInfo, statCode: 1 }                │
│     (only when returnFinishInfo: 1 was set on the original Request)     │
└─────────────────────────────────────────────────────────────────────────┘

Operational Notes

• Callback retry policy. Per-segment and stream-end callbacks are retried up to 20 times if your endpoint does not acknowledge with HTTP 200. Retry intervals follow the policy documented in the Request API's Callback Mechanism section.
• Stream-pull retry policy. Standard rtmp / http / hls streams retry 12 times with intervals incrementing from 5s up to 60s. RTC SDK paths use provider-specific policies (Agora: 2 retries with 0 interval; Zego: 10 retries with 30s interval). After all retries are exhausted, the task is closed and (when returnFinishInfo: 1) a stream-end callback is delivered with the appropriate auxInfo.errorCode.
• returnFinishInfo recommendation. Set returnFinishInfo: 1 on the original Request whenever you want to know why a stream ended — without it, no callback is produced when the stream closes (whether naturally, via the Close Stream API, or due to pull failure).
• returnAllText recommendation. Set returnAllText: 1 on the original Request whenever you want a periodic heartbeat — without it, no callback is produced during silent or risk-free periods.
• Duplicate-submission recovery. If the Request API returns errorCode: 1001 with a dupRequestId, the original requestId was lost on the wire but the stream is already in moderation. Pass that dupRequestId to the Close Stream API to release the task before resubmitting.