下载.jpg
rfc 5245笔记：https://www.jianshu.com/p/0a3fa81d0063
ice作用:与candidates相关的工作. moule: 验证ICE支持能力,候选地址采集,候选地址优先级排序(默认候选地址),角色确定和角色作用,checklist and 连通性检测.
ice 流程:gather candidates(优先级排序；去除冗余；选择默认Candidate)--sdp(offer/answer)--connectivity check---nominated flag/valid list---state completed
ice state: frozen--waiting--in progressing ---completed
ice 架构图:
image.png
gather candidates(优先级排序；去除冗余；选择默认Candidate)--sdp(offer/answer)--connectivity check---nominated flag/valid list---state completed
ice state: frozen--waiting--in progressing ---completed
0 名词解释
candidate info:IP address, port and transport protocol,
and properties:the foundation, component ID, priority, type(reflexive,relay,local), and related transport address:
agent is client or server;
component-id: is rtp or rtcp candidate identify,rtp is １,rtcp is ２
foundation : is composed of 1 to 32 <ice-char>
BASE:指与反射地址对应的本机地址.本机地址的BASE就是本机地址.
Relayed Candidate的Base就是Candidate 自己，如果Relayed Candidate和Host Candidate相同，这个地址应该被丢弃。
1 turn server and stun server 区别？
stun bind 就是为了直连穿透nat。
stun bind request 中username：ice-ufra； pwd： ice-pwd
stun的返回的ip，port rtp也用这个，因为这个翻译的地址已经和内网地址绑定了，肯定有效不能找错
因为RTP与RTCP包总是以0b10(v=2)打头，而STUN是0b00
turn server 只管交互信令，即信令核心交换sdp
TUN服务器的端口号 默认是3478
2 验证ICE支持能力
sdp a=candidate,...
3 候选地址采集 gathering candidates
三种方法.local candidates，nat 反射(stun server), relay ip(turn server)
4 候选地址优先级排序
每个agent 3 个candidates则3*3=9次检测，检测即STUN bingding，stun request/response.
每种candidates有权重,根据公式计算优先级,sort 计算候选的优先级.
比如:设置主机候选的类型优先参数为最高值126,服务器反射候选的类型优先参数为100,中继候选的类型优先参数为最低值0.本地参数设为65 535,分组ID为1.
经计算,主机候选的优先级为2 130 706 431，服务器反射候选的优先级为1 694 498 815，中继候选的优先级为16 777 215
按候选优先级高低排序。
分配主机候选的基础(Foundation)属性为1，服务器反射候选的基础属性为2，中继候选的基础属性为3。
5 默认候选地址
优先级最高的
6 sdp 解码 (offer 就是sdp)
Lite必须在SDP包含一个“a=ice-lite”。如果是Full实现，则不能包含该属性。sdp: This specification defines seven new SDP attributes --
the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", and "ice-options" attributes.
sdp example:
The offer, with the variables replaced with their values, will look like (lines folded for clarity):
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
c=IN IP4 192.0.2.3
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
notes: a="lite"在sdp中(这个是config的)
7 offer-answer
offer/update -answer,第一次offer-answer，之后用UPDATE 更新
offer内容是sdp(a=candidate,video,audio,a="lite")
两个同时发送offer，都是full，谁是controlling？
https://datatracker.ietf.org/doc/rfc6337/?include_text=1 第4章
理解为基于uac和uas，这个应该是connect的时候知道的，uac 发送prack，uas 发送 update
双方通过信令 or http 交换sdp，sdp中包含candidates
8 角色确定和角色作用
controlling特有的属性
controlled特有的属性:a=remote-candidates attribute.
三种情况：根据full,lite 模式 配置和offer-answer 决定角色controlling or controlled
- 两个full
offer一方是server，是controlling.另一方是client，controlled - 一个full，一个lite
肯定是full一方发送offer。offer一方是server，是controlling.另一方是client，controlled - 两个lite
offer一方是server，是controlling.另一方是client，controlled.
9 对于full实现来说，还将构造check list以及开始连通性检测
webrtc使用sdp除了描述媒体类型，还有一些ice的连接候选项。
I 服务器提供offer sdp
II chrome浏览器收到sdp之后,创建应答sdp和ice 候选项发送到服务器.
III 双方都收到sdp之后会首先进行ice连接（即一条udp链路）。
IV 连接建立之后，发起dtls交互，得到远端和本地的srtp的key ??
(分别用于解密远端到来的srtp和加密本地即将发出去的rtp数据包）。
执行连接检查(ice select pair)( 根据优先级进行排序, 冻结候选地址 )
(1) 按优先级对candidate pair进行排序
根据上面三种的权重,计算优先级
https://blog.csdn.net/dxpqxb/article/details/22040017?locationNum=10
(2) 按照优先级顺序对每个candidate pair发起检查
(3) 对单agent发起的检查进行确认
image
checklist列表和其他模块之间的关系汇总
候选配对状态计算：ice candidates: Frozen,Waiting,In-Progress,Succeeded,Failed
ice state 运行状态，完成状体，失败状态(ice 结束)
waiting 状态即准备test的candidates pair，frozen指没有测试的candidates pair
image
connect check:两种模式，两种角色，两种提名
Full Implementation Procedures and Lite Implementation Procedures
controlling nominate REGULAR NOMINATION or AGGRESSIVE NOMINATION.
regular 和 aggressive 提名: 前者一对一对测试，后者只要测试成功一对就media发包
连通性检测.
- 提名 (1) regular 每对都检测，最终根据rtt 提名 (2) aggressive 则第一个测试通过的就是
- 两端提名的pair不一样.统一两端;听controlling的，因为controlling nominate?
统一两端pair用update offer
STUN Extensions:
required
0x0024 : priority
0x0025 : use-candidate (nominated pair flag)
optional
0x8029 : ice-controlled
0x802a : ice-controlling
stun extension: USE-CANDIDATE,ICE-CONTROLLED,ICE-CONTROLLING
10 lite特有属性
都有独立ip. 不做收集ip，和check connect.a="lite" 在sdp中
When two lite implementations connect, no checks are sent.
Lite 实现无需收集candidate，只包含自身的host candidate。
lite 不需要连通性检测.lite 肯定是独立ip(因为一定能连上它,不做stun bind)，只要能够正常"响应"连通性检测的请求即可
11 定时检查
12 notify 媒体
接收和发送rtp，rtcp数据（srtp加密）了，通过ice的连接发送出去。
(dtls 和 srtp 的数据包都是通过ice的udp连接进行传输的。)
others:
trickle ice：
实际使用webrtc开发音视频应用时遇到的一个问题是呼叫“建立很慢”，原因是：ice过程耗费过多时间
a=ice-options:trickle 通知对端支持trickle，即sdp里面描述媒体信息和ice候选项的信息可以分开传输。
使用Trickle ICE必须定义一个方式表明支持Trickle ICE，双方都要支持trickle ice
这中间时间浪费在所有candidate都获取后才发送，所以为了加速通话建立时间，把连通性检测的时间提前，方案叫trickle ice,
其思想是客户端一边收集candidate一边发送给对方，比如local candidate 不需要通过stun获取直接就可以发起，
这降低了了连通性检测完成的时间
turn server 实现：https://blog.csdn.net/CrystalShaw/article/details/103505029
网友评论