XEP-Remarks/XEP-0260: Jingle SOCKS5 Bytestreams Transport Method

From XMPP WIKI
Revision as of 21:38, 16 April 2019 by Rion (talk | contribs)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
If the nominated candidate is of the proxy type and either party cannot connect to the proxy (for example because of a restrictive firewall), the failing party shall send a transport-info message containing an <proxy-error/> element. The parties shall then consider the bytestream unsuccessful and SHOULD attempt to fall back to another transport as described in Fallback Methods.

This is a little bit weird. If remote send me proxy candidate and I can't connect to any remote candidate including this proxy, I would rather send <candidate-error>.


If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically (but not necessarily) IBB; see the Fallback Methods section of this document for details.

A client should not send candidate-error if it hasn't sent yet all its local candidates. Otherwise if we already have candidate-error from remote then the transport will be considered failed. For example it's possible if upnp binding lasts too long while jingle session was auto-accepted and all candidates tried.

Basically this dependency of transport state on candidate-error is hardly compatible with trickle candidates. Instead we need another XEP with more clear and flexible s5b negotiation procedure. Or at least modify this one so each side can send an alert that its local candidates were exhausted. Then we can consider transport failed ony when remote reported us it doesn't have more candidates and candidate-error.