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