[Standards] PR #793 - XEP-0166: Relax transport element requirement

Philipp Hancke fippo at goodadvice.pages.de
Wed Jun 26 10:42:22 UTC 2019

Am 22.06.19 um 17:18 schrieb Sergey Ilinykh:
> In response to  Council Minutes 2019-06-19
> quote from
> https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method
> 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.
> To solve this we have https://github.com/xsf/xeps/pull/793 but may be it
> require more actions.
> Let's discuss.

Moving over from github. Peter, Lance and me looked at a very similar 
case back in 2015, fallback from ice-udp to raw-udp. It also does a 
transport-replace before session-accept.

has the full protocol flow. Its a bit unclear to me now why Romeo would 
send a ice-udp transport to the gateway which is unlikely to announce 
this in disco... (which I assume is the way to pick the transport even 
though 0166 is silent here)

We kept this within the current jingle specification by including an 
empty namespaced
   <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'/>
in the session-accept (example 15) which basically says "reminder: we 
agreed on this transport, hopefully you remember the details".

For IBB I would recommend a similar thing but keeping the sid attribute, 
the initiator can then verify that this refers to an already active 
session that does not need to be reinitialized.

(I just hope we're using this pattern consistently...)


(and thanks for the poke Dave!)

More information about the Standards mailing list