[Standards] Re: Jingle bootstrapping

Thiago Camargo thiago at jivesoftware.com
Tue Mar 6 16:09:23 UTC 2007

Kai Thanks again for your amazing replies.
They are helping us a lot. :)

Here goes more answers, and feel free to criticize them.

I worked for 3 years in corporative environments. Just like Jean-Louis, but I think that he must be much larger experience than me.
So what I usually see is:

* Many Ports are blocked.
* ICMP not allowed, even internally.
* STUN not allowed. (Because they think, it can traces the NAT model of their company network. And they got their reasons and "Finish". They aren't that opened to discuss too many changes in network security and model.)
* Exists several that don't even open high UDP ports for voip. (These ones are the most complicated ones. They usually just allow HTTP, and HTTP through a http proxy.)

And I used to work only with UDP/SIP, and fight good battles against port and protocols blocking.

Now working with Jingle, I saw some alternative solutions of how workarounds can "some times" free us, from using these protocols.

If you take a closer look in my draft diagram, you will see that we aren't stopping use STUN. I'm just considering it as an alternative, if I really don't have condition to get my public address from my XMPP Server.

About TURN we are trying to make it different, to make XMPP Only client easily negotiate their Relay Candidates. If you look again at the diagram you'll see a Media Relay Server usage by the XMPP Server. In other words, clients don't negotiates their relay candidates directly from TURN Server, they will request their XMPP Server, And their XMPP Servers will decide which is the best Media Relay Server to use, get the candidates and send it to the XMPP Clients.

I'll send UDP ECHO flow diagram as soon as I can, I think if you see the details of the Solution you may have more conditions to gave us your opinion. Which will be an extremely important contribution. 

"And really, STUN has been around for years (RFC3489), there are many 
open-source libraries implementing it... so why not use it?"
Our intentions are to change who should and who needs to access STUN servers and their features. And we are doing this to find the best adaptation for our Jingle ICE solution.

Best Regards,

-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Kai Vehmanen
Sent: terça-feira, 6 de março de 2007 11:05
To: 'XMPP Extension Discussion List'
Subject: RE: [Standards] Re: Jingle bootstrapping


On 05 March 2007, Thiago Camargo wrote:
>*** How this could a security issue? "the relay doesn't know 
>where your IP packet are going to come until it gets the first 
>packet". ***
>*** Actually we can request a forced relay to the media Relay 
>server ***

it means you have to authenticate that the flow of media/etc IP packets 
coming to the allocated relay port is really associated with the signaling
instance that allocated the port. This is really hard to do any other
way than with something similar to TURN. Your solution can of course 
do this already, but I'm arguing that it probably is very close to what
TURN does anyways.

>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.
>*** That's exactly the way we are doing. ***

Yes, so you are in fact already using STUN (or some similar UDP protocol) 
to fetch the public address (assuming you are not sending XMPP over UDP 
from the RTP/media socket)?

>>There are reasons why the connectivity checks are 
>>authenticated in ICE - see B.4. of 
>*** That's why UDP ECHO that we use has a password and a 
>username in it.

So it is no simpler than STUN, and UDP-ECHO is really not XMPP 
either, so you are basicly reinventing STUN in a bit different way, right?
And really, STUN has been around for years (RFC3489), there are many 
open-source libraries implementing it... so why not use it?

first.surname at nokia.com (Kai Vehmanen)

More information about the Standards mailing list