[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Kai Vehmanen kai.vehmanen at nokia.com
Mon Mar 26 14:51:26 UTC 2007


Hi,

btw, as a general comment, the ICE/TURN/STUN specs were reviewed
last week in IETF68, and unlike in all previous meetings, no major 
issues were raised in the documents anymore. It is expected that the specs 
will go to last call (final review before publication as RFCs) soon-ish.

On 26 March 2007, Thiago Camargo wrote: 
>3> Client ask XMPP Server to allocate a Relay Channel on the 
>selected Relay Server. Then server returns the IP address, 
>password and port pair.
>
>With this approach clients don't need to negotiate the 
>allocation of a relay directly to a relay server.

Alternative proposal:

- client acquires short-term credentials with XMPP means (plus maybe
  also the IP address and port of the relay)
- client uses standard STUN/TURN procedure to allocate
  a relay port and uses the acquired short-term credentials (username
  plus password used as a key for the message-integrity field) for 
  authentication

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 moment, but now that the specs are about 
to be finished, that situation is certain to change.

Plus you get some bonuses:
  - ability to use TCP, or TLS-over-TCP framing on the client-relay hop
  - support for end-to-end TCP relaying
  - various mechanism designed to protect the relay against
    DoS attack attempts
  - IPv6 ready

>It will make clients implementations much easier. And the type 
>of the relay Server will be transparent.

It won't be transparent - you have to specify how to perform
the initial media path authentication, how do you set the destination 
of your media packets (where the relay will send packets to), how to 
perform TCP relaying, etc -- i.e. you anyways have to specify some 
relaying protocol.

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




More information about the Standards mailing list