Modified fallback scenario to use content-replace action during pending state.
Jingle file transfer is only as reliable as the transports on which it depends. In particular, SOCKS5 Bytestreams does not always result in NAT or firewall traversal. To work around that problem, this specification requires all implementations to support In-Band Bytestreams, which tends to result in a successful (if slow) file transfer. A future version of this specification will also recommend implementation of a Jingle transport method that emulates the IETF's ICE-TCP technology, which is currently a work in progress (see &ice-tcp;).
+Jingle file transfer is only as reliable as the transports on which it depends. In particular, SOCKS5 Bytestreams ("S5B") does not always result in NAT or firewall traversal. To work around that problem, this specification requires all implementations to support In-Band Bytestreams ("IBB"), which tends to result in a successful (if slow) file transfer. A future version of this specification will also recommend implementation of a Jingle transport method that emulates the IETF's ICE-TCP technology, which is currently a work in progress (see &ice-tcp;).
Now the initiator sends the file using In-Band Bytestreams as defined in XEP-0047.
Currently, XEP-0096 does not enable the parties to fall back to a second method (e.g., In-Band Bytestreams) if the first method tried (e.g., SOCKS5 Bytestreams) does not work. This problem is addressed by Jingle. Such a fallback scenario is especially helpful when re-using the existing SOCKS5 Bytestreams ("S5B") method, since that method does not necessarily result in NAT or firewall traversal and therefore often results in a failed transfer attempt. However, because In-Band Bytestreams ("IBB") almost always succeeds (except if the parties violate rate-limiting policies at their servers), it provides a reliable transfer method of last resort. To provide seamless fallback, the initiator or responder can counter-propose IBB if S5B fails.
+Currently, XEP-0096 does not enable the parties to fall back to a second method (e.g., In-Band Bytestreams) if the first method tried (e.g., SOCKS5 Bytestreams) does not work. This problem is addressed by Jingle. Such a fallback scenario is especially helpful when re-using the existing SOCKS5 Bytestreams method, since that method does not necessarily result in NAT or firewall traversal and therefore often results in a failed attempt at setting up the initial transport. However, because In-Band Bytestreams almost always succeeds (except if the parties violate rate-limiting policies at their servers), it provides a reliable transfer method of last resort. To provide seamless fallback, the initiator or responder can counter-propose IBB if S5B setup fails.
The protocol flow is as follows:
|
| ack |
|<----------------------------|
| [ SOCKS5 failure! ] |
|x---------------------------x|
- | session-accept |
- |<----------------------------|
- | ack |
- |---------------------------->|
| content-replace (IBB) |
|<----------------------------|
| ack |
@@ -425,6 +428,10 @@ Claudius Laertes
|<----------------------------|
| [ IBB negotiation ] |
|<--------------------------->|
+ | session-accept |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
| [ file transfer ] |
|---------------------------->|
| terminate |
@@ -433,6 +440,7 @@ Claudius Laertes
|---------------------------->|
| |
]]>
+ Note: Currently, XEP-0166 prohibits use of the content-replace action during the PENDING state. That restriction may be removed in the future.
First the initiator sends a Jingle session-initiate, in this case with a transport of SOCKS5 Bytestreams.
At this point the file transfer has failed using SOCKS5 Bytestreams. However, all is not lost, because the parties can attempt to fall back to In-Band Bytestreams. Therefore the responder sends a session-accept to the initiator but immediately sends a Jingle content-replace action to propose the fallback.
-The initiator acknowledges the Jingle session-accept action.
-However, this session-accept is just a placeholder, and the initiator MUST NOT send the file using SOCKS5 Bytestreams because the initiator received a notification that the SOCKS5 negotiation failed. The responder immediately sends a content-replace action including a transport of IBB and a request for the file originally offered (note the use of the <request/> element instead of the <offer/> element, since the responder wants the initiator to send the previously-offered file).
+At this point the file transfer has failed using SOCKS5 Bytestreams. However, all is not lost, because the parties can attempt to fall back to In-Band Bytestreams. Therefore the responder sends a content-replace action including a transport of IBB and a request for the file originally offered (note the use of the <request/> element instead of the <offer/> element, since the responder wants the initiator to send the previously-offered file).
Now the responder sends a session-accept to the initiator.
+The initiator acknowledges the Jingle session-accept action.
+Now the initiator sends the file using In-Band Bytestreams as defined in XEP-0047.