416
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 20:44, 17 April 2020
, 20:44, 17 April 2020no edit summary
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{remarks}} | |||
'''Strange proxy-error''' | '''Strange proxy-error''' | ||
| Line 27: | Line 29: | ||
In other words the party which sent proxy eventually activates it, not obligtory the Jingle's initiator. Section "'''2.4 Completing the Negotiation'''" is more clear about in terms about activation, so probably one has to read it first. | In other words the party which sent proxy eventually activates it, not obligtory the Jingle's initiator. Section "'''2.4 Completing the Negotiation'''" is more clear about in terms about activation, so probably one has to read it first. | ||
Follow next rules | Follow next rules regarding dstaddr computation: | ||
# dstaddr for a local proxy candidate is computed like sha1(SID + Local JID + Remote JID) | # dstaddr for a local proxy candidate is computed like sha1(SID + Local JID + Remote JID) | ||
| Line 45: | Line 47: | ||
# Never use the same local port for 2+ candidates | # Never use the same local port for 2+ candidates | ||
# If you still want to configure your router manually then do it, but use different local ports for all other candidates. | # If you still want to configure your router manually then do it, but use different local ports for all other candidates. | ||
----- | |||
'''Fallback inconsistency''' | |||
XEP-0166 allows to send multiple contents with the same creator and name. Lets suppose we do this to provide the same file (xep-0234) with different <security> elements. Now one of sides sends such a request with duplicated creator/name and the other side wants to change the transport before content-accept. What's going to be replaced in this case if we provide just name and creator in the request? So while it's not said explicitly you should do transport-replace either after session/content-accept or including all the other content elements (description/security/etc) | |||
Another problem with early (before accept) transport replace is the fact we have to send the same offer twice. For example we have S5B and IBB. The lousy s5b implementation can only gather s5b proxy candidates so it may fail before we sent initial offer (session/content accept). So after proxy discovery failure we may want to send transport-replace request to IBB which will contain everything needed for IBB negotiation (at least block size). Then we have to repeat transport offer with session/content-accept which will force the remote party to reinitialize IBB transport what looks like a bad practice, which may be even worse with other transports. To make things right it has to be allowed to send session/content-accept without transport element if it was accepted earlier. | |||