Summary

  • RFC 8445 turns possible transport addresses into checked candidate pairs, then gives one controlling ICE agent the bounded decision to nominate a valid pair. A nominated pair for every required component becomes the selected path; that receipt proves neither identity nor useful media or application outcome.
  • RFC 7675 renews consent for one 5-tuple, while RFC 8838's end-of-candidates signal closes the current candidate input. These are later, different claims. A reliable record keeps inventory, reachability, choice, consent and outcome separate.

The post-incident timeline looks reassuring. Candidates were gathered. Checks succeeded. A pair was nominated. The checklist completed. The selected pair appeared before the support ticket said the call had failed.

Someone circles the selection event and asks how a connected session could have no useful audio.

The question spends more evidence than the event contains. A selected candidate pair is not a call verdict. It is the result of a path-discovery and path-choice process performed by two ICE agents. It can identify the local and remote transport addresses chosen for a data-stream component. It can show which checks succeeded and which agent made the nomination. It cannot see a decoder, an authorization decision, a human ear or a business outcome.

That distinction is unusually visible in RFC 8445, the Standards Track ICE specification by Ari Keränen, Christer Holmberg and Jonathan Rosenberg. The document does not use one state to mean “everything worked.” It moves through an inventory, a test, a valid-list result, a nomination and a selected pair. Each stage answers a narrower question than the next team may wish it answered.

Keränen's name belongs in this history precisely as a documented contributor to collective standards work. The current IETF profile reviewed on 30 August 2026 lists 21 RFCs and responsibilities in the Thing-to-Thing Research Group, the Internet of Things Directorate and the Internet Research Steering Group. Those details are time-sensitive. RFC authorship is durable; neither establishes sole invention, control of deployed endpoints or authority over an application's result.

The operational lesson is not to distrust the selected pair. It is to let it be exact.

A candidate is an address offered for consideration

ICE begins with possibilities. RFC 8445 defines a candidate as a transport address that might receive data. A host address, a server-reflexive address learned across a NAT and a relayed address obtained through TURN describe different ways an agent may be contacted. Their existence says that the agent has gathered and exposed options. It does not say that any option reaches the peer.

A candidate pair joins one local candidate to one remote candidate. That pairing is still not a live path. It is a proposition: try sending from this local transport address to that remote transport address. Priorities order the propositions so more desirable combinations can be tested earlier, but priority is preference, not proof.

This is the first observability boundary. A signaling trace that received ten remote candidates has evidence of input completeness only to the degree that the sender has finished gathering and said so. It has no basis for reporting ten routes, ten peers or ten working paths. Candidate counts can change because interfaces, NAT mappings, relays and policy changed. None of those counts authenticates the person or organization behind an endpoint.

The minimum candidate receipt therefore needs a generation identifier, component, candidate type, transport address, base or related address where appropriate, priority, source of discovery and arrival time. The generation matters because an ICE restart creates a new decision context. A candidate from the old context cannot quietly become evidence for the new one.

A successful check is reachability, not selection

The agents form a checklist from candidate pairs and test them. A connectivity check is a STUN request-and-response transaction sent from the local candidate to the remote candidate. The addresses and ports are the same ones intended for the eventual data, which is why a successful transaction is valuable evidence: this pair worked for the protocol exchange under the conditions of the check.

Success moves a pair into the valid set. It does not by itself choose the final pair. Several pairs can be valid, and a higher-priority possibility may still be under examination. A triggered check from the other agent can accelerate reciprocal knowledge. The checklist records a search over possibilities, not a single universal handshake named connected.

Even the phrase “worked end to end” must retain its object. The STUN transactions demonstrate that the ICE agents could exchange those messages over the candidate pair. They do not establish that an SRTP packet was decrypted, a codec emitted sound, a data channel opened, an application accepted a participant or a user completed an intended action. Those later mechanisms may depend on the path. Dependence does not merge their receipts.

The distinction becomes practical during partial failure. A support system that keeps only ice_connected=true cannot distinguish a lack of remote candidates from a checklist in progress, a failed STUN transaction, a valid pair that was never nominated, a selected path followed by DTLS failure, or media that arrived but could not be decoded. One convenient bit erases the repair owner.

Nomination is a decision by a protocol role

ICE assigns one agent the controlling role and the other the controlled role. The controlling agent is responsible for the final pair choice. Once its local stopping criterion has been met, it chooses one valid pair and repeats a check carrying the nomination indication. The exact point at which it stops checking and the criterion used to choose among valid pairs are matters of local optimization, subject to the protocol's requirement that it eventually choose one pair for a component.

That makes nomination more than another reachability observation. It is a decision based on observations and local policy. A direct path may rank ahead of a relayed path; a product may wait for a more preferred candidate or decide that delay is worse than relay cost. The valid list constrains what can reasonably be chosen, but it does not dictate every policy trade-off.

The controlled agent does not make the same choice independently. It waits for nomination, runs the required check if necessary and records the nominated flag when the transaction succeeds. When each required component has a nominated pair, those pairs become selected pairs. Future data for those components uses the selected pairs.

“Selected” therefore identifies the result of a role-bearing decision. It is not mutual human consent, organizational approval or proof that both applications prefer the same business outcome. The roles belong to ICE agents. They should not be promoted into claims about employer hierarchy, account ownership or user intent.

A sound record names the controlling side, the role-conflict resolution if one occurred, the valid list at decision time, the pair chosen, the nomination transaction and the policy version that supplied the stopping and evaluation criteria. Without that context, a later analyst can see the winner but not why it won.

Selection is not the first possible data event

The word “selected” also tempts an incorrect sequence. RFC 8445 permits a valid pair for a component to carry data before selected pairs have been produced. The eventual selected pair is the pair retained for sending and receiving after nomination completes; it is not necessarily the first pair on which any application packet appeared.

That detail matters in both directions. Seeing early packets does not prove that the final pair had been selected. Seeing a selected pair does not prove that useful packets followed. A diagnostic timeline must be able to show provisional data on a valid pair, the nomination event, selected-pair installation, a later path change caused by restart, and the application observations on each path.

Media flow itself is not one receipt. Packet departure is different from packet arrival. Arrival is different from successful authentication or decryption. Decryption is different from jitter-buffer admission and decoding. Decoding is different from rendering. Rendering is different from a person perceiving intelligible sound. An application-level success can require yet another authorization or transaction result.

The selected pair answers an earlier question: which checked transport-address combination did the ICE process settle on for this component? It remains useful even if every later receipt fails. In fact, keeping it narrow makes it more useful, because it directs investigation past candidate discovery and toward the next unproven boundary.

Consent has a smaller scope and a new clock

Path selection is not permanent permission. RFC 7675, written by Matthew Perumal, Dan Wing, Rohan Ravindranath, Tirumaleswar Reddy and Martin Thomson, defines consent freshness as a later STUN request-and-response mechanism. Ari Keränen is not an author of that RFC; it is complementary evidence, not an attribution to him.

Consent to send applies to one 5-tuple. It means the remote endpoint continues to permit non-ICE traffic to that remote transport address. The specification calls this application-level consent and explicitly notes that no human intervention is involved. That wording blocks two common exaggerations at once: consent freshness is not a click by a person, and it is not a blanket grant covering every path.

A keepalive is not enough. A send-and-forget indication can maintain a NAT mapping without obtaining a response. Consent freshness requires an authenticated matching response. If fresh consent is not obtained before expiry, the endpoint must cease transmission on the affected 5-tuple and regain consent before resuming. A late response does not simply rewrite the expired interval as continuously authorized.

The application's reaction remains outside RFC 7675. It may display a reconnecting state, attempt an ICE restart, end a call or preserve some other session state. Consent loss identifies a permission boundary for traffic. It does not diagnose the codec, declare the user absent or explain why the remote endpoint stopped responding.

The monitoring join should therefore keep selected_pair_at apart from consent_last_confirmed_at, consent_expires_at and application_state_at. If the pair changes, the 5-tuple and its consent context change with it. A generic session-level consent=true can silently authorize the wrong path in the record even when the implementation behaves correctly.

End-of-candidates closes input, not the outcome

RFC 8838, by Emil Ivov, Justin Uberti and Philipp Hancke, allows candidates to be supplied incrementally. Checks can begin while gathering continues. That reduces setup delay, but it means an observer must distinguish “no more candidates have arrived yet” from “the agent says no more candidates will arrive for this generation.”

The end-of-candidates indication provides that closure. It is tied to an ICE generation and tells the receiver that the candidate supply for the relevant stream is finished or has been deliberately cut off after an acceptable gathering period. After sending it, an agent cannot trickle further candidates into the same ICE session; adding new ones requires an ICE restart.

Closure can help an agent decide that a checklist has failed when no valid pair exists, or stop waiting for a more preferred candidate when only a relayed path is valid. It still does not replace nomination. RFC 8838 preserves regular ICE semantics: the controlling agent must go through the pair-choice process, and nominated pairs can allow ICE to conclude even before every end-of-candidates indication arrives.

The two events are orthogonal. End-of-candidates says the search input is closed. Nomination says a controlling agent chose a valid pair. Selected-pair installation says the choice is now the path for the component. Consent freshness says traffic may continue on one 5-tuple. Application and media receipts describe the downstream use of those packets.

An incident ledger that preserves those verbs—gathered, checked, validated, nominated, selected, consented, transported, decrypted, decoded, rendered, completed—does more than improve troubleshooting. It keeps authority attached to the mechanism that earned it.

Ari Keränen's contribution is a documented boundary, not an ownership claim

RFC 8445 lists Keränen first among three authors. That is strong evidence of his participation in the collective specification that replaced RFC 5245's ICE account. It is not evidence that he alone invented NAT traversal, implemented a reader's product, chose a session's nominated pair or controlled the networks through which it ran.

The present IETF profile adds current institutional context: 21 RFCs and roles associated with T2TRG, the Internet of Things Directorate and the IRSG at the review date. These facts should be dated because roles change. RFC 7675 and RFC 8838 add essential operational boundaries but have different author groups; their ideas should not be reassigned to Keränen merely because they sit next to ICE in one article.

This careful attribution mirrors the protocol lesson. A name on a document, a candidate in a checklist and a selected pair in a session are all valuable records. Each loses value when turned into a larger claim it was never designed to support.

The candidate pair won a bounded contest. Success still had to be earned elsewhere.

Sources