Module candidate 

Candidate types, priorities, and SDP a=candidate parsing. ICE candidates: the addresses an agent can be reached at.

A Candidate pairs a transport address with a CandidateType — host, server-reflexive, peer-reflexive or relay — and the bookkeeping ICE needs: a priority, a foundation, and last-sent/last-received times that feed consent freshness.

Type drives priority, and priority drives check order: host candidates are tried first because they need no traversal, relay candidates last because they always cost an extra hop. The foundation groups candidates that share a base and transport, so redundant checks can be skipped.

Each type has its own constructor module (candidate_host, candidate_relay, …), all built on the shared CandidateConfig.

Modules

candidate_host

Host candidates: an address on a local interface.

candidate_pair

A local/remote candidate pair and its check state. Candidate pairs and their check state.

candidate_peer_reflexive

Peer-reflexive candidates, learned from an inbound check’s source address.

candidate_relay

Relay candidates, allocated on a TURN server.

candidate_server_reflexive

Server-reflexive candidates, learned from a STUN Binding response.

Structs

Candidate

One ICE candidate: a transport address this agent can be reached at, or can reach a peer at, together with its type, priority and liveness bookkeeping.

CandidateConfig

The fields common to every candidate type, used when constructing one.

CandidateRelatedAddress

Convey transport addresses related to the candidate, useful for diagnostics and other purposes.

Enums

CandidateType

Represents the type of candidate CandidateType enum.

Functions

unmarshal_candidate

Creates a Candidate from its string representation.