[Standards] UPDATED: XEP-0234 (Jingle File Transfer)
tjulien at limewire.com
Thu May 29 15:39:41 UTC 2008
Peter Saint-Andre wrote:
> On 05/21/2008 1:18 PM, Tim Julien wrote:
>> So, I'm confused about some of the transport negotiation stuff.
> It was sketched out rather quickly and probably needs more work.
>> In first scenario (section 3.1) the negotiation occurs after
>> session-accept - which is counter to every Jingle spec that has come out
>> so far: typically both <description> and <transport> are negotiated as a
>> pre-requisite to session-accept and going into ACTIVE. (I'll bet it was
>> done this way because content-replace isn't currently allowed in
>> PENDING, even though the other specs are using it there).
> The other specs have been corrected.
> In file transfer especially you might want fallback because SOCKS5
> Bytestreams does not provide reliable NAT traversal, unlike ICE. So you
> might try XEP-0065 first but then it fails, so you fall back to In-Band
> Bytestreams because you know that will always get through (well, almost
> always: you might run into rate limiting from your server).
The fallback makes alot of sense - I'm glad its being added.
But do you envision that happening pre or post session-accept (i.e.,
during PENDING or ACTIVE). I guess I'll wait for your updated flows. :)
>> In the second scenario (section 3.2) the negotiation occurs before the
>> session-accept. This follows the pattern of previous Jingle specs - but
>> isn't consistent with section 3.1.
> Right. Consistency is good, as long as it's not a foolish consistency. :)
>> I really like the concepts of "Fallback" (3.1) and "Transport Selection"
>> (3.2). Being able to negotiate *which* transport type to use as opposed
>> to just negotiating connectivity within a *one* pre-set transport type.
>> We haven't seen that yet from the other Jingle specs, but I really like
>> it. It's analogous to the listing of multiple <payload-type>'s in
>> Jingle Audio RTP, and both parties agree on one.
> As I explained above, the hope is that we won't need fallback for audio
> or video because we're using ICE-UDP there. File transfer is a bit of a
> special case because we have this large deployed base of clients that
> support XEP-0065, so we need a way to fall back to XEP-0047. If we all
> just used ICE-TCP for file transfer life would be different, but that's
> not done yet and it doesn't provide backwards-compatibility with our
> deployed base.
> That said, I will work on the flows in XEP-0234 so that this is all clearer.
More information about the Standards