WebRTC视频通话核心在于信令服务器与p2p连接的协作：信令服务器仅中转SDP和ICE候选者，不处理媒体流；P2P连接需严格按协商媒体能力、同步网络路径、等待连接就绪三步建立。
用 sublime Text 编写 WebRTC 视频通话应用，重点不在编辑器本身，而在于理清信令服务器与 P2P 连接的协作逻辑。Sublime 是轻量级代码编辑工具，适合写前端 js、后端 node.js 或 python 信令服务，但不提供运行时或网络能力——真正起作用的是你写的信令逻辑和浏览器原生的 RTCPeerConnection。
信令服务器：只是“传话员”，不碰媒体流
WebRTC 不自带信令机制，必须靠你自建服务在两个浏览器间中转 SDP 和 ICE 候选者。常见做法是用 node.js + Socket.IO 或 Python + flask-SocketIO 搭一个简单服务：
- 用户 A 创建 offer 后，通过 socket.emit(‘offer’, { roomId, sdp }) 发给服务器
- 服务器收到后，查出同房间的用户 B，再 socket.to(roomId).emit(‘offer’, {…}) 转发过去
- 用户 B 收到 offer，setRemoteDescription，生成 answer，再发回服务器，由服务器转给 A
- 双方交换完 SDP 后，开始收集并互相发送 ICE candidate（每次 candidate 都要单独 emit）
注意：信令服务器绝不处理音视频数据，也不参与 NAT 穿透；它只确保消息及时、准确送达对方。
P2P 连接建立：三步不能跳，顺序很重要
浏览器之间真正连上，依赖三个严格时序步骤，缺一不可：
- 先协商媒体能力：调用 createOffer → setLocalDescription → send offer；对方收到后 setRemoteDescription → createAnswer → setLocalDescription → send answer
- 再同步网络路径：双方开启 onicecandidate 回调，每拿到一个 candidate 就立即发送给对方；对方调用 addIceCandidate 加入连接池
- 最后等待连接就绪：监听 iceConnectionState（如 ‘connected’ 或 ‘completed’）和 signalingState（’stable’），二者都到位才算 P2P 通了
常见卡点：漏发 candidate、addIceCandidate 调用太早（remote description 还没 set）、跨域或 https 限制导致 getUserMedia 失败。
Sublime 中高效开发的关键习惯
用 Sublime 写这类应用，重在结构清晰、调试方便：
- 把信令消息格式统一定义在 constants.js 或 schema.py 里，比如 { type: ‘offer’, sdp: ‘…’, roomId: ‘xxx’ }，避免拼写错误
- 前端 JS 分三层写：ui 控制层（按钮/显示）、WebRTC 逻辑层（RTCPeerConnection 实例管理）、信令对接层（socket.on / emit 封装）
- 服务端日志加标识，例如 [roomId:abc][user:A] offer received，方便对照前后端行为
- 用 Sublime 的侧边栏多文件预览 + Ctrl+P 快速跳转，同时开着 index.html、main.js、server.js 查问题
基本上就这些。信令是胶水，P2P 是骨架，Sublime 只是你握笔的手——写对逻辑，跑起来并不难，但细节容易忽略。