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
(Add Category) |
|||
| Line 1: | Line 1: | ||
{{remarks}} | |||
'''Strange proxy-error''' | '''Strange proxy-error''' | ||
| Line 53: | Line 55: | ||
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. | 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. | ||