23
edits
Difference between revisions of "XEP-Remarks/XEP-0260: Jingle SOCKS5 Bytestreams Transport Method"
Jump to navigation
Jump to search
XEP-Remarks/XEP-0260: Jingle SOCKS5 Bytestreams Transport Method (view source)
Revision as of 21:38, 16 April 2019
, 21:38, 16 April 2019no edit summary
(Created page with "{{Quote|text=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 sh...") |
|||
| Line 2: | Line 2: | ||
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>. | 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>. | ||
----- | |||
{{Quote|text=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. | |||