[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
thiago at jivesoftware.com
Wed Mar 28 15:40:33 UTC 2007
>As well as the "get me my IP" function, if you're using a raw UDP connection >to your peer, STUN requests have the side-effect of creating a mapping in >your NAT for that port, which allows direct media to flow in the cases where >the NAT doesn't consider the source address/port (just the incoming >address/port) for routing incoming UDP. This makes an XMPP-based address >discovery significantly less useful.
STUN is not like socks 5, NATs don't consider STUN packets, the one thing that STUN does, is the same thing that every UDP packet does "NAT Mapping".
NAT Port Binding for outgoing packets to a same address and incoming packets from the same address. It's valid for all UDP packets including RTP Packets.
That's why media relay server works without any extra protocol.
The "get my connection IP" MUST be consider as a last resort for STUN blocked networks. And YES it works for many cases.
The idea is to provide an extra way to get it.
And it works for connection managers too, since server is direct connected to internet. And to check if the server is directly connected to internet, YES we use STUN at server.
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Matt Tucker
Sent: quarta-feira, 28 de março de 2007 12:19
To: XMPP Extension Discussion List
Subject: RE: [Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
> This doesn't mean the secret needs to be shared on an ongoing
> basis, the XMPP server can have something like a private key
> and sign a timestamp with it, creating a ticket which the
> relay server can verify offline using a public key, without
> further reference to the XMPP server. My understanding is
> that the Google relay stuff works along these lines.
> >> To me, this is as simple as the mechanism you described,
> but with the
> >> added bonus that the service provider can use an
> off-the-shelf TURN
> >> server.
> > Off-the-shelf is a plus. We don't want to be off in our little XMPP
> > ghetto here.
> +1 :D
I don't quite get it. You just described a relay server mechanism that's
custom and then added a +1 comment on making things "off the shelf". :)
What I'm seeing:
* Google doesn't use TURN.
* TURN servers don't exist in general, certainly nothing "off the
* I can't find anything in the TURN spec about this advanced shared key
logic (expiring shared keys), so I'm not sure how an off the shelf
server could ever work anyway.
* TURN doesn't cover the HTTPS relay trick that Google uses, which I
think may be worth standardizing.
None of this is a problem for me at all -- we just need to agree on a
simple relay mechanism that works well and document it.
I keep coming back to a point made a few weeks back -- if everything
about Jingle is exactly the same as SIP, there is exactly zero benefit
to using Jingle instead of SIP.
More information about the Standards