| Summary: |
call-stream: send local candidates after gathering completed |
| Product: |
Telepathy
|
Reporter: |
Fabrice Bellet <fabrice> |
| Component: |
tp-farstream | Assignee: |
Olivier Crête <olivier.crete> |
| Status: |
RESOLVED
NOTABUG
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
normal
|
|
|
| Priority: |
medium
|
|
|
| Version: |
git master | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
| Attachments: |
call-stream: send local candidates after gathering completed
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 121475 [details] call-stream: send local candidates after gathering completed This patch changes the way local candidates are transmitted to the peer via the xmpp server. Currently candidates are transmitted one after the other, causing two problems : * asymmetric behavior in the connection checking part of the ICE algorithm. The RFC 5245 (2.2) states that "each agent has a complete list of both its candidates and its peer's candidate". When remotes candidates arrive one after the other, the conncheck algorithm begins as soon as the first candidate is received, probably not the one with the highest priority, and the pairing algorithm of ICE will produce partial and misordered conncheck list. Remote and local peer will have a different list of pairs to test, and this also defeats UDP hole punching technique that takes benefit from the fact that both peer try the same pair, in the same order, *almost* at the same time. * roundtrip time caused by the the xmpp server increases the problem even more, as some remote candidates may arrive after the ICE algorithm has already completed. with this patch, all local candidates are sent in a single message after gathering completes.