pub struct Candidate {
pub foundation: Foundation,
pub component: ComponentId,
pub transport: Transport,
pub priority: Priority,
pub address: IpAddr,
pub port: u16,
pub kind: CandidateType,
pub related: Option<RelatedAddress>,
pub extensions: Vec<(String, String)>,
}Expand description
One a=candidate line (RFC 8839 §5.1). Media-level.
Fields§
§foundation: FoundationThe foundation.
component: ComponentIdWhich component of the stream this candidate is for.
transport: TransportThe transport. Always Transport::Udp; see the type.
priority: PriorityThe priority, range-checked on parse.
address: IpAddrThe transport address.
port: u16The port.
kind: CandidateTypeHow the candidate was obtained.
The raddr/rport pair.
RFC 8839 §5.1 requires it for srflx, prflx and relay and forbids it for host, and
a candidate sipx generates must obey that. It is not enforced when reading: §5.1 gives
the field to “diagnostics”, nothing in RFC 8445’s checks consults it, and dropping a
peer’s only working candidate over a diagnostic field would trade a call for a nicety. A
privacy-preserving agent writes 0.0.0.0/:: and port 9 here, which is ordinary.
extensions: Vec<(String, String)>cand-extension name/value pairs sipx does not model, in the order they arrived.
Kept rather than dropped, the same discipline crate::session applies to unknown SDP
lines one level up: §5.1 says unknown extensions MUST be ignored, and ignoring an
extension is not the same as deleting it from a description that is about to be relayed.
Implementations§
Source§impl Candidate
impl Candidate
Sourcepub fn parse(value: &str) -> Option<Self>
pub fn parse(value: &str) -> Option<Self>
Read an a=candidate value.
None means ignore this line and keep the description — RFC 8839 §5.1’s rule for a
candidate carrying an FQDN or an address family the agent does not support, and by the
same argument for a transport or candidate type sipx cannot check over. It also covers a
line that is simply malformed, because the outcome the peer needs is identical.