There is a quote from the xep below: This message MUST contain a <transport/> element qualified by the 'urn:xmpp:jingle:transports:s5b:1' namespace, which SHOULD in turn contain one <candidate/> element for each SOCKS5 Bytestreams candidate generated by or known to the responder, but MAY instead be empty if the responder does not wish to offer any candidates or wishes to send each candidate as the payload of a transport-info message.
пн, 29 апр. 2019 г., 18:06 Daniel Gultsch <dan...@gultsch.de>: > Hi, > > how about sending the upnp as a fallback using transport-replace, with > a new transport (new id) of type s5b:1? > > I’m not really sure that the method you describe in (1) is legal > according to the XEP. transport-info isn’t explicitly specified in 260 > and even if it is legal (166 doesn’t forbid it) I have a feeling it > will be very unexpected to some of the existing implementations. > > By the way would love to do some interop assuming you are currently > implementing Jingle File Transfer in Psi. > > cheers > Daniel > > Am Mo., 29. Apr. 2019 um 10:05 Uhr schrieb Sergey Ilinykh < > rion...@gmail.com>: > > > > Hi > > > > 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. > > > > 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. > > > > Thanks, > > Sergey > > > > // Psi IM dev > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > _______________________________________________ > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
