WebRTC - TURN 和 ICE 函数 [英] WebRTC - TURN and ICE functions
问题描述
我正在尝试了解 WebRTC 的概念.正如我在一些描述中发现的(例如这里
UA1 收集到所有候选对象后，将它们按优先级从高到低的顺序排列，并在 SDP 提供消息的属性中将它们发送给 UA2.UA2 执行相同的候选收集并发送带有候选列表的 SDP 响应.每个 UA 获取两个候选列表并将它们配对以形成候选对.每个 UA 将这些收集到检查列表中并安排连接检查、STUN 请求/响应事务，以查看哪些对有效.图 3 显示了构成 UA 检查列表的候选对的组成部分.
ICE 将其中一个代理指定为控制代理"，另一个指定为受控代理".控制代理使用有效的候选对来提名一对用于媒体.有两种提名方法可以使用:
- 常规提名 检查一直持续到至少有一对有效的候选人对.控制代理从有效对中挑选，并在该对上发送带有标志的第二个 STUN 请求，以告诉对等方这是指定使用的那个.
- 主动提名 提名标志随每个 STUN 请求一起发送，一旦第一次检查成功，该媒体流的 ICE 处理完成并且不需要第二次 STUN 请求.
检查列表中的每个候选对都有一个与之关联的状态.一旦计算出检查列表，状态就由 UA 分配.有五种可能的状态:
- Frozen 这对只有在进入等待状态后才能被检查.要进入等待状态，其他检查必须先成功.
- 等待 一旦这是检查列表中优先级最高的对，就会执行检查.
- 进行中 已发送此对的支票，交易正在进行中
- 成功的配对检查结果.
- Failed 配对检查的失败结果.
以下链接包含 ICE 流程的更多信息和图表.
参考:
I'm trying to understand a concept of WebRTC. As I found in some descriptions (for example here http://www.innoarchitech.com/content/images/2015/02/webrtc-complete-diagram.png), there is such a way of making a connection:
- Call STUN, to get your IP:port address.
- Get some channel from TURN - with that channel you can send info to other peer.
- Send to other peer ICE candidates.
- Accept ICE candidates with other peers- start a call.
The question is, what do we need ICE candidates for? We know our IP, we can send it to TURN therefore to other peer, and on TURN we have a nice connection with other peer- so we don't have to scary about NATs. Why except that we are sending ICE candidates (why many?), and why we need to use them?
We have 3 main concepts here:
- ICE
- TURN
- STUN
The ICE negotiation is not that simple... To execute ICE, UAs have to identify all address candidates, transport addresses. Transport addresses are a combination of IP address and port for a particular transport protocol. There are three types of candidates:
- Host Candidate – transport address associated with a UA’s local interface
- Relayed Candidate – transport address associated with a TURN server (can only be obtained from a TURN server)
- Server Reflexive Candidate – translated address on the public side of the NAT (obtained from either a STUN server or a TURN server)
After UA1 has gathered all of its candidates, it arranges them in order of priority from highest to lowest and sends them to UA2 in attributes in an SDP offer message. UA2 performs the same candidate gathering and sends a SDP response with it’s list of candidates. Each UA takes the two lists of candidates and pairs them up to make candidate pairs. Each UA gathers these into check lists and schedules connectivity checks, STUN request/response transaction, to see which pairs work. Figure 3 shows the components of the candidate pairs that make up the UA check list.
ICE assigns one of the agents as the "Controlling Agent" and the other as the "Controlled Agent". The controlling agent used the valid candidate pairs to nominate a pair to use for the media. There are two nomination methods that can be used:
- Regular Nomination The checks continue until there is at least one valid candidate pair. The controlling agent picks from the valid pairs and sends a second STUN request on that pair with a flag to tell the peer that this is the one that is nominated for use.
- Aggressive Nomination The nomination flag is sent with every STUN request, once the first check succeeds ICE processing for that media stream is finished and a second STUN request is not needed.
Each candidate pair in the check list has a state associated with it. The state is assigned by the UA once the check list has been computed. There are five possible states:
- Frozen This pair can only be checked after being put in the waiting state. To enter the waiting state some other check must succeed first.
- Waiting As soon as this is the highest priority pair in the check list a check will be performed.
- In-Progress A check has been sent for this pair and the transaction is in progress
- Succeeded Successful result from pair check.
- Failed Failed result from pair check.
The link below includes more information and diagrams of the ICE flow.
Reference:
- http://www.vocal.com/networking/ice-interactive-connectivity-establishment/
- RFC https://tools.ietf.org/html/rfc5245#page-9
这篇关于WebRTC - TURN 和 ICE 函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
