[Jingle] transport fallbacks for stream transports

Dirk Meyer dmeyer at tzi.de
Mon Jul 28 03:42:52 CDT 2008


Peter Saint-Andre wrote:
> Robert McQueen wrote:
>> At the summit we discussed how to fall back between things like SOCKS 5,
>> direct TCP connections[1] and IBB in order to find the most desirable
>> working stream transport between the two parties. Note that this is not
>> the same problem as negotiation (knowing before calling which transports
>> you have in common with the endpoint). We've got a separate idea for that.

That separate idea could be ice-tcp except that ice uses TURN and not
SOCKS as one fallback. But the basic ideas of ice-tcp to detect where
we are and what kind of firewall/NAT we have is important.

>> The proposal is to remove the "content-replace" action, and instead add
>> "transport-replace" to replace the transport *only* for an already
>> accepted content, and "transport-accept" so that the other party can
>> agree to this change.
>
> As discussed at the XMPP Summit, I'm +1 on this change.

I was neither on the summit nor have I a vote but the content-replace
also bothered me we implementing jingle-streams. transport-replace
sounds much better.

>> 1: I think we want a Jingle transport description for direct TCP
>> connections, because we'll need it on link-local XMPP, and if we have
>> working fallbacks then trying a direct connection first isn't going to
>> cost much.
>
> Like "raw-tcp"?

Sounds good to me.


Dischi

-- 
ACK and you shall receive.


More information about the Jingle mailing list