[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Thiago Camargo thiago at jivesoftware.com
Mon Mar 26 12:59:22 UTC 2007


Here goes a suggestion:

1> the discovery mechanism (Use STUN/Media Relay Discovering suing XMPP)

2> the client does dns name resolution and choose the best relay server.

3> Client ask XMPP Server to allocate a Relay Channel on the selected Relay Server. Then server returns the IP address, password and port pair.

With this approach clients don't need to negotiate the allocation of a relay directly to a relay server.
Clients will only have to send media to the relay server using the correct ports.

It will make clients implementations much easier. And the type of the relay Server will be transparent.

Regards,
Thiago


-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Scott Ludwig
Sent: segunda-feira, 26 de março de 2007 03:35
To: XMPP Extension Discussion List
Subject: Re: [Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

> Scott,
>
> Is the Google approach documented anywhere? I looked at:
>
> http://code.google.com/apis/talk/jep_extensions/extensions.html
>
> but couldn't find anything about media relays.

Sean will know if it is documented. If it isn't, we certainly intend
to document it. The Google Talk client uses it as part of jingleinfo.

http://code.google.com/apis/talk/jep_extensions/jingleinfo.html

In addition to a stun section, there is a relay section (I notice not
documented yet). If you watch the xmpp stream in and out of Google
Talk.exe you can see it go by.

If you look at libjingle-0.4.0, it's all in there.

> Is what you're saying logically something like the following?
>
> C: <iq type="get">
>      <media-relay/>
>    </iq>
>
> S: <iq type="result">
>      <media-relay>
>        <address>example.com</address>
>        <password>foobar</password>
>      </media-relay>
>    </iq>

It returns a list of relay servers to try in order, listed by dns name
and port. It also returns a token, which is good for 12 hours, signed
with a shared secret so that the relay server can verify its
authenticity (used when allocating a relay session). Once the client
asks for jingleinfo the first time, the xmpp server sends a new
jingleinfo every 6 hours, to keep the token fresh.

The first server in the list is a dns name that when resolved returns
the closest relay server for that user. The dns resolution can also be
used for load balancing and other factors. The client simply goes
through that list until it finds a working relay server. Most of the
time it is the first one. By making the client robust in this way,
taking down a data center for maintenance doesn't require special
coordination.

> Also, I'm guessing that we're going to need to define more than one media proxy type if we want to support http-based proxies officially?

The Google Talk relay supports a few different candidate types: udp,
tcp, and a special port 443 tcp candidate type. The client attempts to
traverses https proxies using the CONNECT proxy method. Sometimes
networks are firewalled and not proxied and only allow http and https
traffic out. The client attempts to traverse port 443 by using a
special candidate that negotiates ssl but then reverts to sending raw.

Google Talk doesn't currently support http-only proxies. It assumes
that for most proxied environments, if there is an http proxy, there
is an https proxy, and it uses that. To support http proxies, media
would need to be tunnelled in the http protocol, and that would
require special relay support. I agree, it is worthwhile to consider.

In practice this hasn't been an issue for Google Talk when it comes to
traversal. It could be useful for web only clients.

What are your thoughts on supporting http proxies (as apart from https proxies)?

> Finally, why doesn't the XMPP server know the best media proxy for the user? The client always has a direct connection to the server, which means that the XMPP server knows the public IP address of the user and should be able to determine the best media relay using whatever algorithm it wants. In fact, this technique could be *much* smarter since the XMPP server could know how much traffic the media relays are getting (via trusted relationship) and do load balancing accordingly.

At DNS name resolution time, many factors can be taken into account, such as:

- network distance of the user
- data center availability
- backend availability (the relay service backend in a given data
center for example)
- load balancing

Nowadays a company with network services of some sort that are spread
across data centers is likely using DNS to handle some or all of these
tasks.

It's true that these things could be known by the xmpp server, however
you'd need to build the plumbing to make this the case, and it would
be different than mechanisms that may already be in place that use DNS
for these tasks. This is a lot of work.

Having the client do dns name resolution is the only requirement to
use dns for these tasks. Given that dns is popularly used for these
tasks, I suggest leveraging it, rather than banking on a custom
solution that requires the xmpp server to have all this real time
information.

All this said, we could each use the techniques for this that we want
transparently if we agree on:

1> the discovery mechanism (jingleinfo or something like it)
2> that the client does dns name resolution
3> how the client allocates relay sessions

Then you could use your xmpp server to do load balancing / network
distance / relay server availability if you wish. You'd simply return
the right list of servers, in the right order, through jingleinfo. And
those that wish to use dns for these tasks would provide their own
list, compatible with that approach. This would work as long as
clients performed the 3 steps above.

Boiling this all down, I believe #3 is the remaining issue. At the end
of step #2 the client has a relay server ip address, and step #3 is
allocating a relay session from that machine. I believe you'd like to
use xmpp. I'll point out that since at the end of step 2 there is an
ip address, there is little need to use xmpp.

>From the ICE point of view, you are free to allocate the candidates
how you wish, xmpp or otherwise. However we need to have a documented
method to allocate relay candidates so that a third party client, when
encountering a new network, can successfully allocate relay
candidates.

Can we agree on the above 3 steps? Then our individual load balancing
techniques can be used transparently to the client.

Scott

>
> Regards,
> Matt
>
> > -----Original Message-----
> > From: standards-bounces at xmpp.org
> > [mailto:standards-bounces at xmpp.org] On Behalf Of Scott Ludwig
> > Sent: Sunday, March 25, 2007 12:07 PM
> > To: XMPP Extension Discussion List
> > Subject: Re: [Standards] Proposed XMPP Extension:
> > STUNServerDiscovery forJingle
> >
> > The client should not allocate relay sessions via the xmpp
> > server. It makes it difficult to scale relay load across data
> > centers, and more difficult to choose the relay server with
> > the lowest latency for that client.
> >
> > The client should discover the dns name of the relay server
> > over XMPP, and discover an authentication token for
> > allocating a session from the relay server, using a mechanism
> > similar to the stun server discovery.
> >
> > Then the client should resolve the dns name, which will allow
> > the client to discover the closest relay server ip address
> > geographically, for minimal latency and good load distribution.
> >
> > On 3/25/07, Thiago Camargo <thiago at jivesoftware.com> wrote:
> > > Yes, OpenFire now can act as a STUN Server, but not as a
> > TURN Server.
> > >
> > > "While there are no security problems with Binding requests,
> > > publically available TURN servers can be used by non-xmpp
> > software as anonymous proxies."
> > >
> > > That's exactly what we are trying to prevent using XMPP
> > Server to negotiate Relay Sessions for clients. In other
> > words, clients don't have direct access to request a Relay
> > Session from Relay Server.
> > > User should ask a relay Session from its XMPP Server and
> > receive everything it needs directly from XMPP Server. In
> > this case XMPP Server should authenticate and allocate a
> > relay session in a Relay Server, and send all the information
> > like IP Addresses, port numbers, and password to clients.
> > >
> > > Regards,
> > > Thiago
> > >
> > > -----Original Message-----
> > > From: standards-bounces at xmpp.org
> > [mailto:standards-bounces at xmpp.org]
> > > On Behalf Of Matt Tucker
> > > Sent: domingo, 25 de março de 2007 11:44
> > > To: XMPP Extension Discussion List
> > > Subject: RE: [Standards] Proposed XMPP Extension:
> > STUNServerDiscovery
> > > forJingle
> > >
> > > I didn't propose a public TURN server. Yes, that would be a
> > crazy idea.
> > > :) STUN is a somewhat special case because it requires two
> > public IP
> > > addresses from the server. Openfire can now act as a STUN
> > server, but
> > > the two IP address requirement makes that a bit of a setup burden.
> > >
> > > Regards,
> > > Matt
> > >
> > > > -----Original Message-----
> > > > From: standards-bounces at xmpp.org
> > > > [mailto:standards-bounces at xmpp.org] On Behalf Of Evgeniy Khramtsov
> > > > Sent: Sunday, March 25, 2007 1:47 AM
> > > > To: XMPP Extension Discussion List
> > > > Subject: Re: [Standards] Proposed XMPP Extension: STUN
> > > > ServerDiscovery forJingle
> > > >
> > > > Matt Tucker wrotes:
> > > >
> > > > > * Should we run a public STUN server at xmpp.org
> > > > >
> > > >
> > > > I think this is not a good idea :) While there are no security
> > > > problems with Binding requests, publically available TURN servers
> > > > can be used by non-xmpp software as anonymous proxies.
> > > >
> > >
> >
>



More information about the Standards mailing list