[Standards] Re: Jingle bootstrapping

Kai.Vehmanen at nokia.com Kai.Vehmanen at nokia.com
Mon Mar 5 12:29:11 UTC 2007


now obviously I'm a newbie on this forum, so I might be missing 
some key points here -- but, but, I'm familiar with the ICE work,
so hopefully these comments are helpful.

On 05 March 2007,  Thiago Camargo wrote:

>* Using TURN with SDP negotiation. In other words, we want to 
>get the relay candidates from our XMPP server. (Because we 
>want to negotiate with the client using XMPP.)

TURN has no direct link to SDP nor SIP (well, the authentication
is designed in a such a way you can reuse HTTP/SIP style authentication
infra on the server side, but that's about it). So why not do it 
directly with TURN, and just reuse the authentication credentials from 
signaling (the current jingle approach)? Any other way, you easily open 
up yourself to possible security issues (the relay doesn't know where 
your IP packet are going to come until it gets the first packet).

>* Trying to get public address without STUN use when it's 
>possible. (Because we prefer XMPP instead of other protocols.)

Again, in order to reliably query your public address, you have
to do this from the very source IP+port (and protocol -> UDP for RTP)
you are going to send media from. This is really the only somewhat
reliable way to do the query.

Anyways, this shouldn't be a big issue. ICE supports use of
candidates discovered via other means than STUN/TURN.

>* Use UDP ECHO instead of STUN connectivity check. (Because 
>UDP ECHO is pretty much easy to implement and very reliable.)

There are reasons why the connectivity checks are authenticated
in ICE - see B.4. of http://tools.ietf.org/html/draft-ietf-mmusic-ice-13
and the security threats documented in section 16.1. And note that 
the plain keepalives are simpler also in ICE (STUN Binding Indications).

first.surname at nokia.com (Kai Vehmanen)

More information about the Standards mailing list