Bug 93974 - call-stream: send local candidates after gathering completed
Summary: call-stream: send local candidates after gathering completed
Status: RESOLVED NOTABUG
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-farstream (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Olivier Crête
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-02 20:50 UTC by Fabrice Bellet
Modified: 2016-04-04 10:44 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
call-stream: send local candidates after gathering completed (3.04 KB, text/plain)
2016-02-02 20:50 UTC, Fabrice Bellet
Details

Description Fabrice Bellet 2016-02-02 20:50:11 UTC
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.
Comment 1 Olivier Crête 2016-02-02 21:03:15 UTC
This candidate trickling is required to implement Google Talk compatibility as well as the ICE trickle draft RFC https://tools.ietf.org/html/draft-ietf-ice-trickle-01

So the CM should implement that if required.
Comment 2 Fabrice Bellet 2016-04-04 10:43:59 UTC
Of course, you're right, thanks for this suggestion. I proposed a patch that implements the same delaying principle in telepathy-gabble/wocky in a place that should be ICE 5245 specific hopefully:

https://bugs.freedesktop.org/show_bug.cgi?id=94812


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.