[Jingle] ICE-TCP

Dirk Meyer dmeyer at tzi.de
Mon Nov 3 14:22:12 CST 2008


Justin Uberti wrote:
> 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.

How can we do that? When I have a 1GB file transfer, I can I detect that
the message is a STUN message and not part of my file? How can I make
sure I do not loose any data when switching connections? If you only use
RTP over ICE-TCP it is no problem, but I do not see how it works with
other stuff. And ice-tcp says:

   Once the connection is established, the agent MUST utilize the shim
   defined in RFC 4571 [RFC4571] for the duration this connection
   remains open.  The STUN Binding requests and responses are sent ontop
   of this shim, so that the length field defined in RFC 4571 precedes
   each STUN message.  If TLS or DTLS-SRTP is to be utilized for the
   media session, the TLS or DTLS-SRTP handshakes will take place ontop
   of this shim as well.  However, they only start once ICE processing
   has completed.  In essence, the TLS or DTLS-SRTP handshakes are
   considered a part of the media protocol.  STUN is never run within
   the TLS or DTLS-SRTP session.

The last part is important. No STUN after we are running. So IMHO we
need something more robust, we need to figure out

a. is it STUN or not
b. what is the last packet from the old (dead) link

That is what I want to do with my format:

> On 11/3/08, Dirk Meyer <dmeyer at tzi.de> wrote:
>>  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.

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

It is citical for TCP->UDP bridges but not helping for "real" streams.


Dirk

-- 
printk("; corrupted filesystem mounted read/write - your computer 
will explode within 20 seconds ... but you wanted it so!\n");
	2.4.3 linux/fs/hpfs/super.c


More information about the Jingle mailing list