SRS流媒体服务（五）WebRTC信令交互与SDP交换实战解析

1. WebRTC信令交互基础概念

第一次接触WebRTC信令时，我盯着SDP那一大串文本看了半天，完全不明白这些a=、v=开头的字符串有什么用。后来在实际项目中踩过几次坑才明白，这其实是媒体协商的关键。简单来说，信令交互就像两个陌生人在相亲前先交换基本信息：你擅长什么（支持的编解码）、你喜欢什么方式沟通（传输协议）、你的联系方式是什么（IP和端口）。

WebRTC的信令过程必须解决三个核心问题：

• 媒体能力协商：通过SDP（Session Description Protocol）描述双方的音视频编解码能力
• 网络穿透：通过ICE框架收集NAT穿透所需的候选地址（candidate）
• 安全验证：通过DTLS-SRTP建立加密传输通道

SRS作为信令服务器的优势在于，它把复杂的ICE协商过程封装成了两个简单的HTTP API。开发者只需要关注：

1. 调用/rtc/v1/publish/发布本地媒体流
2. 调用/rtc/v1/play/请求远端媒体流
   剩下的NAT穿透、安全握手等脏活累活都交给SRS处理。这种设计让WebRTC的接入门槛大幅降低，我在实际项目中最快15分钟就能搭建出可用的视频通话demo。

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用于后续的信令跟踪

2.2 拉流API的特殊处理

拉流时最容易踩的坑是收发器（transceiver）的方向设置。在创建RTCPeerConnection后，必须正确配置transceiver的direction参数：

javascript复制pc.addTransceiver("audio", {direction: "recvonly"});
pc.addTransceiver("video", {direction: "recvonly"});

如果忘记设置recvonly，会导致SRS服务器误判为双向流传输，消耗额外带宽。我在生产环境就遇到过因为这个问题导致服务器负载飙升的情况。

3. SDP交换全流程拆解

3.1 典型SDP结构分析

一个完整的SDP包含多个层级的信息：

code复制v=0  // 协议版本
o=- 0 0 IN IP4 127.0.0.1  // 会话标识
s=-  // 会话名称
t=0 0  // 时间戳
a=group:BUNDLE 0 1  // 媒体流绑定
m=audio 9 UDP/TLS/RTP/SAVPF 111  // 音频媒体行
a=rtpmap:111 opus/48000/2  // 编解码详情
a=candidate:1 1 udp 2130706431 192.168.1.100 5000 typ host  // 网络候选地址

实际项目中，我建议重点关注三个部分：

1. m=开头的媒体行，确认音视频是否都正常协商
2. a=rtpmap验证编解码器是否支持
3. a=candidate检查NAT穿透地址是否正确

3.2 常见SDP协商问题

调试时最常遇到的三种SDP错误：

1. m-line顺序不一致：本地offer和远端answer的媒体行顺序必须匹配
2. 编解码不兼容：比如客户端只支持H264但服务器配置了VP8
3. 候选地址无效：防火墙未开放UDP端口导致ICE失败

通过Wireshark抓包分析时，可以重点关注：

• STUN绑定请求是否收到响应
• DTLS握手是否成功完成
• RTP/RTCP包是否正常传输

4. 实战：Vue3集成完整示例

4.1 项目配置要点

在vue.config.js中需要添加WebRTC相关的polyfill配置：

javascript复制module.exports = {
  configureWebpack: {
    resolve: {
      fallback: {
        'http': false,
        'https': false,
        'zlib': false
      }
    }
  }
}

4.2 关键代码实现

推流功能的完整实现包含以下步骤：

1. 获取媒体设备权限

javascript复制const stream = await navigator.mediaDevices.getUserMedia({
  audio: {
    echoCancellation: true,
    noiseSuppression: true
  },
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 }
  }
});

2. 创建PeerConnection并添加轨道

javascript复制const pc = new RTCPeerConnection();
stream.getTracks().forEach(track => {
  pc.addTrack(track);
});

3. 发起SDP交换

javascript复制const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

const response = await fetch('http://192.168.5.104:1985/rtc/v1/publish/', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    api: "http://192.168.5.104:1985/rtc/v1/publish/",
    streamurl: "webrtc://192.168.5.104:8000/live/demo",
    sdp: offer.sdp
  })
});

const answer = await response.json();
await pc.setRemoteDescription(
  new RTCSessionDescription({ type: 'answer', sdp: answer.sdp })
);

4.3 调试技巧分享

在开发过程中，我总结出几个实用的调试方法：

1. SDP可视化分析：使用https://sdp.dev工具解析SDP内容
2. ICE状态监控：监听RTCPeerConnection的iceconnectionstatechange事件
3. 带宽自适应：通过RTCPeerConnection的getStats()获取实时网络质量

javascript复制pc.addEventListener('iceconnectionstatechange', () => {
  console.log('ICE状态:', pc.iceConnectionState);
});

setInterval(async () => {
  const stats = await pc.getStats();
  stats.forEach(report => {
    if(report.type === 'outbound-rtp') {
      console.log('当前码率:', report.bitrate);
    }
  });
}, 1000);

5. 性能优化与生产建议

5.1 服务器端配置优化

在SRS的配置文件中，这几个参数对性能影响最大：

conf复制rtc_server {
    enabled on;
    listen 8000;
    candidate $CANDIDATE_IP;
}

rtc {
    twcc on;  # 启用传输层拥塞控制
    min_port 10000;
    max_port 20000;
}

其中candidate配置特别重要，必须设置为服务器的公网IP或域名。我在阿里云环境测试时，错误配置内网IP导致外网用户完全无法连接。

5.2 客户端最佳实践

根据实际项目经验，推荐以下优化措施：

1. 带宽探测：在建立连接前先进行带宽测试
2. 分层编码：使用Simulcast或SVC适应不同网络条件
3. 降级处理：网络差时自动降低分辨率/帧率

实现代码示例：

javascript复制// 动态调整视频参数
function adaptVideoQuality(bitrate) {
  const sender = pc.getSenders().find(s => s.track.kind === 'video');
  const parameters = sender.getParameters();
  
  if(bitrate < 500) {
    parameters.encodings[0].scaleResolutionDownBy = 2.0;
    parameters.encodings[0].maxBitrate = 300000;
  } else {
    parameters.encodings[0].scaleResolutionDownBy = 1.0;
    parameters.encodings[0].maxBitrate = 1000000;
  }
  
  sender.setParameters(parameters);
}

6. 常见问题解决方案

6.1 ICE失败排查指南

当遇到ICE协商失败时，建议按以下步骤排查：

1. 检查candidate是否包含所有网络类型的地址
2. 验证STUN/TURN服务器是否可达
3. 确认防火墙已放行UDP端口

测试STUN服务的命令示例：

bash复制nmap -sU -p 3478 stun.l.google.com

6.2 音频卡顿优化

音频卡顿通常由以下原因导致：

• 网络抖动导致包丢失
• 音频缓冲区设置不合理
• CPU过载导致编码延迟

解决方案：

javascript复制// 启用opus的FEC（前向纠错）
const audioSender = pc.getSenders().find(s => s.track.kind === 'audio');
const parameters = audioSender.getParameters();
parameters.encodings[0].codecPayloadType = 111; // opus负载类型
parameters.codecs = [
  {
    mimeType: 'audio/opus',
    clockRate: 48000,
    channels: 2,
    parameters: {
      useinbandfec: 1,  // 开启FEC
      usedtx: 1         // 启用静音压缩
    }
  }
];
audioSender.setParameters(parameters);