[Jingle] Are We There Yet?

Dirk Meyer dmeyer at tzi.de
Tue Sep 23 13:11:02 CDT 2008

Peter Saint-Andre wrote:
> Robert McQueen wrote:
>>> 1. File transfer -- needs to be updated per the core specs.
>> I've got a lot to say on how we can put file transfer together.
>> Unfortunately despite early skepticism, I'm now pretty sold on Google's
>> concept of using HTTP over a stream transport, and using a reliability
>> layer to multiplex streams over a datagram transport.

I'm not sure I understand this? You want to use HTTP over something
over UDP?

>> Besides being able to retreive thumbnails separately from the files
>> themselves, and giving us a reasonable way to multiplex many files over
>> one session, Justin Uberti from Google pointed out a big advantage with
>> using HTTP over the reliability layer, which is that if you've got a
>> relay server (like theirs) which can bridge TCP and pseudo-TCP over ICE,
>> then a web client can just go for the TCP candidate straight away and
>> HTTP it directly from http://relayserver:1234/cat.jpg.

I'm not sure I can follow all this? Is HTTP the transport or the
highest level protocol? Do you have some more details?

> You know, that does seem reasonable. But we'd still want/need the old
> methods (even including IBB) as fallbacks, no? Or do we just scuttle the
> old stuff?

HTTP over IBB maybe?

Just jumping in this discussion I want to add a feature request:
seeking in file transfer. Maybe I want to watch a video from my home
network and use XMPP to negotiate what file to play and how to open a
transport layer using Jingle. IBB is no option, but with a TURN server
or a direct connection transfering video is possible. Now I may want
to seek in the file like Flash does. So maybe we can add optional
chunks and byte positions in the stream and use the XMPP layer for

1. Jingle negotiation
2. A requests movie.mpg
3. B sends 0 and 1MB of the movie
4. B sends 1 and 1MB of the movie
5. B sends 50 and 1MB of the movie
6. A says seek to 75
7. B sends 75 and 1MB of the movie

The bute position is required because it takes some time between
sending the seek and receiving the correct data. It doesn't matter if
the video stream is transmitted over TCP or with HTTP as extra
layer. Flash uses something similar:

I know there is a range header in HTTP but I would prefer to not open
a new connection for every seek. And yes, I know that there is RTSP
and RTP for stuff like that, but IMHO using TCP for streaming is the
better choice in this case. Realtime is not important, getting all
packages is.

Maybe this belongs into the file transfer XEP, maybe it is an extra


A man generally has two reasons for doing a thing. One that sounds
good, and a real one.

More information about the Jingle mailing list