Bug 94812 - implement finish_initial_candidates method
Summary: implement finish_initial_candidates method
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-04 10:37 UTC by Fabrice Bellet
Modified: 2016-06-15 15:46 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
call-stream: implement finish_initial_candidates method (1.67 KB, patch)
2016-04-04 10:38 UTC, Fabrice Bellet
Details | Splinter Review
jingle-content: implement finish_initial_candidates method (5.40 KB, patch)
2016-04-04 10:39 UTC, Fabrice Bellet
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Fabrice Bellet 2016-04-04 10:37:47 UTC
This patch modifies the way candidates are sent in jingle transport for the ICE udp protocol: IMO the candidates should be sent in a single batch after all local candidates have been collected. This is important for the ICE connection checking algorithm to work because it assumes that all local (and remote) candidates have been exchanged before starting the stun requests. Proper ordering of pair to be checked depends on this.

Currently, candidates for ICE are sent to the peer as soon as they are collected, one per callback. And the connection check on the peer consequently begins with a partial list of remote candidates. The rest of the remote candidates usually arrive much later, with a delay caused by the transit via the xmpp server.

This patch implements the finish_initial_candidates method, and uses it in wocky-jingle-transport-iceudp, to call send_candidates() just one time, after all initial local candidates have been collected. It makes the ice algorithm to converge much more quickly.
Comment 1 Fabrice Bellet 2016-04-04 10:38:53 UTC
Created attachment 122696 [details] [review]
call-stream: implement finish_initial_candidates method
Comment 2 Fabrice Bellet 2016-04-04 10:39:32 UTC
Created attachment 122697 [details] [review]
jingle-content: implement finish_initial_candidates method
Comment 3 diane 2016-04-18 05:23:20 UTC
Thank you for the patch.

I'm not terribly familiar with how the ICE negotiation works. Your description does sound plausible, but would you happen to know 

I've been doing all my VoIP testing using SIP and one of the things I've observed is that some of the time I'll only end up with a stream in one direction. KDE Telepathy exposes a hold which allows me to renegotiate the streams and I'll usually then get sound in both directions.

It seems like from your description that could be caused by this.
Comment 4 Fabrice Bellet 2016-04-20 11:36:05 UTC
(In reply to diane from comment #3)
> Thank you for the patch.
> 
> I'm not terribly familiar with how the ICE negotiation works. Your
> description does sound plausible, but would you happen to know 
> 
> I've been doing all my VoIP testing using SIP and one of the things I've
> observed is that some of the time I'll only end up with a stream in one
> direction. KDE Telepathy exposes a hold which allows me to renegotiate the
> streams and I'll usually then get sound in both directions.
> 
> It seems like from your description that could be caused by this.

Yes, I think this is very possible, the ICE spec relies greatly on the assumption that both agents start to test the same set of connection candidates  "local-address:local-port <--> remote-address:remote-port", in the same order (their list is ordered), and at the same time. This may be more difficult if both peers don't implement the same flavor of the ICE spec.

Any delay introduced by the round-trip time with the xmpp server may void this assumption.


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.