[Jingle] Are We There Yet?

Robert McQueen robert.mcqueen at collabora.co.uk
Wed Sep 3 19:17:30 CDT 2008

Peter Saint-Andre wrote:
> As far as I can see, we've incorporated all the consensus points from
> the recent XMPP Summit into the core Jingle specs, so I wonder if they
> are done now. Can we perhaps take the temperature of the list about
> whether XEP-0166, XEP-0167, and XEP-0176 are ready to be advanced to
> Draft? (AFAIK the only outstanding issue is to clean up the examples and
> schemas a bit, but I can do that this week.)

I just skimmed 0166 and 0167 at least, and I think they look reasonably
good now. The only stuff I have on my list that applies to the core XEP is:
a) Allow doing content-add while a session is pending, provided we
clarify that session-accept only accepts contents which were included in
the session-initiate. This would let us do early media with an extra
content, so it should just require a little tweak to XEP-0167 to say
that's how it's done.
b) Add an optional <thread> element to go in under <jingle> so that you
can associate calls/file transfers/etc with an ongoing conversation, so
that UIs which can present multiple interactions in the same window can
relate these things when they are sent over the wire
c) Add some more semantics to transport-replace, including a tie break
in the case of two crossed-over replace actions (session initiator wins,
responder should forget they even tried), and maybe explaining you can
reply with a "content-remove" with a <reason> if the new transport
doesn't work for you.

I'm a bit behind on ICE, and particular how it turns up in SIP, but I
also had a vague interop concern with XEP-0176, which is whether it has
enough information in it that you can turn the ICE candidates into a
SIP+ICE offer, and then deal gracefully with a SIP endpoint that doesn't
understand the ICE parts? I seem to recall that SIP had ICE as extra
lines in the offer, but that it also chose one of the most likely
candidates to put in the "normal" place in case the other endpoint
didn't do ICE. With XEP-0176, is there some way to reply to the ICE
candidates to say that actually, you want to use just raw UDP on the
wire, or does this actually rely on us doing a transport renegotiation
to use the raw UDP transport XEP instead?

> Now, I know we need to work on some extensions. These are:
> 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.

The reliability layer can be defined in a XEP which provided both a
Jingle description to say "I'm a reliability layer" and a Jingle
transport which can say "put me over the reliability layer content named
'foo', port 80". This means that a file transfer with a group of files
can then just do a single ICE-UDP negotiation as the datagram transport
for the reliability layer, and then include one content stanza for each
file, with a description saying that HTTP is in use, and the path of the
file is here, maybe with a thumbnail too. Something like:

<jingle ...>
  <content name="reliability">
    <description xmlns="...pseudo-tcp">
    <transport xmlns="...ice-udp">
      <candidate ...>
  <content name="file0">
    <description xmlns="...http-file">
      <desc>My cat!</desc>
    <transport xmlns="...pseudo-tcp">
  <content name="file1">
    <description xmlns="...http-file">
      <desc>My dog!</desc>
    <transport xmlns="...pseudo-tcp">

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.

> 2. Early media.
> 3. Session transfer.
> 4. Presence sharing (not Jingle-specific).

Looks good. Additionally I'd like to see a XEP with a content
description for miscellaneous existing stream protocols (so, VNC and
stuff). I know I said I'd write it but, yeah... We didn't find an
interested client for that, so it keeps slipping off the todo list atm.
Maybe the same for datagrams too.

> However, I don't think we need to have those done before we can advance
> the core specs to Draft.

Seems fair.

> What do you all say?

Let's do it. Hopefully we'll have an updated implementation to match the
current XEPs really really soon now (the guy just got back from his
honeymoon :D), and any further feedback shouldn't be too major to just
push into the XEP after it's gone Draft.

> /psa


More information about the Jingle mailing list