[Jingle] ICE-TCP

Dirk Meyer dmeyer at tzi.de
Mon Nov 3 13:58:26 CST 2008


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