Bug 94812

Summary:	implement finish_initial_candidates method
Product:	Telepathy	Reporter:	Fabrice Bellet <fabrice>
Component:	gabble	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	CC:	diane
Version:	git master
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	call-stream: implement finish_initial_candidates method jingle-content: implement finish_initial_candidates method

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.

Comment 5 GitLab Migration User 2019-12-03 20:01:53 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/284.

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.