企业官网建设流程全解析

1. 项目概述：为什么SDP不是“协议”，而是一份“音视频会议的电子菜单”

刚入行那会儿，我盯着Wireshark里抓到的一段几十行的纯文本发愣——既没有TCP三次握手的SYN/ACK标志，也没有HTTP的GET/POST动词，更看不到任何加密密钥或媒体流数据。它就安静地躺在SIP信令的Body里，像一封手写的邀请函，用空格和等号分隔，写着v=0、o=- 123456789 1 IN IP4 192.168.1.100、m=audio 49170 RTP/AVP 0……当时带我的导师只说了一句：“别管它叫协议，把它当成音视频通话前双方交换的‘电子菜单’——谁点什么菜（编解码）、在哪上菜（IP端口）、用什么餐具（传输协议）、要不要加辣（NAT穿透方式），全写在这张纸上。”这句话我记了八年，也验证了八年。

SDP（Session Description Protocol）根本不是传统意义的通信协议——它不定义连接建立过程，不参与数据传输，不处理重传纠错，甚至不校验完整性。它只是一个纯文本的、无状态的、描述性元数据格式，作用只有一个：在两个音视频终端（比如手机App和WebRTC网页）真正开始推流拉流之前，把“这次通话要怎么开”这件事，用双方都能看懂的标准化语言，白纸黑字写清楚。它的存在，让H.264和VP9能坐上同一辆RTP列车，让Opus和G.711能在同一个Jitter Buffer里排队，让ICE候选者和DTLS证书能在媒体协商阶段就完成对齐。

你可能每天都在用它，却从未意识到：微信语音通话发起时弹出的“正在连接”，背后是SDP在SIP消息体里飞驰；Zoom会议点击“加入”后黑屏三秒，其实是浏览器在解析SDP并初始化WebRTC PeerConnection；某款国产会议系统出现“音频正常但视频卡顿”，八成是SDP里a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f这行参数和接收端解码器能力不匹配。它不炫技，不抢镜，但一旦出错，整个音视频链路就卡在“准备就绪”的临界点上，动弹不得。

这篇文章不是教你怎么背RFC 4566文档，而是带你以一线开发者的视角，亲手拆开SDP这张“电子菜单”：从最基础的v=版本行开始，逐行解读每个字段的真实含义；还原一次完整的WebRTC SDP Offer/Answer协商过程；实操修改关键参数解决真实线上问题；最后告诉你，当SDP在弱网、NAT、多终端混用场景下“说错话”时，该怎么听懂它没说出口的潜台词。无论你是刚接触音视频的客户端工程师，还是需要排查信令问题的服务端同学，或者正被跨平台兼容性折磨的测试人员，这篇内容都直接对应你明天早上的工单。

2. SDP结构深度拆解：每一行都是音视频通话的“法律条款”

SDP文档看似松散，实则结构森严。它由一个会话级描述（Session Description）和零到多个媒体级描述（Media Description）组成，所有字段均以a=（attribute）、m=（media）、c=（connection）等单字母前缀标识。这种设计不是为了省事，而是为了解耦——会话级信息（如全局起始时间、主叫方身份）只需声明一次，而媒体级参数（如音频用Opus还是G.722、视频分辨率多少）可针对每路流独立配置。下面我以一份真实的WebRTC Offer为例，逐行解剖其背后的工程逻辑。

2.1 会话级字段：通话的“宪法总纲”

v=0 o=- 123456789 2 IN IP4 192.168.1.100 s=- i=- u=- e=- p=- c=IN IP4 0.0.0.0 t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS local_stream

• v=0：SDP版本号，目前只有0。别小看这行，某些老旧设备固件会因检测到非0值直接拒绝协商，这是历史兼容性埋下的第一颗雷。

• o=行（Origin）：o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>。其中<sess-id>是会话唯一ID，必须是整数且随每次Offer递增（如第一次123456789，第二次123456790）。我曾遇到某硬件终端因服务端生成的sess-id含小数点（如123456789.1）导致协商失败，抓包发现它直接返回488错误——因为RFC明文规定sess-id是“non-negative decimal integer”。

• c=行（Connection）：c=<nettype> <addrtype> <connection-address>。这里写0.0.0.0是WebRTC的惯用法，表示“具体地址由后续a=candidate决定”。但若你在SIP场景中看到c=IN IP4 203.0.113.10，就要警惕：这个IP必须和实际RTP包源地址一致，否则防火墙会丢弃媒体流。某次线上故障，就是因CDN节点将c=行中的公网IP误替换为内网IP，导致所有外网用户收不到视频。

• t=行（Timing）：t=<start-time> <stop-time>。设为0 0表示“永久有效”，但真实会议系统会填入精确的UTC时间戳（如t=1717027200 1717030800对应2024-05-30 08:00:00至09:00:00）。这里有个隐藏陷阱：若两端系统时钟偏差超15分钟，某些STUN服务器会拒绝响应，因为DTLS证书有效期校验依赖时间同步。

• a=group:BUNDLE audio video：这是WebRTC的“捆绑大法”。它告诉对方：“把音频和视频流复用到同一个5-tuple（源IP:端口→目的IP:端口）上传输”。好处是减少NAT映射数量、降低ICE连通性检测耗时。但代价是——一旦该5-tuple网络抖动，音视频同时卡顿。我们曾为金融客户定制方案时禁用BUNDLE，改用a=group:LS audio video（Lip Synchronization），让音视频走不同端口，牺牲100ms同步精度换取单流稳定性。

2.2 媒体级字段：每路流的“专项合同”

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:0g4z a=ice-pwd:qzjw7x8y9k0l1m2n3o4p5q6r7s8t9 a=fingerprint:sha-256 1A:2B:3C:4D:5E:6F:7G:8H:9I:0J:1K:2L:3M:4N:5O:6P:7Q:8R:9S:0T:1U:2V:3W:4X:5Y:6Z a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10;useinbandfec=1 a=ssrc:123456789 cname:abcd1234

• m=行（Media）：m=<media> <port> <proto> <fmt> ...。<port>为9表示“使用默认端口”，实际端口由a=ice-ufrag等ICE候选者决定；<proto>中的UDP/TLS/RTP/SAVPF是关键：SAVPF代表“Secure Audio/Video Profile with Feedback”，即支持RTCP反馈（如PLI、FIR），这是实现视频自适应码率（ABR）的基础。若此处写RTP/AVP（不加密），则无法启用DTLS-SRTP，安全性归零。

• a=rtpmap:与a=fmtp:：这是编解码能力的“双保险”。a=rtpmap:111 opus/48000/2声明“payload type 111对应Opus编码，采样率48kHz，双声道”；a=fmtp:111 minptime=10;useinbandfec=1则细化“最小打包时长10ms，启用带内前向纠错”。注意：fmtp参数必须与接收端解码器能力严格匹配。某次Android端接入iOS会议时，iOS发送useinbandfec=1，但Android老版本libopus未开启FEC支持，导致音频断续——最终方案是在Offer中主动移除该参数，改用a=rtcp-fb:111 nack（基于RTCP的NACK重传）。

• a=setup:actpass：DTLS角色协商。actpass表示“我既能当主动方也能当被动方”，实际建连时由Offer方强制设为active，Answer方设为passive。这里有个硬核细节：若两端同时设为active，DTLS握手会因双方都等待对方Hello而超时失败。我们在线上监控中加入此字段校验，当发现异常组合时自动触发告警。

• a=extmap:：RTP头扩展映射。urn:ietf:params:rtp-hdrext:ssrc-audio-level对应音频音量指示（VAD），用于UI显示“谁在说话”。但某些低端芯片平台不支持该扩展，需在Offer中动态移除，否则对方收到未知extmap会静默丢包。

2.3 ICE与DTLS：穿越NAT的“通关文牒”

a=candidate:1 1 udp 2130706431 192.168.1.100 54321 typ host generation 0 a=candidate:2 1 udp 1694498815 203.0.113.10 54321 typ srflx raddr 192.168.1.100 rport 54321 generation 0 a=candidate:3 1 udp 1004011519 203.0.113.20 54321 typ relay raddr 203.0.113.10 rport 54321 generation 0

• a=candidate:行是ICE的命脉。每行包含5个关键信息：foundation（候选者唯一标识）、component-id（1=RTP,2=RTCP）、transport（固定为udp）、priority（优先级算法：2^32×type preference + 2^24×local preference + 2^8×(256 - component-id) + (256 - generation)）、address（IP地址）、port、type（host/srflx/relay）。priority值越大越优先，但很多开发者误以为typ relay一定比typ host优先——其实host的type preference是126，srflx是100，relay仅10，所以host候选者priority天然更高。某次跨国会议卡在“connecting”状态，就是因为服务端错误地将relay候选者priority设得过高，导致终端跳过本地直连路径，强行走高延迟中继。

• a=ice-ufrag/a=ice-pwd：ICE认证凭据。ufrag是随机字符串，pwd是密码，两者在Offer/Answer中必须完全一致。它们的作用是防止STUN Binding Request被篡改——STUN包中会携带MESSAGE-INTEGRITY属性，其HMAC-SHA256值由pwd计算得出。若Answer中pwd与Offer不匹配，STUN响应将被丢弃，ICE永远无法进入connected状态。

3. WebRTC SDP协商实战：从Offer生成到Answer确认的完整链路

理解SDP结构只是第一步，真正的挑战在于如何让它在复杂网络中稳定工作。下面我以一个真实项目——为某教育平台开发低延迟互动课堂——为例，还原SDP协商的完整生命周期。所有代码基于Chrome 115+和最新WebRTC API，避免使用已废弃的createOffer({offerToReceiveAudio:true})等旧语法。

3.1 Offer生成：不只是调用API，更是策略决策

// 初始化PeerConnection（关键配置） const pc = new RTCPeerConnection({ // ICE服务器：必须包含stun和turn，且turn需带credential iceServers: [ { urls: "stun:stun.l.google.com:19302" }, { urls: "turn:turn.example.com:3478", username: "user123", credential: "pass456" } ], // 关键策略：禁用不必要功能降低协商复杂度 iceTransportPolicy: "all", // 允许host/srflx/relay所有类型 bundlePolicy: "max-bundle", // 强制音视频捆绑 rtcpMuxPolicy: "require", // 强制RTP/RTCP复用 // 编解码偏好：按性能排序，Opus放首位 offerToReceiveAudio: true, offerToReceiveVideo: true }); // 添加本地媒体流（假设已获取getUserMedia成功） pc.addTrack(localStream.getAudioTracks()[0], localStream); pc.addTrack(localStream.getVideoTracks()[0], localStream); // 生成Offer：这才是真正的技术分水岭 async function createOffer() { try { // Step 1: 调用原生API生成基础Offer const offer = await pc.createOffer({ // 指定offer类型，避免默认生成answer offerToReceiveAudio: true, offerToReceiveVideo: true }); // Step 2: 修改SDP内容——这才是高手和新手的分界线 let sdp = offer.sdp; // 【避坑技巧1】移除不支持的编解码，避免协商失败 // 某些Android设备不支持H.265，但Chrome默认包含，需过滤 sdp = sdp.replace(/m=video.*?H265.*?\r\n/g, ""); // 【避坑技巧2】强制设置VP8为首选，规避H.264专利问题 sdp = sdp.replace(/m=video.*?120.*?\r\n/, "m=video 9 UDP/TLS/RTP/SAVPF 120 121\r\n"); sdp = sdp.replace(/a=rtpmap:120.*?\r\n/, "a=rtpmap:120 VP8/90000\r\n"); // 【避坑技巧3】添加关键扩展，提升弱网体验 if (!sdp.includes("a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01")) { sdp = sdp.replace( /a=extmap:1.*?\r\n/, "a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\n" + "a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\n" + "a=extmap:3 https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-header-extension\r\n" ); } // Step 3: 应用修改后的SDP await pc.setLocalDescription(new RTCSessionDescription({ type: "offer", sdp })); console.log("Offer已生成并设置:", sdp.substring(0, 200) + "..."); return { type: "offer", sdp }; } catch (err) { console.error("Offer生成失败:", err); } }

这段代码的关键不在createOffer()调用本身，而在于三处SDP手动干预：

• 编解码精简：移除H.265等非必需编码，避免老旧终端因不识别payload type而静默失败；
• 编码器锁定：强制VP8为首选，绕过H.264专利授权风险（某次海外上线因H.264许可问题被临时下架）；
• 扩展增强：注入Transport-Wide CC（TWCC）扩展，为GCC（Google Congestion Control）算法提供精准丢包反馈，这是实现500ms内弱网自适应的核心。

提示：不要迷信RTCPeerConnection的“智能协商”。Chrome生成的Offer默认包含20+种编解码，而真实终端可能只支持其中3种。主动精简SDP，比事后排查“为什么对方收不到视频”高效十倍。

3.2 Answer生成：不只是响应，更是能力对齐

// 收到远端Offer后，生成Answer async function handleRemoteOffer(remoteOffer) { try { // Step 1: 设置远端Offer await pc.setRemoteDescription(new RTCSessionDescription(remoteOffer)); // Step 2: 创建Answer（此时本地已知远端能力） const answer = await pc.createAnswer(); // Step 3: 深度定制Answer SDP——重点在“能力裁剪” let sdp = answer.sdp; // 【核心技巧】只保留Offer中出现的编解码，避免“答非所问” const offeredCodecs = extractCodecsFromOffer(remoteOffer.sdp); // 自定义函数，解析m=行中的payload types sdp = filterUnofferedCodecs(sdp, offeredCodecs); // 【关键优化】根据网络质量动态调整视频参数 if (networkQuality === "poor") { // 弱网时禁用VP9，强制VP8 + 低分辨率 sdp = sdp.replace(/m=video.*?121.*?\r\n/, "m=video 9 UDP/TLS/RTP/SAVPF 120\r\n"); sdp = sdp.replace(/a=fmtp:121.*?\r\n/, ""); // 移除VP9高级参数 sdp = sdp.replace(/a=x-google-flag:conference.*?\r\n/, ""); } // Step 4: 设置本地Answer await pc.setLocalDescription(new RTCSessionDescription({ type: "answer", sdp })); console.log("Answer已生成:", sdp.substring(0, 200)); return { type: "answer", sdp }; } catch (err) { console.error("Answer生成失败:", err); } } // 辅助函数：从Offer中提取远端支持的payload types function extractCodecsFromOffer(offerSdp) { const codecs = []; const mediaLines = offerSdp.split('\n').filter(line => line.startsWith('m=video') || line.startsWith('m=audio')); for (const line of mediaLines) { const parts = line.split(' '); // m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 -> 取120,121,126 for (let i = 4; i < parts.length; i++) { const pt = parseInt(parts[i]); if (!isNaN(pt)) codecs.push(pt); } } return codecs; }

Answer阶段的精髓在于**“能力对齐”而非“能力堆砌”**。很多团队错误地认为Answer应尽可能列出所有本地支持的编解码，结果导致：

• 远端选择了一个它不支持的payload type（如Offer中没提121，Answer却写了a=rtpmap:121 VP9/90000），协商后媒体流静默；
• 弱网环境下Answer仍携带高码率参数（如a=fmtp:120 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f），导致首帧加载超时。

我们的解决方案是：Answer中只保留Offer明确声明的payload type，并根据实时网络质量动态降级。这套逻辑上线后，教育平台弱网（2G/高丢包）场景下的首帧时间从8.2秒降至1.7秒。

3.3 协商状态机：从stale到stable的七次心跳

SDP协商不是一蹴而就，而是一个状态跃迁过程。WebRTC定义了RTCSignalingState，但真实世界远比枚举值复杂。以下是我们在生产环境监控到的典型状态流转及耗时：

注意：completed状态不等于媒体可用！真正的媒体通路需等待ontrack事件触发，且首个RTP包到达。我们在线上埋点发现，从completed到首帧渲染平均还有230ms延迟，主要消耗在Jitter Buffer填充和解码器初始化。

4. SDP常见故障排查：从Wireshark日志到终端控制台的全链路诊断

再完美的SDP设计，也逃不过现实网络的毒打。下面整理我们过去三年处理的TOP 5 SDP相关故障，附带真实日志、定位方法和根治方案。这些不是理论推测，而是凌晨三点救火时记下的血泪笔记。

4.1 故障1：Offer/Answer中a=mid不匹配——“失联”的音视频流

现象：

• Chrome控制台报错：Failed to set remote answer sdp: Failed to apply the description for m=video: The mid 'video' does not match any media section in the local description.
• Wireshark抓包显示Offer中有a=mid:video，Answer中却是a=mid:vid

根因分析：
a=mid（Media Identifier）是SDP中媒体流的唯一身份证，Offer和Answer中同一路流的a=mid值必须完全一致（包括大小写）。某次升级WebRTC SDK后，新版本默认将视频mid设为vid，而旧版服务端仍按video解析，导致Answer被拒绝。

诊断步骤：

1. 在Chrome开发者工具中，打开chrome://webrtc-internals，找到对应PeerConnection的getStats()，查看outbound-rtp和inbound-rtp的mediaSourceId是否匹配；
2. 复制Offer/Answer的SDP文本，在VS Code中用正则a=mid:(\w+)分别提取双方mid值，肉眼比对；
3. 若使用SIP信令，检查SIP消息体中SDP是否被代理服务器截断或转义（如a=mid:video被改为a=mid%3avideo）。

根治方案：

• 在createOffer()前，显式设置mid：

  pc.addTransceiver("video", { direction: "sendrecv", streams: [localStream] }).mid = "video"; // 强制指定mid为"video"

• 服务端增加mid校验中间件，对不匹配的Answer返回488错误并记录告警。

4.2 故障2：a=fingerprint不一致——DTLS握手“胎死腹中”

现象：

• RTCIceConnectionState卡在checking，RTCDtlsTransportState为failed；
• Wireshark中看到大量STUN Binding Request，但无Binding Success Response；
• Chrome控制台报错：Failed to set remote description: DTLS fingerprint doesn't match.

根因分析：
a=fingerprint是DTLS证书的SHA-256摘要，用于验证证书真实性。Offer和Answer中的fingerprint必须指向同一张证书。某次灰度发布，A/B测试组使用了不同证书（一组用Let's Encrypt，一组用自签名），但服务端未区分下发，导致Answer中fingerprint与Offer不匹配。

诊断步骤：

1. 在chrome://webrtc-internals中，展开certificates节点，复制Offer和Answer对应的fingerprint值；
2. 使用OpenSSL命令验证指纹一致性：

   # 从证书文件计算指纹 openssl x509 -in cert.pem -sha256 -noout -fingerprint # 输出：SHA256 Fingerprint=1A:2B:3C:...:6Z

3. 检查SDP中a=fingerprint行是否被意外换行（如\r\n被替换为\n），导致解析失败。

根治方案：

• 统一证书管理：所有终端使用同一CA签发的证书，服务端下发前校验fingerprint一致性；
• 在setRemoteDescription()前，用JavaScript预校验：

  function validateFingerprint(sdp, expectedFp) { const fpLine = sdp.match(/a=fingerprint:sha-256\s+(.*)/i); if (!fpLine) return false; return fpLine[1].replace(/:/g, '').toLowerCase() === expectedFp.replace(/:/g, '').toLowerCase(); }

4.3 故障3：a=rtcp-mux缺失——RTP/RTCP“分家”导致卡顿

现象：

• 音频正常，视频卡顿严重；
• chrome://webrtc-internals中inbound-rtp统计显示packetsLost持续增长，jitter>100ms；
• Wireshark中看到RTP包（端口54321）和RTCP包（端口54322）走不同路径，RTCP包大量丢失。

根因分析：
a=rtcp-mux表示RTP和RTCP复用同一端口传输。若Offer中声明a=rtcp-mux，但Answer中遗漏，接收端会为RTCP单独开一个端口。在NAT环境下，该端口可能未被映射，导致RTCP反馈（如PLI请求关键帧）无法送达，发送端因收不到反馈而持续发送损坏帧。

诊断步骤：

1. 对比Offer/Answer SDP，搜索a=rtcp-mux是否存在；
2. 在chrome://webrtc-internals中，查看outbound-rtp的rtcpTransportId是否与outbound-rtp相同（相同表示复用）；
3. 使用tcpdump抓包，过滤udp port 54321 or port 54322，观察两路包的TTL和路由是否一致。

根治方案：

• 在RTCPeerConnection配置中强制启用：

  const pc = new RTCPeerConnection({ rtcpMuxPolicy: "require" // 必须复用，否则创建失败 });

• Answer生成时自动注入：

  if (!sdp.includes("a=rtcp-mux")) { sdp = sdp.replace(/a=sendrecv\r\n/, "a=sendrecv\r\na=rtcp-mux\r\n"); }

4.4 故障4：c=地址与a=candidate冲突——NAT“迷路”的媒体流

现象：

• 本地能看到远端画面，但远端黑屏；
• Wireshark中远端RTP包目标IP为0.0.0.0，明显错误；
• chrome://webrtc-internals中candidateType显示host，但ip为127.0.0.1。

根因分析：
c=行定义会话级连接地址，a=candidate定义具体传输地址。当c=行写0.0.0.0（WebRTC标准做法）时，a=candidate必须提供真实可达地址。若a=candidate中typ host的IP是内网地址（如192.168.1.100），而远端在公网，RTP包将发往该内网IP，必然失败。

诊断步骤：

1. 解析SDP中的c=行和所有a=candidate行，检查typ host的IP是否为公网可路由地址；
2. 使用ipconfig（Windows）或ifconfig（macOS/Linux）确认本机公网IP，对比a=candidate中的srflx和relay地址；
3. 在远端抓包，过滤ip.dst == <host-ip>，确认是否有RTP包到达。

根治方案：

• 禁用host候选者（仅在可控内网环境启用）：

  const pc = new RTCPeerConnection({ iceTransportPolicy: "relay" // 只用TURN中继 });

• 或在SDP中动态过滤：

  sdp = sdp.replace(/a=candidate:.*?typ host.*?\r\n/g, ""); // 移除所有host candidate

4.5 故障5：a=extmap扩展不支持——“听不见”的音量指示

现象：

• UI上“谁在说话”的麦克风图标不亮；
• chrome://webrtc-internals中inbound-rtp的audioLevel统计始终为0；
• Wireshark中RTP包无audio-level头扩展。

根因分析：
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level声明支持音量指示，但需两端同时支持且正确配置。某次Android端升级芯片固件后，新固件未实现该扩展，但SDP中仍声明支持，导致发送端不敢发送扩展数据。

诊断步骤：

1. 检查Offer/Answer中a=extmap:1是否存在且URI一致；
2. 在Wireshark中右键RTP包 →Decode As→ 设置RTP→Show RTP header extensions，观察是否有audio-level字段；
3. 查看chrome://webrtc-internals中outbound-rtp的headerExtensions是否包含audio-level。

根治方案：

• 发送端增加运行时探测：

  // 尝试发送带扩展的RTP包，监听是否被接收端丢弃 pc.addEventListener("track", (event) => { if (event.track.kind === "audio") { event.receiver.getStats().then(stats => { const audioStats = [...stats.values()].find(s => s.type === "inbound-rtp" && s.mediaType === "audio"); if (audioStats && audioStats.audioLevel === undefined) { console.warn("audio-level extension not working, disabling..."); // 动态关闭扩展 } }); } });

5. SDP进阶实践：在SIP信令、跨平台兼容与安全加固中的落地经验

SDP的价值不仅限于WebRTC内部协商，它更是音视频系统互联互通的通用语言。下面分享三个高价值场景的实战心得，这些方案已在多个千万级用户产品中验证。

5.1 SIP信令中的SDP：让传统电话系统“开口说话”

SIP（Session Initiation Protocol）是VoIP领域的基石，而SDP是其信令体（Message Body）的标准载体。当你的WebRTC应用需要对接企业PBX或SIP话机时，SDP就是唯一的