RES: RES: [Standards-JIG] ICE XEP - xep-0176
scottlu at google.com
Wed Jan 10 04:32:15 UTC 2007
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
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 jivesoftware.com> 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.
More information about the Standards