从janus中学习webrtc的ice简单交换过程

最新推荐文章于 2025-06-28 17:35:30 发布

MeRcy_PM

最新推荐文章于 2025-06-28 17:35:30 发布

阅读量1.2w

点赞数 5

CC 4.0 BY-SA版权

分类专栏： webrtc

本文链接：https://blog.youkuaiyun.com/MeRcy_PM/article/details/55806415

本文通过web与Janus服务器的实时通信Demo，结合RFC5245，深入分析ICE（Interactive Connectivity Establishment）的连接流程。内容涉及NAT环境下客户端与服务器的交互，包括获取对外IP、交换ICE候选、STUN请求和连通性测试等步骤，探讨了常规提名和激进提名的区别，并以Janus服务器为例说明了lite模式的应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 简介：

本文通过web和janus进行实时音视频通信的Demo，结合rfc-5245来学习ice交换的过程。

2. 测试模型

本文测试模型为一个NAT内的web的客户端，向一个NAT内的janus服务器发起请求。

3. rfc 5245

本文只捡基础的一个流程进行分析，5245协议本身囊括的内容较多。(这里主要围绕2, 2.1, 2.2三段)。

ICE的过程主要分为三个过程：

1) 各个peer首先向各自的stun server请求，获取各自的对外IP。(非必须)

2) 各个peer收集自己的ice candidate，这里包括了本机的local地址，及打洞后获取的对外IP，双方交换ice candidate。

3) 各个peer收到对应的ice candidate后，排序后向各个candidate发起stun请求，用stun协议进行连通性测试，通过后择优。

4. 过程分析

本次例子客户端发往打洞服务器被墙……，从抓包上来看，客户端打洞请求发出，但是没有收到对端服务器的响应，而服务端响应正常。

下图为客户端打洞请求，但是并没有从相应的服务器得到相应的回复。

下图为服务端的打洞请求，服务端收到了打洞服务器的响应，并得到了自己的对外IP和端口。

接着我们继续查看客户端发给服务端的请求，这里还是查找POST请求，我们会发现，这里发送给服务端的ice candidate中都是NAT内部的IP。

服务端日志上正是收到如上部分的candidate。

[5261413890922073] Trickle candidate (sdparta_0): candidate:0 1 UDP 2122252543 192.168.0.102 55349 typ host
[5261413890922073] Trickle candidate (sdparta_0): candidate:0 2 UDP 2122252542 192.168.0.102 59517 typ host
[5261413890922073] Trickle candidate (sdparta_1): candidate:0 2 UDP 2122252542 192.168.0.102 50268 typ host
[5261413890922073] Trickle candidate (