[Jingle] ICE-TCP

Justin Uberti juberti at google.com
Mon Nov 3 14:12:16 CST 2008


We still want STUN during the call so that we can detect if the
connection dies, and we want to have other connections warm so that we
can switch over with no disruption.

RFC 4571 only adds a length field to properly frame messages, which is
critical for TCP->UDP bridges. I don't see why we would want to make
up our own thing.

On 11/3/08, Dirk Meyer <dmeyer at tzi.de> wrote:
> Hi,
>
>  Dirk Meyer wrote:
>  > The ice-tcp draft is designed for RT(S)P and requires RFC 4571 for
>  > framing. IMHO this is a misstake we should not make. Our ICE-TCP should
>  > open an set-up a stream and once started, you can do whatever you want.
>
>  Now that I read the drafts and RFCs more closely I wonder if we want to
>  be compatible with ice-tcp or not. The stack for ice-tcp looks like
>  this:
>
>            +----------+
>            |          |
>            |    App   |
>  +----------+----------+
>  |          |          |
>  |   STUN   |  D/TLS   |
>  +----------+----------+
>  |                     |
>  |      RFC 4571       |
>  +---------------------+
>  |                     |
>  |         TCP         |
>  +---------------------+
>  |                     |
>  |         IP          |
>  +---------------------+
>
>  The question is: do we need the RFC 4571 framing all the time? We may
>  need it for the STUN messages, but STUN is only used on setup. And while
>  we are at it, maybe use a better frame format so we can RESUME a stream
>  on IP address change. We only need a simple sequence number/ACK
>  mechanism. A frame could look like this:
>
>  1 Bit: STUN (0) or application data (1)
>  15 Bits: Length of the packet
>  16 Bits: Sequence number of this packet
>  16 Bits: Sequence number of the next packet to expect from the peer
>  length Bits: data
>
>  If the connections breaks down (e.g. IP address change) the peers set up
>  a new connection, exchange STUN messages again and fill the second
>  sequence number field correctly. The session can resume. I hope this is
>  clear to all readers, if not I will post an example.
>
>  TLS is something we may or may not enable in <transport>
>
>  This will give us:
>
>            +----------+
>            |          |
>            |    App   |
>  +----------+----------+
>  |          |   TLS    |
>  |   STUN   |(optional)|
>  +----------+----------+
>  |                     |
>  |    6 Bytes Frame    |
>  +---------------------+
>  |                     |
>  |         TCP         |
>  +---------------------+
>  |                     |
>  |         IP          |
>  +---------------------+
>
>  Pros:
>  - Disruption tolerant, survives link loss
>
>  Cons:
>  - Incompatible with ICE-TCP, a XMPP-SIP gateway will not work for this
>
>  We could also support an optional compatibility mode which uses RFC 4571
>  for framing.
>
>  Comments?
>
>
>  > Reading ICE-TCP I wonder why it is so complicated. We do we have active
>  > and passive candidates? If I send you my active candidate and you can
>  > connect to it, aren't we just done? Why the passive ones?
>
>  Anyone with some inside on this?
>
>
>  Dirk
>
>
>  --
>  Never say 'OOPS!'  Always say 'Ah, Interesting!'
>


More information about the Jingle mailing list