[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
matt at jivesoftware.com
Mon Mar 26 04:32:45 UTC 2007
Is the Google approach documented anywhere? I looked at:
but couldn't find anything about media relays. Is what you're saying logically something like the following?
C: <iq type="get">
S: <iq type="result">
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?
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.
> -----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:
> > 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