ice 笔记

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 架构图: 没找到
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 1,rtcp is 2
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

turn server 实现:[https://blog.csdn.net/CrystalShaw/article/details/103505029]
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.根据rtt选择最优的
每种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 模式与controlling,controlled 关系
1) 两个full 
offer一方是server,是controlling.另一方是client,controlled
2) 一个full,一个lite 
肯定是full一方发送offer。offer一方是server,是controlling.另一方是client,controlled
3) 两个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发起的检查进行确认

checklist列表和其他模块之间的关系汇总
候选配对状态计算:ice candidates: Frozen,Waiting,In-Progress,Succeeded,Failed
ice state 运行状态,完成状体,失败状态(ice 结束)
waiting 状态即准备test的candidates pair,frozen指没有测试的candidates pair

connect check:两种模式,两种角色,两种提名
Full Implementation Procedures and Lite Implementation Procedures
controlling nominate REGULAR NOMINATION or AGGRESSIVE NOMINATION.
regular 和 aggressive 提名: 前者一对一对测试,后者只要测试成功一对就media发包 

连通性检测. 
1) 提名  (1) regular 每对都检测,最终根据rtt 提名   (2) aggressive 则第一个测试通过的就是 
2) 两端提名的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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章