642ccf25218977e964acff2f2936b242f26156a6 — Christopher Vollick 3 years ago b6a13dc
Ignore Candidates for RTCP Component

We happen to know that all of our clients support rtcp-mux, which means
both kinds of traffic will flow over the same port.
This means that we'll only use component 1.

But, the offerer doesn't technically know that yet, since we don't
advertise that until our session-accept.

So in the meantime it may have generated candidates for component 2.

Our ICE setup is practically on the edge of not working at all, given
the way Jingle trickles candidates in contrast to the spec asterisk was
written against.

So it's a miracle it works at all, since it sees each individual
candidate as the only one.
But when it sees a candidate list that appears to _only_ contain
candidates for component 2, that is rtcp and not rtp, then it doesn't
even try to run the checklists, since it thinks there's no actual media.

So that's apparently one problem too many and nothing works.
This change just ignores candidates for component 2.
There's already code that doesn't _actually_ restart anything if there's
not actually any new candidates, so if that's the only one then it'll
just be ignored.
For candidates for component 1, it should do the same thing it's already
doing, which is limping over the finish-line.
1 files changed, 10 insertions(+), 0 deletions(-)

M channels/chan_motif.c
M channels/chan_motif.c => channels/chan_motif.c +10 -0
@@ 2330,6 2330,16 @@ static int jingle_interpret_ice_udp_transport(struct jingle_session *session, ik
			return -1;

		// CV - All of our clients support RTCP-MUX
		// So there should only be 1 component (component 1)
		// But since we don't actually support trickle, we sometimes
		// get candidates for component 2, which can monopolize the
		// whole system, since we think they're the only one.
		// So for now, just ignore anything that isn't the first one.
		if (local_candidate.id != 1) {

		local_candidate.foundation = foundation;
		local_candidate.transport = protocol;