[Jingle] Are We There Yet?

[Peter Saint-Andre]

Thanks for the feedback. Updates below.

Robert McQueen wrote:
> 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 working these into XEP-0166 now.

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

I need to investigate this further. Will post again when I have finished
with 166 and have moved on to 176. :)

>> 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 ...>
>     </transport>
>   </content>
>   <content name="file0">
>     <description xmlns="...http-file">
>       <desc>My cat!</desc>
>       <size>12345</size>
>       <path>/cat.jpg</path>
>       <thumbnail>/small-cat.jpg</thumbnail>
>     </description>
>     <transport xmlns="...pseudo-tcp">
>       <content>reliability</content>
>       <port>80</port>
>     </transport>
>   </content>
>   <content name="file1">
>     <description xmlns="...http-file">
>       <desc>My dog!</desc>
>       <size>67890</size>
>       <path>/dog.jpg</path>
>       <thumbnail>/small-dog.jpg</thumbnail>
>     </description>
>     <transport xmlns="...pseudo-tcp">
>       <content>reliability</content>
>       <port>80</port>
>     </transport>
>   </content>
> </jingle>
> 
> 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.

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?

>> 2. Early media.

I think early media is just a bit of text added to XEP-0167.

>> 3. Session transfer.

I think this is a new XEP.

>> 4. Presence sharing (not Jingle-specific).

This one is lower on my priority list, but I'll get to it.

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

Go for it. :)

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

Super!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/