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.
/psa
