The parties would then attempt to negotiate use of the SOCKS5 Bytestreams transport method, as described in XEP-0065.
Once the file transfer succeeds, one of the parties terminates the session.
-Note: The syntax and semantics of the &DESCRIPTION; and &TRANSPORT; elements are out of scope for this specification, since they are defined in related specifications. The syntax and semantics of the &JINGLE; and &CONTENT; elements are specified in this document under Formal Definition.
Note: In order to expedite session establishment, the initiator MAY send transport candidates (e.g., for negotiation of the ICE transport) immediately after sending the session-initiate action and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be PENDING even before receiving acknowledgement). Given in-order delivery, the responder should receive such transport-info actions after receiving the session-initiate action (if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist).
-Unless one of the following errors occurs, the responder SHOULD acknowledge receipt of the initiation request.
-If the responder does not support Jingle, it MUST return a &unavailable; error.
-If the responder wishes to redirect the request to another address, it SHOULD return a &redirect; error.
-If the responder does not have sufficient resources to participate in a session, it SHOULD return a &constraint; error.
-An informational message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info" or "transport-info"; the &JINGLE; element MUST further contain a payload child element (specific to the session or to a transport method) that specifies the information being communicated. If the party that receives an informational message does not understand the payload, it MUST return a &feature; error with a Jingle-specific error condition of <unsupported-info/>.
-