~singpolyma/asterisk

aed474800ba85c95dae377f51230ea363665e2ae — Christopher Vollick 6 months ago 92b33c9
Use Nominated Pair

We were seeing Chromium choose to nominate a pair that was not highest
priority, and then get stuck trying to convince us to use it.

While it's true it's a bit weird to do that, that's its right as
"controlling" agent, and our job as "controlled" agent is to do what it
asks of us.

It's possible it was just looking for the handshake to complete to
renegotiate with the higher priority one, or maybe it is planning on
just sticking with it. Either way, talking to the same interfaces is
better than making up our own answer.

The difference in this case is that if a component has multiple valid
options, then the highest priority one will be the one that's chosen as
"most valid"

But it's possible that, again, for some reason the controlling entity
chose to pick a different pair as the one to nominate.
In that case, the nominated and valid checks will differ, and we are
currently using the wrong one.
1 files changed, 3 insertions(+), 3 deletions(-)

M res/res_rtp_asterisk.c
M res/res_rtp_asterisk.c => res/res_rtp_asterisk.c +3 -3
@@ 610,15 610,15 @@ static void update_address_with_ice_candidate(pj_ice_sess *ice, enum ast_rtp_ice
{
	char address[PJ_INET6_ADDRSTRLEN];

	if (component < 1 || !ice->comp[component - 1].valid_check) {
	if (component < 1 || !ice->comp[component - 1].nominated_check) {
		return;
	}

	ast_sockaddr_parse(cand_address,
		pj_sockaddr_print(&ice->comp[component - 1].valid_check->rcand->addr, address,
		pj_sockaddr_print(&ice->comp[component - 1].nominated_check->rcand->addr, address,
			sizeof(address), 0), 0);
	ast_sockaddr_set_port(cand_address,
		pj_sockaddr_get_port(&ice->comp[component - 1].valid_check->rcand->addr));
		pj_sockaddr_get_port(&ice->comp[component - 1].nominated_check->rcand->addr));
}

/*! \brief Destructor for locally created ICE candidates */