[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Kai Vehmanen kai.vehmanen at nokia.com
Wed Mar 28 13:52:56 UTC 2007


Hi Matt and others,

On 27 Marc 2007 Matt Tucker wrote:
>> 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. I admit there are very few of these servers out there at the 
>
>Is this really true? The TURN server and XMPP server will need 
>to be integrated *somehow* in order to coordinate the shared 
>secret.

yes, some common authentication backend is needed, but this is the 
case in many/most deployments anyways (unless you are running everything 
in one box). A deployment-ready TURN server would most probably provide
hooks to various authentication backends.

> Not only that, but the current TURN spec seems to 
>assume a static shared secret, which would be a security 

??? TURN spec specifically talks about short-term (created for instance
per session) and long-term (reusing e.g. your registration credentials to 
allocate relay resource) credentials. Both are supported by the spec.

>solution is TURN-like. Also, I found the following article interesting:
>http://www.sipcenter.com/sip.nsf/html/AG+P2P+SIP. A snip:

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.

br,
-- 
first.surname at nokia.com (Kai Vehmanen)




More information about the Standards mailing list