[Standards] XEP-0260 (jingle socks5 transport) candidate-complete event
fippo at goodadvice.pages.de
Wed Jun 26 08:45:31 UTC 2019
I was summoned... :-)
Am 29.04.19 um 12:02 schrieb Sergey Ilinykh:
> There is a problem with jingle-s5b in the way how it handles additional
> candidates sent with transport-info message.
> Let's imagine a situation. We have an accepted session. Both sides sent
> their host candidates in session-initiate/accept and both sides failed
> because of NAT. But one of sides (or maybe both) also had upnp-igd port
> binding in progress which would defenitely worked.
> Since all current remote candidates failed, both sides send candidate-error
> and so finish the transport negotiation with failure not even trying the
> candidate coming from upnp which arrived slightly later.
> A similar situation is possible with candidate-used leading to selection of
> s5b proxy for example instead of nat-assited candidate.
> There is a few ways to solve this.
> 0. The easiest solution is to not send session-initiate/accept until
> highest priority candidates are discovered (at least host/NAT-assisted).
> This solution though may slowdown the negotiation.
This is similar to some of the problems that exist in ICE. The "wait
until gathering is complete" turns out to be very slow so Emil came up
with (or Jingle/ICE did this by default, but in a naive way) trickle
ice. https://webrtchacks.com/trickle-ice/ has the details.
It did not have a way to signal "these are all candidates" initially
which can lead to premature failure if one side fails all the checks for
existing candidates and the candidate that works arrives only later.
14) go much more in depth about the rationale.
https://xmpp.org/extensions/xep-0371.html#protocol-end includes a way to
indicate this which you might want to borrow (even though the s5b and
ice transports already use a very different syntax for the same
concepts). It looks like example 17 in that spec is contradicting the
text though :-(
> 1. Another way. Local party should not sent candidate-used/error if it has
> local unacknowledged candidates in including those which discovery is still
> in progress. Besides if local party received candidate-error and then sent
> a new candidate to remote (respecting candidates priority) then the local
> party should forget it received candidate-error from remote and expect new
> candidate-error/used to be sent by remote after connection attempts to the
> new candidate. Unfortunately it's hard to propose the same against
> candidate-used since the remote can stay on previous candidate-used and
> send nothing if the new high-priority candidate failed.
> While everything above doesn't break compatibility with the spec, for
> candidate-used we can also forget the remote already sent candidate-used
> and expect the remote will send it again (even if the same) after it
> received the new candidate from our local party.
> 2. Since these double checks of the part 1 complicate a lot the
> implementation there has to be an event explicitly telling the remote no
> more local candidates will be sent. Let's call it candidate-complete event.
> If we add two more restriction from p.1 when the remote must send
> candidate-error/used after receiving additional candidates with
> transport-info, we come to the state where everything is pretty much clear
> and simple.
> In this case both parties can send candidate-used/error according to the
> current spec. We know exactly when our additional candidates were handled
> and when to consider the whole transport negotiation failed. Particularly
> the negotiation has be considered completed only when both parties sent
> candidate-used/error and candidate-complete.
> Probably there is still a room for race conditions but probably it's a
> topic for another thread.
> // Psi IM dev
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards