主要观点：

• WebRTC 实施和现场试验在演进，但仍有诸多问题使其在现实世界中可部署性受限，若从头再来可能会有所不同。
• 举例说明近期关于 WebRTC 相关的讨论及问题，如 W3C 讨论和 Quobis 的 CTO 帖子。
• 作者 Tim Panton 自 WebRTC 存在之前就开始研究，虽其设备已达 10 亿，但实现从 Raspberry Pi 的传感器获取实时数据并在浏览器显示仍困难重重。
• 虽有相关开源库，但在实现 WebRTC 数据通道时，花费大量时间在 SDP 操作、解析和传输上，远多于加密和 ICE 部分。
• SDP 格式复杂且难以解析，很多部分含义不明，如 a=msid-semantic: WMS 等，且不同位置设置 ICE 密码含义不同，增加了代码出错的可能性。
• 问题源于 IETF 的“未来遗留互操作性”决策，为未来可能的设备而设计，目前并无实际的遗留设备使用该协议，导致 SDP 复杂且需额外的 API 来操作。

关键信息：

• 提到相关网站如AlanQuayle.com、WebRTChacks.com等。
• 涉及的技术和协议有 WebRTC、IAX2、SCTP/DTLS/ICE/UDP、Session Description Protocol (SDP)等。
• 提及的公司和组织有 W3C、IETF、Google、Jitsi、Asterisk 等。

重要细节：

• 作者自PhoneFromHere.com时代就开始研究，如今在实现 Raspberry Pi 与浏览器间的 WebRTC 通信时遇到困难。
• 构建 Google 的 WebRTC 代码时需去除音频和视频依赖及浏览器假设并交叉编译到 Pi 上，且过程艰难。
• SDP 中 15 行内容实际只有 4 行传达有用信息，但 15 行必须完全正确，否则 SDP 将被拒绝。
• a=setup:actpass 属性用于指示 DTLS 连接的发起方，是为支持“早期媒体”而设计，但作者不理解其必要性。
• 18 个月前就指出问题但为尽快推出标准而妥协，现在仍在添加 SDP 相关内容且需 API 来操作。

总结：WebRTC 在发展过程中存在诸多问题，如 SDP 复杂难解析、实现困难等，这些问题源于“未来遗留互操作性”决策，虽 WebRTC 成就显著，但 API 设计需改进，应借鉴爱因斯坦的原则，让其更简单易用。