[Standards] Simple Jingle example(s) and spec(s) wanted
matt at jivesoftware.com
Sat Feb 3 20:44:36 UTC 2007
Focusing on file transfer as a way to get initial Jingle support in clients is a great idea. ICE-based transfers would be the current way to work around firewall issues, but it's not a very simple approach for initial implementations (we've seen this same problem on the audio side). Simple UDP and TCP proxy specifications for Jingle would go a long way towards solving that problem.
> -----Original Message-----
> From: standards-bounces at xmpp.org
> [mailto:standards-bounces at xmpp.org] On Behalf Of Remko Tronçon
> Sent: Saturday, February 03, 2007 10:07 AM
> To: XSF Standards
> Subject: [Standards] Simple Jingle example(s) and spec(s) wanted
> I think it would be good for Jingle's popularity to have clarifying
> example(s) and at least one easy-to-implement description
> format and transport specification. Due to the lack of an
> example encompassing the complete flow of a Jingle session
> and an easy-to-implement (yet maybe not very effective)
> transport, there is no way to get
> *something* implemented in a decent amount of time, which is
> very demotivating (at least for me). For example, it would be
> great if there was a description format for file transfers,
> and a SOCKS5 transport spec to transfer the files over.
> Correct me if i'm wrong, but this sounds like the easiest
> Jingle session to implement, and as such allow people to
> implement the framework of Jingle support in their
> application fast, without having to bother with the low-level
> details of transports (and even worse, multimedia implementations).
> As for the clarifying example, I would like to know how the
> following use case goes (in terms of XML stanzas sent and
> received, and actions performed by both clients):
> - Client A wants to send a file to Client B, and supports
> SOCKS5 and Raw UDP. Client A is NATed (with a port forward),
> and as such has both a local IP and a global IP through which
> it is reachable.
> - Client B only supports SOCKS5, and is outside of Client A's
> local network.
> This flow would already clarify a lot (at least it would for
> me). An extension of this example would be where Client A
> supports 3 transport methods, and Client B doesn't support
> one of the 3, and is unable to reach Client A using one of
> the 2 remaining.
More information about the Standards