Janice Lu1. WebRTC信令交互基础概念
第一次接触WebRTC信令时，我盯着SDP那一大串文本看了半天，完全不明白这些a=、v=开头的字符串有什么用。后来在实际项目中踩过几次坑才明白，这其实是媒体协商的关键。简单来说，信令交互就像两个陌生人在相亲前先交换基本信息：你擅长什么（支持的编解码）、你喜欢什么方式沟通（传输协议）、你的联系方式是什么（IP和端口）。
WebRTC的信令过程必须解决三个核心问题：
- 媒体能力协商：通过SDP（Session Description Protocol）描述双方的音视频编解码能力
- 网络穿透：通过ICE框架收集NAT穿透所需的候选地址（candidate）
- 安全验证：通过DTLS-SRTP建立加密传输通道
SRS作为信令服务器的优势在于，它把复杂的ICE协商过程封装成了两个简单的HTTP API。开发者只需要关注：
- 调用
/rtc/v1/publish/发布本地媒体流 - 调用
/rtc/v1/play/请求远端媒体流
剩下的NAT穿透、安全握手等脏活累活都交给SRS处理。这种设计让WebRTC的接入门槛大幅降低，我在实际项目中最快15分钟就能搭建出可用的视频通话demo。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. SRS信令API深度解析
2.1 推流API的实战细节
在Vue项目中实现推流时，有几个关键参数容易出错。首先是streamurl的格式，必须严格按照webrtc://{ip}:{port}/{stream}的格式填写，其中8000是SRS默认的WebRTC UDP端口。我曾因为漏写端口号导致连续两小时排查失败。
完整的推流请求示例：
javascript复制const data = {
api: "http://192.168.5.104:1985/rtc/v1/publish/",
streamurl: "webrtc://192.168.5.104:8000/live/room1",
sdp: pc.localDescription.sdp // 从RTCPeerConnection获取
}
服务器响应中的关键字段：
code=0表示成功sdp包含服务器端的媒体协商结果sessionid用于后续的信令跟踪