Closed Bug 1258753 Opened 4 years ago Closed 4 years ago

ICE stack always thinks it is the offerer

Categories

(Core :: WebRTC: Networking, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: bwc, Assigned: bwc)

References

Details

Attachments

(1 file)

It seems that the priority calculations down in nICEr are always computed as if the agent is the offerer. Something must not be plumbed right.
Ok, it looks like we have two problems. One is we're basing the priority calculation on whether we're the offerer or not, instead of whether we're controlling or not. This is something that can change with role conflict resolution. The second problem is that we are always telling nICEr it is the offerer. The end result is even when the role conflict is resolved, the priorities of the candidate pairs are never consistent between the two ends, which has a tendency to result in each side sending media over a different path. This could explain all kinds of things.
Attachment #8734146 - Flags: review?(drno) → review+
Comment on attachment 8734146 [details]
MozReview Request: Bug 1258753: Base candidate pair priority on controlling/controlled. r?drno

https://reviewboard.mozilla.org/r/42109/#review38645

::: media/mtransport/third_party/nICEr/src/ice/ice_media_stream.c:890
(Diff revision 1)
> +     * re-sorting the check list. */
> +    nr_ice_cand_pair_head old_checklist=stream->check_list;
> +    TAILQ_INIT(&stream->check_list);
> +
>      assert(stream->ice_state != NR_ICE_MEDIA_STREAM_UNPAIRED);
>  

Might be worth adding a comment here that this does not affect the |trigger_check_queue| as that is a FIFO and not ordered by the priorities of the pairs.
Assignee: nobody → docfaraday
https://hg.mozilla.org/mozilla-central/rev/21a8c1db64fa
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.