[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
kai.vehmanen at nokia.com
Mon Mar 26 14:51:26 UTC 2007
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.
- 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
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
first.surname at nokia.com (Kai Vehmanen)
More information about the Standards