https://datatracker.ietf.org/doc/rfc5245/
ice 原理:
1 收集候选(计算候选优先级，设置基础(Foundation)属性，选择默认候选)
2 offer/anwser sdp(包含1中的candidates all info), 角色判断
3 connect check
ice 实现即第17 example总结
1 client to stun request to get nat ip;
2 计算candidates 优先级，foundation 等(sort candidates 之后，放入sdp中 candidate1,candidate2),最高优先级的as default
3 client to server offer (sdp with all candidates)
4 server to stun request to get nat ip, but nat ip and local ip ,it is the same (stun request MAPPED-ADDRESS，RESPONSE-ADDRESS)
5 server to client answer (sdp with all candidates)
6 check 的时候决定角色（根据offer-answer３种情况）
7 server to client bind request for the first check connect, because it is network ip , connect fail (stun bind extension use-candidate,ice-controlled/controlling)
8 client to server bind request with natip(because natip different with local,prune local. (why local connect prune but sdp send local candidate to peer? ) ,
9 server to client bind response with nomination flag USE-CANDIDATE(controlling)
10 client add the pair in valid (marked as selected,since the Binding request contained the USE-CANDIDATE attribute.)
11 L 选择完之后，R这段也要走一遍trigger check，才能放入自己的valid list
12 server to client connect with the nominate pair, sucess ,and add it in valid list
13 both can media , Completed state
notes: ICE之STUN协议---Binding Request https://blog.csdn.net/glw0223/article/details/90728328
====================================================
rfc5245 笔记
1. Introduction
2. Overview of ICE
2.1. Gathering Candidate Addresses 3种local,reflexive(nat) ,relay
2.2. Connectivity Checks： stun request,response ；收到如果local candidates和本机收集的local candidates不一样则说明是nat 或者 relay
2.3. Sorting Candidates: The algorithm is described in Section 4.1.2
2.4. Frozen Candidates:FOUNDATION
2.5. Security for Checks
2.6. Concluding ICE
2.7. Lite Implementations
3. Terminology
4 Sending the Initial Offer
an agent must (1) gather candidates, (2) prioritize them, (3) eliminate redundant candidates, (4) choose default candidates, and then (5) formulate and send the SDP offer.
4.1. Full Implementation Requirements
4.1.1. Gathering Candidates
4.1.1.1. Host Candidates
4.1.1.2. Server Reflexive and Relayed Candidates. If an agent is gathering both relayed and server reflexive candidates,
it uses a TURN server. If it is gathering just server reflexive candidates, it uses a STUN server.
This specification only considers usage of a single STUN or TURN server
4.1.1.3. Computing Foundations
The foundation is an identifier
4.1.1.4. Keeping Candidates Alive
4.1.2. Prioritizing Candidates
priority 公式;
4.1.2.2. Guidelines for Choosing Type and Local Preferences
The RECOMMENDED values are 126 for host candidates, 100 for server reflexive candidates,
110 for peer reflexive candidates,and 0 for relayed candidates
4.1.4. Choosing Default Candidates
4.2. Lite Implementation Requirements
4.3. Encoding the SDP
If an agent is a lite implementation, it MUST include an "a=ice-lite"
session-level attribute in its SDP. If an agent is a full implementation, it "MUST NOT" include this attribute.
notes: sdp 就可以区分出来lite and full
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
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
(type,priority,foundation,component id, RelatedAddr)
5. Receiving the Initial Offer
5.2. Determining Role
For a full agent, this means nominating the candidate pairs that can be used by ICE for each media stream, and for generating the updated offer based on ICE's selection, when needed.
For a lite implementation, being the controlling agent means selecting a candidate pair based on the ones in the offer and answer , The controlled agent is told which candidate pairs to use for each media stream, and does not generate an updated offer to signal this information.
notes: scenaro Both agents are full:One agent full, one lite；Both lite
5.3. Gathering Candidates
5.4 Prioritizing Candidates
5.5. Choosing Default Candidates
5.6. Encoding the SDP
5.7. Forming the Check Lists
the agent forms candidate pairs, computes a candidate pair priority,orders the pairs by priority, prunes them, and sets their states.These steps are described in this section.
5.7.1. Forming Candidate Pairs
First, the agent takes each of its candidates for a media stream(called LOCAL CANDIDATES)
and pairs them with the candidates it received from its peer (called REMOTE CANDIDATES) for that media stream.
A local candidate is paired with a remote candidate if and only if the two candidates have the same component ID。
notes:the component ID is for the rtp or rtcp candidate identify。pair的时候需要相同rtp components id，这样不会串流.
Figure 6: Conceptual Diagram of a Check Lis
5.7.2. Computing Pair Priority and Ordering Pairs
公式计算pair优先级，sort
5.7.3. Pruning the Pairs (不需要)
5.7.4. Computing States
Figure 7: Pair State FSM
The initial states for each pair in a check list are computed by performing the following sequence of steps:
一个frozen 其他的waiting
There are three states:
Running: in progress
Completed: produced nominated pairs
Failed:
a check list is constructed as the consequence of an offer/answer exchange, it is placed in the Running state.
5.8. Scheduling Checks
Checks are generated only by full implementations.
The generation of both checks is governed by a timer that fires periodically for each media stream.
根据state is waiting or frozon, 有没有pair，走各种if-else
6. Receipt of the Initial Answer
收到peer answer,做下面的事情
It verifies that its peer supports ICE, determines its role, and for full implementations, forms the check list and begins performing ordinary checks.
6.1. Verifying ICE Support 验证ICE是否支持
there were a=candidate attributes or a=ice-mismatch in sdp
出现candidates 属性
例如对于RTP来说，c行和m行的IP地址和端口号出现在candidate属性中，rtcp属性的端口号也出现在candidate属性中。
a=candidate:1 1 udp 2013266431 10.10.110.3 50965 typ host
a=candidate:2 1 udp 2013266430 218.206.90.6 52852 typ host
a=end-of-candidates
6.2. Determining Role
角色分两种：controlling和controlled
controlling agent负责选择通信最终采用的candidate pair
full agent 模式对每一个流选择的candidate进行提名，基于ICE的选择结果发送刷新offer（主动发送offer）
Lite agent 作为controlling意味着基于OFFER和ANSWER（只有一个pair.lite 只有一个local candidates）选择一个candidate pair，controlled agent被动接受candidate pair的选择结果，也不产生刷新的offer去告知这个信息。
scenario1: 都是full实现：
I 产生offer的一方作为controlling，另一端作为controlled
II 双方都构造check list列表，运行ICE状态机，执行连通性检测(双方都连通性检测)
III controlling agent根据8.1节所述逻辑提议ICE最终选择的pair，然后双方都根据8.1.2节描述结束ICE流程。
notes: 8.1节选择的pair??
scenario2:一个full实现，一个lite实现：
I full实现作为controlling，lite作为controlled。
II 由full实现的agent构造check list列表，运行ICE状态机，执行连通性检测。
III 该agent还要根据8.1节所述逻辑提议ICE最终选择的pair，然后根据8.1.2节描述结束ICE流程。
IV lite实现agent指示监听连通性监测请求，并且响应，然后根据8.2节所述进行ICE判定。
对于lite实现，每个处理的媒体流都认为是Running态，整个ICE流程的状态也认为是处于Running态。
scenario3: 都是lite实现
I 产生offer的一方作为controlling，另一端作为controlled。
II 这种场景下，都不启动连通性检测。
III 只要offer/answer交换完成，双方都按照第8节描述的无连通性检测的流程处理。
冲突由携带offer/answer的上层协议通过glare detection的能力进行解决。
IV 每个处理的媒体流都认为是Running态，整个ICE流程的状态也认为是处于Running态。
https://blog.csdn.net/tommy1boy/article/details/819415536.3. Forming the Check List 构造check list
6.4. Performing Ordinary Checks
7 Performing Connectivity Checks a full implementation will both generate checks (acting as a STUN client) and receive them (acting as a STUN server), a lite implementation will only receive checks, and thus will only act as a STUN server.
notes:这章不主要，不需要了解实现细节，仅仅用于查资料备用
I 构造candidate pair
计算pair的优先级和排序:综合client,server的优先级计算pair优先级
II 修剪pairs（没看懂，但是不主要，没有应用）
III 计算状态
(1) 该check list的所有的pair设置为Frozen状态
(2) agent检查第一条流（offer或者answer中SDP的一个m行表示的流）的check list。
根据foundation+component id 设置 Waiting status
check list有三种状态：
Running：该流中ICE流程还在执行。
Completed：该流的所有component都已经产生了nominated pair。因此ICE已经完成，媒体流可以发送。
Failed：该流上的ICE流程检测失败。
当check list初始构造出来时，设置为Running状态。
(3) 调度检测
1)寻找check list中状态为Waiting的pair中优先级最高的pair
- 如果存在这样的pair：
- 基于该pair从local candidate向remote candidate发送STUN检测。构造STUN检测请求的步骤参考7.1.2节描述。
- 设置这个pair的状态为In-Progress。
- 如果没有这样的pair:
- 寻找check list中状态为Frozen 的pair中优先级最高的pair。
- 如果存在这样的pair：
+解冻此pair
+基于此pair发起检测，状态切换为In-Progress - 如果不存在这样的pair：
+停止该check list的定时器
在计算消息完整性时，用到了从对端SDP中获取到的用户名片段和密码。使用到的本端的用户名片段是可以直接取到的
(4) 执行连通性检测
7.1. STUN Client Procedures
7.1.1. Creating Permissions for Relayed Candidates
创建Relayed candidate的Permission
If the connectivity check is being sent using a relayed local candidate, the client MUST create a permission first if it has not already created one previously.
notes: 理解为turn server 需要permissisons
7.1.2. Sending the Request
The check is generated by sending a Binding request from a local candidate to a remote candidate.
notes: Binding request is for check connective
ICE extends STUN by defining several new attributes, including PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
检测通过从local candidate向remote candidate发送一个Binding请求而产生 ICE扩展STUN定义了一些新的属性：包括PRIORITY， USE-CANDIDATE，ICE-CONTROLLED和ICE-CONTROLLING。
这些扩展属性只用于ICE的连通性检测。
I PRIORITY和USE-CANDIDATE
II ICE-CONTROLLED和ICE-CONTROLLING
III 构造凭证
用于连通性检测的Binding请求必须使用STUN短期凭证机制。
凭证的用户名通过拼接对端发过来的username片段和本端的username片段.中间以冒号隔开。密码则使用对端提供的password。
7.1.2.1. PRIORITY and USE-CANDIDATE
根据公式计算优先级
The controlling agent MAY include the USE-CANDIDATE attribute in the Binding request.
The controlled agent MUST NOT include it in its Binding request.
This attribute signals that the controlling agent wishes to cease checks for this component,
and use the candidate pair resulting from the check for this component.
7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING
The agent MUST include the ICE-CONTROLLED attribute in the request if it is in the controlled role,
and MUST include the ICE-CONTROLLING attribute in the request if it is in the controlling role.
7.1.2.3. Forming Credentials
The username,The password
7.1.3. Processing the Response
response candidate pair
7.1.3.1. Failure Cases
7.1.3.2. Success Cases
client and server: ip,port 正确即可
7.1.3.2.1. Discovering Peer Reflexive Candidates 发现Peer Reflexive Candidates
agent需要检测响应中的映射地址，如果这个传输地址不同于任何一个local candidate，那么他就代表了一个新的candidate——一个peer reflexive candidate。同其他candidate一样，同样具有类型，base，优先级以及foundation。
这些项的取值如下：
类型设置为peer reflexive。
base设置为检测请求发送的那个local candidate
优先级等于Binding请求中的PRIORITY属性的值
foundation根据4.1.1.3节流程选择
然后这个peer reflexive candidate加入到该媒体流的local candidate列表中。
the agent MAY generate an updated offer which includes the peer reflexive candidate.
7.1.3.2.2. Constructing a Valid Pair
构造Valid Pair:
agent将会构造一个新的candidate pair，且其local candidate等于响应映射的那个地址,而remote candidate则等于请求发送的目标地址。
这个pair称为valid pair，因为已经被STUN连通性检测验证过了。
如果这个pair不在任何check list中，
那么agent将会为这个pair计算优先级：根据他的本端和对端candidate以及5.7节算法。
local candidate的优先级取决于他的类型。
如果不是peer reflexive类型,则等于SDP中为该candidate所赋的值。
如果是peer reflexive类型,则等于响应对应Binding请求中携带的PRIORITY 属性的值。
remote candidate的优先级则取对端的SDP中的相关值。
如果对端地址在在remote candidate列表中不存在该值，那么这个检测随后应该有一个triggered check。
这种情况下，这个remote candidate的优先级可以取这个triggered check的Binding请求中的PRIORITY属性值。
然后将这个pair加入到VALID LIST中。
根据优先级放入valid list,
如果是peer reflexive，优先级在stun bind request中
如果不是peer reflexive，优先级在sdp
The pair is then added to the VALID LIST.
7.1.3.2.3. Updating Pair States 更新pair状态
https://datatracker.ietf.org/doc/rfc5245/?include_text=1
7.1.3.2.4. Updating the Nominated Flag更新Nominated标志
If the agent was a controlling agent, and it had included a USE-CANDIDATE attribute in the Binding request, the valid pair generated from that check has its nominated flag set to true.
If the agent is the controlled agent, the response may be the result of a triggered check that was sent in response to a request that itself had the USE-CANDIDATE attribute.
Nominated Flag 就是选中的pair。Nominated Flag 由controlling做
controlling agent had included a USE-CANDIDATE attribute in the Binding request,
the valid pair generated from that check has its nominated flag set to true.
controlled agent:the response may be the result of a triggered check that was sent in response to a request that itself had the USE-CANDIDATE attribute.
7.1.3.3. Check List and Timer State Updates
7.2. STUN Server Procedures
总体概括两个scenario的作用
The agent MUST consider the username to be valid
offerer will receive a Binding request（ prior to receiving the answer from its peer. ）
If this happens, the agent MUST immediately generate a response
(including computation of the mapped address as described in Section 7.2.1.2).
The agent has sufficient information at this point to generate the response;
the password from the peer is not required.
Once the answer is received, it MUST proceed with the remaining steps required, namely, 7.2.1.3, 7.2.1.4, and 7.2.1.5 for full implementations.
7.2.1. Additional Procedures for Full Implementations
7.2.1.1. Detecting and Repairing Role Conflicts
重计算优先级。然后提名pair and generated updated offers
7.2.1.2. Computing Mapped Address
receive a relayed candidate, the source transport address used for STUN processing (namely, generation of the XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the TURN server.
2.3、XOR-PEER-ADDRESS
XOR-PEER-ADDRESS指定TURN服务器上看到的peer的地址和端口。(例如，如果peer在NAT之后，则为peer的服务器反射传输地址。)其编码方式与XOR-MAPPED-ADDRESS [RFC5389]相同
That source transport address will be present in the XOR-PEER-ADDRESS attribute of a Data Indication message,
if the Binding request was delivered through a Data Indication.
If the Binding request was delivered through a ChannelData message, the source transport address is the one that was bound to the channel.
7.2.1.3. Learning Peer Reflexive Candidates
发现peer的nat 地址和source address 不一样，说明新的reflexive remote candidate
If the source transport address of the request does not match any existing remote candidates,
it represents a new peer reflexive remote candidate.
This candidate is constructed as follows:
o The priority
o The type
o The foundation (arbitrary value)
If any subsequent offer/answer exchanges contain this peer reflexive candidate in the SDP,
o The component ID
This candidate is added to the list of remote candidates.
7.2.1.4. Triggered Checks
check pair.check username and pwd
这个是pair peer已经被对方测试通过了(stun request-response)，这面在做一遍(stun request-respond) 然后放入自己的valid list.
7.2.1.5. Updating the Nominated Flag
两个if-case 情况。 state is success and in-progress to set Nominated Flag
7.2.2. Additional Procedures for Lite Implementations
8 Concluding ICE Processing
8.1.1. Nominating Pairs
The controlling agent nominates pairs : regular nomination or aggressive nomination.
8.1.1.1. Regular Nomination 每对candidates pair都check connnect 一遍. 添加几个valid list,但是只选一个提名.USE-CANDIDATE attribute
8.1.1.2. Aggressive Nomination
With aggressive nomination, the controlling agent includes the USE-CANDIDATE attribute in every check it sends.
Once the first check for a component succeeds, it will be added to the valid list and have its nominated flag set. When all components have a nominated pair in nominated pair.
8.1.2. Updating States
根据the state of each check list +nominated pairs，介绍了不同if-case 情况
8.2. Procedures for Lite Implementations
There are two cases to consider:
The implementation is lite, and its peer is full.
The implementation is lite, and its peer is lite.
8.2.1. Peer Is Full
In this case, the agent will receive connectivity checks from its peer. When an agent has received a connectivity check that includes the USE-CANDIDATE attribute for each component of a media stream, the state of ICE processing for that media stream moves from Running to Completed.
When the state of ICE processing for all media streams is Completed, the state of ICE processing overall is Completed.
8.2.2. Peer Is Lite
Once the offer/answer exchange has completed, both agents examine their candidates and those of its peer.
o If there is a single pair per component, that pair is added to the Valid list.
If all of the components for a media stream had one pair, the state of ICE processing for that media stream is set to Completed.
If all media streams are Completed, the state of ICE processing is set to Completed overall.
The agent adds the selected pair for each component to the valid list.
The agent MUST NOT update the state of ICE processing when the offer is sent.
change the state to completed
8.3. Freeing Candidates
8.3.1. Full Implementation Procedures
8.3.2. Lite Implementation Procedures
A lite implementation MAY free candidates not selected by ICE as soon
as ICE processing has reached the Completed state for all peers for all media streams using those candidates.
9. Subsequent Offer/Answer Exchanges
The rules in Section 8 will cause the controlling agent to send an updated offer at the conclusion of ICE
processing when ICE has selected different candidate pairs from the default pairs.
This section defines rules for construction of subsequent offers and answers.
Should a subsequent offer be rejected, ICE processing continues as if the subsequent offer had never been made.
9.1. Generating the Offer
9.1.1. Procedures for All Implementations
9.1.1.2. Removing a Media Stream
9.1.1.3. Adding a Media Stream
If an agent wishes to add a new media stream, it sets the fields in
the SDP for this media stream as if this was an initial offer for that media stream (see Section 4.3).
9.1.2. Procedures for Full Implementations
9.1.2.1. Existing Media Streams with ICE Running
9.1.2.2. Existing Media Streams with ICE Completed
9.1.3. Procedures for Lite Implementations
9.1.3.1. Existing Media Streams with ICE Running
9.1.3.2. Existing Media Streams with ICE Completed
9.2. Receiving the Offer and Generating an Answer
9.2.1. Procedures for All Implementations
9.2.1.1. Detecting ICE Restart
9.2.1.2. New Media Stream ------init offer
If the offer contains a new media stream, the agent sets the fields in the answer as if
it had received an initial offer containing that media stream (see Section 4.3).
This will cause ICE processing to begin for this media stream.
9.2.1.3. Removed Media Stream
If an offer contains a media stream whose port is zero,
the agent MUST NOT include any candidate attributes for that media stream in its answer
and SHOULD NOT include any other ICE-related attributes defined in Section 15 for that media stream.
9.2.2. Procedures for Full Implementations
the username fragments, password, and implementation level MUST remain the same as used previously.
9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates
9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates
9.2.2.3. Existing Media Streams and remote-candidates
9.2.3. Procedures for Lite Implementations
In this case, both would have sent updated offers around the same time.
However, the signaling protocol carrying the offer/answer exchanges will have resolved this glare condition,
so that one agent is always the 'winner' by having its offer received before its peer has sent an offer.
The winner takes the role of controlled, so that the loser (the answerer under consideration in this section) MUST change its role to controlled.
两个controlling 则 采用glare condition.
https://datatracker.ietf.org/doc/rfc6337/?include_text=1 第4章第2节
notes 理解为：两个同时发送offer,本质还是看你是server or client，即是A or B.
server 之后继续发update or re-invite，reject 掉client的offer.client 发送prack给server.
9.3. Updating the Check and Valid Lists
9.3.1. Procedures for Full Implementations
9.3.1.1. ICE Restarts
9.3.1.2. New Media Stream
If the offer/answer exchange added a new media stream, the agent MUST create a new check list for it
9.3.1.3. Removed Media Stream
An agent MUST remove the check list for that media stream and cancel any pending ordinary checks for it.
9.3.1.4. ICE Continuing for Existing Media Stream
9.3.2. Procedures for Lite Implementations
1) the agent MUST start a new Valid list for that media stream
2) remember called the previous selected pairs
3) send media there as described in Section 11.1.
4) The state of ICE MUST change to Running
10. Keepalives
11. Media Handling
11.1. Sending Media
11.1.1. Procedures for Full Implementations
Agents send media using selected candidate pair.
Media sent from a relayed candidate is sent from the base through that TURN server, using procedures defined in [RFC5766].
If the local candidate is a relayed candidate, it is RECOMMENDED that an agent create a channel on the TURN server towards the remote candidate.
The selected pair for a component of a media stream is:
o equal to the highest-priority nominated pair for that component in the valid list if the state of the check list is Completed
the controlling agent sends an updated offer/answer exchange to remedy this disparity.
However, until that updated offer arrives, there will not be a match.
11.1.2. Procedures for Lite Implementations
A lite implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream.
11.1.3. Procedures for All Implementations
ICE has interactions with jitter buffer adaptation mechanisms
11.2. Receiving Media
12. Usage with SIP
12.1. Latency Guidelines
ICE requires a series of STUN-based connectivity checks to take place between endpoints.
Two cases can be considered -- one where the offer is present in the initial INVITE and one where it is in a response.
12.1.1. Offer in INVITE
收到offer（invite request）,收集candidates. 回复answer.
ice 通过sdp or Provisional Response Acknowledgment (PRACK) mechanism
once the answer has been sent, the agent SHOULD begin its connectivity checks.
Once candidate pairs for each component of a media stream enter the valid list, the answerer can begin sending media on that media stream.
12.1.2. Offer in Response
In addition to uses where the offer is in an INVITE, and the answer is in the provisional and/or 200 OK response,
ICE works with cases where the offer appears in the response.
The answer will arrive in a PRACK.
The 200 OK would contain no SDP, since the offer/answer exchange has completed.
Alternatively, agents MAY place the offer in a 2xx instead (in which case the answer comes in the ACK).
12.2. SIP Option Tags and Media Feature Tags
12.3. Interactions with Forking
12.4. Interactions with Preconditions
12.5. Interactions with Third Party Call Control
13. Relationship with ANAT
14. Extensibility Considerations
15. Grammar
This specification defines seven new SDP attributes -- the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-
ufrag", "ice-pwd", and "ice-options" attributes.
15.1. "candidate" Attribute
It contains a transport address for a candidate that can be used for connectivity checks.
candidate-attribute = "candidate" ":" foundation SP component-id SP
foundation = 1*32ice-char
component-id = 1*5DIGIT
transport = "UDP" / transport-extension
transport-extension = token ; from RFC 3261
priority = 1*10DIGIT
cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr,rel-port,extension-att-name,extension-att-value,ice-char
This grammar encodes the primary information about a candidate: its IP address, port and transport protocol,
and its properties: the foundation, component ID, priority, type, and related transport address
<connection-address>,<port>,<transport>,<foundation>,<component-id>,<priority>,<cand-type> <rel-addr> and <rel-port>
The grammar allows for new name/value pairs to be added at the end of the attribute.
15.2. "remote-candidates" Attribute
remote-candidate-att = "remote-candidates" ":" remote-candidate 0*(SP remote-candidate)
remote-candidate = component-ID SP connection-address SP port
The attribute contains a connection-address and port for each component.
This attribute MUST be included in an offer by a controlling agent for a media stream that is Completed, and MUST NOT be included in any other case.
notes: controlling agent 特有属性
15.3. "ice-lite" and "ice-mismatch" Attributes
The syntax of the "ice-lite" and "ice-mismatch" attributes, both of
which are flags, is:
ice-lite = "ice-lite"
ice-mismatch = "ice-mismatch"
"ice-lite" is a session-level attribute only, and indicates that an agent is a lite implementation.
"ice-mismatch" is a media-level attribute only, and when present in an answer,
indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute.
notes: 不支持ice
15.4. "ice-ufrag" and "ice-pwd" Attributes
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment and password used by ICE for message integrity.
Their syntax is:
ice-pwd-att = "ice-pwd" ":" password
ice-ufrag-att = "ice-ufrag" ":" ufrag
password = 22*256ice-char
ufrag = 4*256ice-char
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the beginning of a session.
notes: ice name and pwd
15.5. "ice-options" Attribute
The "ice-options" attribute is a session-level attribute.
It contains a series of tokens that identify the options supported by the agent.
Its grammar is:
ice-options = "ice-options" ":" ice-option-tag 0*(SP ice-option-tag)
ice-option-tag = 1*ice-char
16. Setting Ta and RTO
两个计算公式没啥用
17 example
L NAT STUN R
|RTP STUN alloc. | |
|(1) STUN Req | | |
|S=$L-PRIV-1 | | |
|D=$STUN-PUB-1 | | |
|------------->| | |
| |(2) STUN Req | |
| |S=$NAT-PUB-1 | |
| |D=$STUN-PUB-1 | |
| |------------->| |
| |(3) STUN Res | |
| |S=$STUN-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<-------------| |
|(4) STUN Res | | |
|S=$STUN-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|(5) Offer | | |
|------------------------------------------->|
| | | |RTP STUN
alloc.
| | |(6) STUN Req |
| | |S=$R-PUB-1 |
| | |D=$STUN-PUB-1 |
| | |<-------------|
| | |(7) STUN Res |
| | |S=$STUN-PUB-1 |
| | |D=$R-PUB-1 |
| | |MA=$R-PUB-1 |
| | |------------->|
|(8) answer | | |
|<-------------------------------------------|
| |(9) Bind Req | |Begin
| |S=$R-PUB-1 | |Connectivity
| |D=L-PRIV-1 | |Checks
| |<----------------------------|
| |Dropped | |
|(10) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|USE-CAND | | |
|------------->| | |
| |(11) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |USE-CAND | |
| |---------------------------->|
| |(12) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(13) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|RTP flows | | |
| |(14) Bind Req | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |<----------------------------|
|(15) Bind Req | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|<-------------| | |
|(16) Bind Res | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | |
|------------->| | |
| |(17) Bind Res | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | |
| |---------------------------->|
| | | |RTP flows
Figure 9: Example Flow
1) client to stun request to get nat ip;
2) 计算candidates 优先级，foundation 等(sort candidates 之后，放入sdp中 candidate1,candidate2),最高优先级的as default
3) client to server offer (sdp with all candidates)
4) server to stun request to get nat ip, but nat ip and local ip ,it is the same
5) server to client answer (sdp with all candidates)
6) check 的时候决定角色（根据ｏｆｆｅｒ－ａｎｓｗｅｒ ３种情况）
7) server to client bind request for the first check connect, because it is network ip , connect fail
8) client to server bind request with natip(because natip different with local,prune local. (why local connect prune but sdp send local candidate to peer? ) ,
9) server to client bind response with nomination flag USE-CAND(controlling)
10) client add the pair in valid (marked as selected,since the Binding request contained the USE-CANDIDATE attribute.)
11) L 选择完之后，R这段也要走一遍trigger check，才能放入自己的valid list
12) server to client connect with the nominate pair, sucess ,and add it in valid list
13) both can media , Completed state
18. Security Considerations
19. STUN Extensions
19.1. New Attributes
This specification defines four new attributes, PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
The PRIORITY attribute indicates the priority that is to be associated with a peer reflexive candidate,should one be discovered by this check.
It is a 32-bit unsigned integer, and has an attribute value of 0x0024.
The USE-CANDIDATE attribute indicates that the candidate pair resulting from this check should be used for transmission of media.
The attribute has no content (the Length field of the attribute is zero);
it serves as a flag. It has an attribute value of 0x0025.
The ICE-CONTROLLED attribute is present in a Binding request an indicates that the client believes it is currently in the controlled role.
The ICE-CONTROLLING attribute is present in a Binding request and indicates that the client believes it is currently in the controlling role.
The content of the attribute is a 64-bit unsigned integer in network byte order, which contains a random number used for tie-breaking of role conflicts.
19.2. New Error Response Codes
This specification defines a single error response code:
487 (Role Conflict): The Binding request contained either the ICE-CONTROLLING or ICE-CONTROLLED attribute, indicating a role that conflicted with the server.
20. Operational Considerations 网络操作-对应用来说基本没用
This section discusses issues relevant to network operators looking to deploy ICE.
20.1. NAT and Firewall Types
ICE was designed to work with existing NAT and firewall equipment.
Consequently, it is not necessary to replace or reconfigure existing firewall and NAT equipment in order to facilitate deployment of ICE.
ICE works best in environments where the NAT devices are "behave" compliant, meeting the recommendations defined in [RFC4787] and [RFC5766].
20.2. Bandwidth Requirements 计算每个steps的带宽
Deployment of ICE can have several interactions with available network capacity that operators should take into consideration.
20.2.1. STUN and TURN Server Capacity Planning //stun ,turn server需要的带宽
For each component of each media stream, there will be one or more STUN transactions from each client to the STUN server.
In a basic voice-only IPv4 VoIP deployment, there will be four transactions per call (one for RTP and one for RTCP, for both caller and callee).
Each transaction is a single request and a single response, the former being 20 bytes long, and the latter, 28.
TURN traffic is more substantial.
The TURN server will see traffic volume equal to the STUN volume.
in addition to the traffic for the actual media traffic.
The amount of calls requiring TURN for media relay is highly dependent on network topologies, and can and will vary over time.
20.2.2. Gathering and Connectivity Checks
The process of gathering of candidates and performing of connectivity checks can be bandwidth intensive.
20.2.3. Keepalives
20.3. ICE and ICE-lite 混合型不需要
20.4. Troubleshooting and Performance Management
ICE utilizes end-to-end connectivity checks, and places much of the processing in the endpoints.
SIP servers on the signaling path, typically deployed in the data centers of the network operator,
will see the contents of the offer/answer exchanges that convey the ICE parameters.
These parameters include the type of each candidate (host, server reflexive, or relayed),along with their related addresses.
Once ICE processing has completed, an updated offer/answer exchange takes place, signaling the selected address (and its type).
This updated re-INVITE is performed exactly for the purposes of educating network equipment
(such as a diagnostic tool attached to a SIP server) about the results of ICE processing.
20.5. Endpoint Configuration
ICE relies on several pieces of data being configured into the endpoints.
This configuration data includes timers, credentials for TURN servers, and hostnames for STUN and TURN servers.
ICE itself does not provide a mechanism for this configuration.
Instead, it is assumed that this information is attached to whatever mechanism is used to configure all of the other parameters in the endpoint.
21. IANA Considerations 介绍各种属性作用和用法举例
This specification registers new SDP attributes, four new STUN attributes, and one new STUN error response.
21.1. SDP Attributes
This specification defines seven new SDP attributes per the procedures of Section 8.2.4 of [RFC4566].
The required information for the registrations is included here.
21.1.1. candidate Attribute
Contact Name: Jonathan Rosenberg, [email protected].
Attribute Name: candidate
Type of Attribute: media-level
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides one of many possible candidate addresses for communication.
These addresses are validated with an end-to-end connectivity check using Session Traversal Utilities for NAT (STUN)).
21.1.2. remote-candidates Attribute
Contact Name: Jonathan Rosenberg, [email protected].
Attribute Name: remote-candidates
Type of Attribute: media-level
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the identity of the remote
candidates that the offerer wishes the answerer to use in its answer.
21.1.3. ice-lite Attribute
Contact Name: Jonathan Rosenberg, [email protected].
Attribute Name: ice-lite
Type of Attribute: session-level
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent has the minimum
functionality required to support ICE inter-operation with a peer that has a full implementation.
21.1.4. ice-mismatch Attribute
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE),
and indicates that an agent is ICE capable,but did not proceed with ICE due to a mismatch of candidates with
the default destination for media signaled in the SDP.
21.1.5. ice-pwd Attribute
Contact Name: Jonathan Rosenberg, [email protected].
Attribute Name: ice-pwd
Type of Attribute: session- or media-level
Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the password used to protect STUN connectivity checks.
21.1.6. ice-ufrag Attribute
Contact Name: Jonathan Rosenberg, [email protected].
Attribute Name: ice-ufrag
Type of Attribute: session- or media-level
Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the fragments used to construct the username in STUN connectivity checks.
21.1.7. ice-options Attribute
Contact Name: Jonathan Rosenberg, [email protected].
Attribute Name: ice-options
Type of Attribute: session-level
Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates the ICE options or extensions used by the agent.
21.2. STUN Attributes
This section registers four new STUN attributes per the procedures in [RFC5389].
0x0024 PRIORITY
0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED
0x802A ICE-CONTROLLING
21.3. STUN Error Responses
This section registers one new STUN error response code per the procedures in [RFC5389].
487 Role Conflict: The client asserted an ICE role (controlling or controlled) that is in conflict with the role of the server.
22. IAB Considerations
ICE is an example of a protocol that performs this type of function.
22.1. Problem Definition
The specific problems being solved by ICE are:
Provide a means for two peers to determine the set of transport addresses that can be used for communication.
Provide a means for a agent to determine an address that is reachable by another peer with which it wishes to communicate.
22.2. Exit Strategy
22.3. Brittleness Introduced by ICE
22.4. Requirements for a Long-Term Solution
22.5. Issues with Existing NAPT Boxes