RES: RES: RES: [Standards-JIG] ICE XEP - xep-0176

Thiago Camargo thiago at
Wed Jan 10 05:57:19 UTC 2007

I have some good reason to prefer that:

TURN is an IETF standard, which implements media relay for SIP end-points. The
approach however is not ideal. It assumes the clients have a trust relationship with a
TURN server and request session allocation based on shared credentials. This has
scalability issues, requires complex changes in the XMPP clients, as TURN protocol is
difficult to implement, has no possibility of distributing the load and complicates the
configuration of the XMPP user agent.
Another approach, which requires no changes in the XMPP devices, is to reuse the trust
relationship the XMPP Server device already has with the XMPP Server. In contrast with how TURN
works, the XMPP Server and not the User agent does the session reservation for the
media relay. This has the immediate advantage that the Jingle UA does not have to have
any TURN capability built in and secondary a database with user credentials does not
need to be stored on both the TURN server and the client. Another advantage is the
fact that the XMPP Server has always more clues about where is the best place to assign
a media relay for a Jingle session than the Jingle devices themselves. This allows per call
allocation of a media relay session in an optimum place on the Internet and solves the
load balancing and scalability of the media relay function.

For an enterprise the media relay should always be located at the border of the network, for roaming uses
the media relay location should be chosen depending on subscriber geographical address.
And there is not better way to know this than using Enterprise XMPP Server.

If the Relay Server Service is a Smart service, it will have some load balance engine, to choose the best server for the client.

Maybe, we will have a fork here, that can let you get candidates through XMPP Server or a client with TURN support.


-----Mensagem original-----
De: standards-jig-bounces at em nome de Scott Ludwig
Enviada: ter 9/1/2007 22:32
Para: XMPP Extension Discussion List
Assunto: Re: RES: RES: [Standards-JIG] ICE XEP - xep-0176
I don't like this approach (having the xmpp server talk directly with
the relay server to get address candidates). It is better if the
client gets a list of DNS addresses from the server, and resolves the
name to an ip address locally. Doing it this way allows the relay
service to be load balanced across geographic regions by having the
DNS server return the ip address closest to the client. At this point,
the client talks directly with that server to allocate an address

Another reason why it is good to do it this way is reachability. The
xmpp server may be able to talk to a relay server, but the client
cannot. This can sometimes happen with data center maintenance, or if
there is a network problem between the client and the relay service.
It is best to put this sort of failure control in the hands of the
client. The client first tries the geographically closest relay (by
DNS lookup), and if that fails, then tries the others until it finds a
working relay.

The Google Talk client uses this technique with the information
returned by the below extension, for both stun and relay servers.
JingleInfo is what we propose:

Note it currently documents how to discover STUN servers. We will
update it shortly to include relay server discovery.


On 1/9/07, Thiago Camargo <thiago at> wrote:
> Hello Peter,
> "So you communicate with the relay server via XMPP, or you communicate
> with your XMPP server and it communicates with the relay server?"
> I communicate with my XMPP server and it communicates with the Relay Server.
> This way we can use current XMPP Connection to provide Relay candidates. And another positive point is that we can be one more step ahead in "XMPP only" clients. The goal of XMPP is to provide communication.
> If we tunnelate negociations through XMPP we are extending XMPP concepts of Messaging and Communication.
> Regards,
> Thiago

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Standards mailing list