The thing was that I was forcing Gajim to do a transport-replace right after the jingle session initiates. That was good for testing, but in the real world scenario, transport-replace would only come after Gajim recieves the following stanza:
<iq from='target@example.org/bar' id='hu3vax16' to='requester@example.com/foo' type='error'> <error type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
I encountered an array of minor problems related to the JingleFT branch, that have prevented me from successfully test for the IBB fallback. Hopefully they will be sorted out by the end of this week.
Correct me if i'm wrong, but IQ errors shouldn't happen in a Jingle session afaik, unless something is really wrong (connectivity fallbacks isn't part of that).
ReplyDeleteShouldn't the fallback happen on candidate-error (which is a jingle transport-info message). See XEP-260?
Thank you very much for correcting me. I can't believe I missed that.
ReplyDeleteIt is very clear from here: First the initiator sends a Jingle session-initiate, in this case with a transport of SOCKS5 Bytestreams. The protocol flow is exactly the same as described above. If both parties are unable to connect to a candidate provided by the peer, they send candidate-error messages to indicate that SOCKS5 has failed. The initiator MUST either terminate the Jingle session with a Jingle reason of or replace the transport with something else using the transport-replace action. Typically the fallback option is IBB (see, for example, Jingle File Transfer [6]). Therefore the initiator sends a transport-replace action including a transport of IBB.