pub fn check_priority(local_preference: u16, component: ComponentId) -> PriorityExpand description
The PRIORITY a connectivity check carries (§7.1.1).
The same formula, “but with the candidate type preference of peer-reflexive candidates” — 110, whatever the candidate sending the check actually is.
It has to be. That is the priority the peer will assign to the peer-reflexive candidate it may learn from this very check (§7.3.1.3 takes it straight out of the attribute), and the two ends have to agree on it. Send the candidate’s own priority here and the far end prioritises the candidate it learned from us differently from the way we prioritise it, and the two checklists diverge — which shows up as ICE picking different pairs at the two ends, not as anything that looks like a bug in this function.