Skip to main content
SDK 抛出的错误统一是 SRTCError,它继承 Error,并额外带三个字段: toString() 输出 "{code}: {detail}",方便日志里一行同时拿到码和描述。

错误码是怎么拼出来的

  • SDK 内部错误:原始码 < 1000,会被加上平台前缀拼成 6 位数。 HarmonyOS 的 RTC 前缀是 108,所以内部错误码形如 108001 ~ 108026
  • 业务后端透传的错误码:≥ 1000 时原样保留,不再加前缀。
这套编号与其它端一致(windows=101、android=102、iOS=103、linux=104、macOS=105、 web=106、小程序=107、HarmonyOS=108),所以同一类错误在各端的后三位是相同的, 跨端排障时可以直接对齐。
apiRequestFailedcode 语义与其它错误不同:它带的是后端返回的码。 后端码 ≥ 1000 时原样透出,< 1000 时同样会被加上 108 前缀。

连接相关


信令相关


WebRTC / 传输相关


轨道与采集相关


引擎与通用错误


推荐的处理方式

JSON.stringify(new Error()) 的结果是 {}ArkTS 里直接把错误对象序列化进日志会得到一个空对象,什么线索都没有。排障时请显式取 code / detail(SDK 错误)或 code / message(系统 BusinessError)。
建议在业务层把 SRTCError 映射成你们自己的错误域,而不是把英文 detail 直接展示给最终用户。

编解码相关的坑

codecNotSupported 不一定会抛出来 —— 更常见的情况是「静默降级」。@ohos/webrtc 的 H264 / H265 是纯硬编,没有软编兜底。当设备能力表里查不到 H264 时, SDK 内部会跳过编码偏好设置、退回默认顺序(通常是 VP8),这个过程不报错表现是本机看得到画面,但与 Web / iOS / Android / CDN 互通不上。所以自测不能以 “看到画面”为准,要核对实际协商到的编码格式:
videoCodecReport() 会把收发两个方向的能力连同 sdpFmtpLine 一起列出来, 用它确认发送侧有没有 video/H264。只有接收侧有是不够的 —— 收得下不代表发得出。