[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Robert McQueen robert.mcqueen at collabora.co.uk
Wed Mar 28 18:11:00 UTC 2007


Matt Tucker wrote:
> Kai,
> 
>> Yes, transparent media relaying is widely used in existing 
>> SIP networks. It has its pros and cons. One very huge plus is 
>> that it solves the NAT problem for existing SIP client base, 
>> and that's why it is used a lot (but this is not an issue for 
>> XMPP). A big minus is that the proxy-relays cannot verify 
>> whether direct connectivity would work, and you end up 
>> relaying more traffic than you would with ICE-enabled clients.
> 
> I think the article I had sent said their solution was for the client to
> use ICE and *then* to use transparent media relays. In any case,
> Thiago's solution doesn't preclude ICE whatsoever. Here's what I'm
> seeing:

Even within ICE, the fallback is to obtain and provide a relay address
as the lowest priority candidate, if possible.

>  * Server-negoiated relays are incredibly easier for the client to
> implement. The back-end could be TURN or whatever relay server protocol
> we want to use.

If the client has a working TURN library, server-negotiated relays are
at best the same effort, or at worst harder for the client to use.

>  * This solution will not work for Google due to their world-wide server
> network and very particular scaling needs. On the other hand, they're
> not using TURN.

They're very close to TURN, as Scott mentioned elsewhere.

>  * Some people on this list are very insistent that we follow ICE
> exactly, including off the shelf TURN servers.

Perhaps you meant me, but what I'm trying to say is that we shouldn't
preclude the ability to use off the shelf TURN servers, not that we must
use them.

>  * TURN was invented to solve some problems that are specific to SIP. We
> already authenticate with XMPP servers and even have trusted federation,
> so shouldn't we take advantage of that? 

The problems that are "specific to SIP" is that because of NATs, peer to
peer media doesn't work very well if you just naively exchange IP
addresses. That's not specific to them at all, it affects us just the
same. If you have something which speaks SIP, and you have money to burn
on bandwidth *or* you're gatewaying to the traditional phone network and
are expecting to terminate all of the calls anyway, then you can hack
around the problem with transparent media relays. However, even the SIP
community has seen this is a bad idea and have produced ICE to try and
increase the reliability of peer to peer media, and TURN to catch the
remaining 5% of cases.

> For example, why doesn't
> Asterisk implement TURN for it's media relay functionality? A: it
> doesn't need to.

Yes, Asterisk doesn't need to do TURN because it is originally intended
as a PBX, ergo all media is relayed through it by design, because it's
either using IAX to trunk calls to another Asterisk instance, has access
to PSDN lines via line cards, and uses SIP to talk over usually a
friendly network to its clients. But, I don't think turning XMPP servers
into PBXes is a good path for us to follow.

> So, how do resolve the impasse?
> 
>  1) Everyone wants to interop with Google Talk. That might sound shitty
> from a standards definition perspective, but let's be practical. :) So,
> we need to agree on something that will work for them, or define a
> couple of Jingle variations (just like we have with simple UDP and ICE).

Unless we get the standards wrong and give Google a reason to not
implement them as directly intended, then Google Talk compatibility
should become equal to standards compliance.

If we standardise on a naive thing which isn't sufficient for Google's
pretty reasonable (and proven to work) baseline, and everyone wants
Google Talk compatibility, people will implement the Google-compatible
method, and any client that only speaks only the "simple" variant will
in practice have very limited interoperability.

Note that this has already happened in a way, the number of people who
implement GTalk-compatible stuff (often with libjingle) is far in excess
of the people who have implemented real Jingle (us? you guys currently
developing it? anyone else?). The solution which will resolve the
situation and provide the maximum interop is to make sure the standards
meet Google's requirements, not to provide two standards.

Also, I think your choice of example isn't ideal. Simple UDP support
isn't to make client's lives easier - it works less well than ICE, and
the more transports we ask people to implement then the worse it gets
for clients - it's to provide wire-compatibility with SIP clients so
that gateways don't also need to be relays.

>  2) The XMPP philosophy is simple client, complex server. This has
> served us extremely well in the past and shouldn't be abandoned for
> Jingle. To me, that means we should push as far as we can on the client
> simplicity route, even if it means deviating somewhat from off the shelf
> ICE/TURN.

Actually, I think in the case of Jingle, as I've mentioned already
elsewhere on this list (with mumurs of agreement), I don't think that
this philosophy is quite applicable. Two reasons:

a) Implementing a working RTP media stack is already pretty tricky.
Unless they have some very special requirements, then clients are not
really expected to implement it from scratch. Ergo, the more components
they can re-use, the less implementation work they have to do. We're
expecting that due to the massive momentum behind SIP that the existing
stacks which can already do things like STUN for you will also gain ICE
or TURN support. Pushing stuff onto the XMPP server just because we can,
or because we think we know better, means that the client authors will
have to do more work to bridge the gap between their RTP stack and
Jingle, *and* that server authors have to do more work.

b) There is a very large deployed base of XMPP servers at the moment,
many of which are not necessarily upgraded to the latest version of
whatever they're using, etc. The existing Google Talk protocol works
pretty well if you're connected to a vanilla Jabber server and it's just
doing normal routing, and works better if one end has access to eg
Google's relay. The more magic we put onto the server, especially if we
start relying on it for calls to actually be successful, then the longer
it will take for the deployed server base to catch up, so the longer it
will take for Jingle to actually become a workable prospect for people.

> Does everybody agree with those principles?

Well... sorry. :/

> Regards,
> Matt

Regards,
Rob



More information about the Standards mailing list