[jitsi-dev] List of suitable XMPP-Servers


#1

There was the idea of creating a list of XMPP servers which would be
suitable for new users, the Jitsi UI should then display a account
creation window which lets the user choose a username and a password
at a server from that list (one server should already be preselected,
the one with the lowest ping would be preferable).
I would be willing to write mails to the owners of public XMPP-Servers
asking them if they comply with our criteria:

1. Federation
2. Allow for the ZRTP handshake to complete
3. Provide free of charge accounts with support for XEP-0077.
4. Support TLS connections.
5. Have IPv6 support
6. Allow use of ICE
7. Provide a reliable relaying mechanism such as JingleNodes, TurnServer
or hosted NAT traversal.
8. File transfer
9. Allow use of HD audio codecs such as Opus or SILK.

I could also create test-accounts on all the servers which answered
positively to check if it really works.

would that appreciated?
and: are the criteria complete? or is anything missing?
- --
Yannik V�lker


#2

There was the idea of creating a list of XMPP servers which would
be suitable for new users, the Jitsi UI should then display a
account creation window which lets the user choose a username and a
password at a server from that list (one server should already be
preselected, the one with the lowest ping would be preferable). I
would be willing to write mails to the owners of public
XMPP-Servers asking them if they comply with our criteria:

1. Federation

That's a very basic thing that all public XMPP servers support. Unless
of course you're one of the big silos (Google, Facebook, etc.), since
they offer client-to-server XMPP only.

2. Allow for the ZRTP handshake to complete

XMPP servers are signalling routers. If they are blocking certain
kinds of signalling, that's a big problem.

3. Provide free of charge accounts with support for XEP-0077.

XEP-0077 isn't necessarily a great idea, unless CAPTCHAs are required,
see http://xmpp.org/extensions/xep-0158.html for details. Does Jitsi
support CAPTCHAs?

4. Support TLS connections.

Naturally.

5. Have IPv6 support

Given IPv6 peering problems among some providers, just offering IPv6
support doesn't necessarily ensure interoperability. I know we have
this problem at jabber.org.

6. Allow use of ICE

That's not an XMPP server issue at all (see above on signalling).

7. Provide a reliable relaying mechanism such as JingleNodes,
TurnServer or hosted NAT traversal.

Media relays aren't cheap to run (lots of bandwidth).

8. File transfer

File transfer is mostly a client issue, not a server issue. But see
above on media relays.

9. Allow use of HD audio codecs such as Opus or SILK.

That's not an XMPP server issue at all (see above on signalling).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

···

On 5/28/13 7:15 AM, Yannik V�lker wrote:


#3

Could one of the developers, preferably Emil approve the lists so I
could start talking to the server owners?

XMPP:
1. Federation
2. Do not manipulate a users messages
3. Provide free of charge accounts, support for XEP-0077 and XEP-0158
would be desirable
4. having dual-stacked IPv4 and IPv6
5. Provide at least a STUN server and JingleNodes (providing TURN
encouraged)
6. provide a file transfer proxy

SIP:
1. Federation
2. Allow ZRTP handshake to complete (do not use asteriks)
3. TLS
4. IPv6
5. Allow the use of ICE
6. Allow the use of HD audio codecs (do not use asteriks)

- --
Yannik V�lker


#4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There was the idea of creating a list of XMPP servers which would
be suitable for new users, the Jitsi UI should then display a
account creation window which lets the user choose a username and a
password at a server from that list (one server should already be
preselected, the one with the lowest ping would be preferable). I
would be willing to write mails to the owners of public
XMPP-Servers asking them if they comply with our criteria:

1. Federation

That's a very basic thing that all public XMPP servers support. Unless
of course you're one of the big silos (Google, Facebook, etc.), since
they offer client-to-server XMPP only.

Pretty sure google is federated.

2. Allow for the ZRTP handshake to complete

XMPP servers are signalling routers. If they are blocking certain
kinds of signalling, that's a big problem.

3. Provide free of charge accounts with support for XEP-0077.

XEP-0077 isn't necessarily a great idea, unless CAPTCHAs are required,
see http://xmpp.org/extensions/xep-0158.html for details. Does Jitsi
support CAPTCHAs?

4. Support TLS connections.

Naturally.

5. Have IPv6 support

Given IPv6 peering problems among some providers, just offering IPv6
support doesn't necessarily ensure interoperability. I know we have
this problem at jabber.org.

6. Allow use of ICE

That's not an XMPP server issue at all (see above on signalling).

ICE requires a STUN server. I don't think it's unreasonable to require a STUN server.

7. Provide a reliable relaying mechanism such as JingleNodes,
TurnServer or hosted NAT traversal.

Media relays aren't cheap to run (lots of bandwidth).

8. File transfer

File transfer is mostly a client issue, not a server issue. But see
above on media relays.

This is more complex, I think. There are various specs for file transfer, including in-band (XMPP) and out-of-band (jingle).

···

On May 29, 2013, at 1:40 PM, Peter Saint-Andre wrote:

On 5/28/13 7:15 AM, Yannik Völker wrote:

9. Allow use of HD audio codecs such as Opus or SILK.

That's not an XMPP server issue at all (see above on signalling).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRpj2ZAAoJEOoGpJErxa2pbMkP/jISLiRD5+QP/ykqHvuERt6E
enDhC91fHqoKxTGVBwcr6vM7tndQPyWwrVExfbQi0pCdFSq24Q07VNeKIQgw8oPD
/7Vs4a0f8/o2vIS3Cl/7EHChY+6c2guresxVApsqc+gBw9LtH+w4Rzdf96QQKCce
Uc40H/320fmW5No9+vAmjWH0VqA5638PqDBhAQNUmAVXpfXPqPCrowcBqGrt4s4e
2QrC1ZR9Kcfw0YtPCpiWr2nzwsj9YpsiUxn1gNs3p/LdNgp3YpeK1QKfupphCs2U
IpHZOQjmquzNtYsB1e8DiKCbNX/srV8OYZs2L7zYFAA4UjG2ARDgFw8al1oU3wRm
WrolZRBVUmfrX7qpTs0IQkxjik0K6diHMQO2oNo61mw/ZWtARkJCLIEg9vnqL2gx
ZciEv5QTH9+7jYPk5CDcRtaGpaq2D9BFhCDdW43xzC6K5aUOj8p/saiSRXggfrOY
tXoxZG88idTRUhcHublc0rY1aYNGjVajet4LbeuG/1/uF+irIRRjwx721HupumXU
4VqvYtKSb6H+JSixlKdiYHIeH6BTefmDezN6V8i2ggjhr4Uozqj3SMXZGfqH/Zwk
bAT+yhxiS5inx5qvwRyLrE0tyK5ggTjWFelTYFrE/hx/DWgL6eiYKMZIRPgCFivU
u5jFk/3EHae+Vs2s6uzR
=/ccW
-----END PGP SIGNATURE-----

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com
@xonamiaudio


#5

Hey guys,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There was the idea of creating a list of XMPP servers

Actually, when I created this list, I was thinking about both XMPP and SIP servers. This is important.

which would

be suitable for new users, the Jitsi UI should then display a
account creation window which lets the user choose a username and a
password at a server from that list (one server should already be
preselected, the one with the lowest ping would be preferable). I
would be willing to write mails to the owners of public
XMPP-Servers asking them if they comply with our criteria:

1. Federation

That's a very basic thing that all public XMPP servers support. Unless
of course you're one of the big silos (Google, Facebook, etc.), since
they offer client-to-server XMPP only.

Right. This one was there mostly as a requirement to SIP servers.

2. Allow for the ZRTP handshake to complete

XMPP servers are signalling routers. If they are blocking certain
kinds of signalling, that's a big problem.

This one was also mostly for SIP servers. Most of SIP's NAT traversal these days is handled with Hosted NAT Traversal and latching [0]. Some SIP services do this with things like rtpproxy and MediaProxy. Others use asterisk. The former work perfectly with ZRTP, the latter unfortunately don't.

3. Provide free of charge accounts with support for XEP-0077.

XEP-0077 isn't necessarily a great idea, unless CAPTCHAs are required,
see http://xmpp.org/extensions/xep-0158.html for details. Does Jitsi
support CAPTCHAs?

Yup ... that's agreed. We don't currently support CAPTCHAs as part of XEP-0077 but we could.

At some point, we'd need to have this so that people would be able to create accounts from within the client.

4. Support TLS connections.

Naturally.

Again, mostly there for the SIP servers.

5. Have IPv6 support

Given IPv6 peering problems among some providers, just offering IPv6
support doesn't necessarily ensure interoperability. I know we have
this problem at jabber.org.

This one will probably move to "nice to have". Otherwise we will be eliminating too many options.

6. Allow use of ICE

That's not an XMPP server issue at all (see above on signalling).

Same, mostly a requirement for SIP servers.

7. Provide a reliable relaying mechanism such as JingleNodes,
TurnServer or hosted NAT traversal.

Media relays aren't cheap to run (lots of bandwidth).

Right. This one was mostly for XMPP servers :).

Media relays aren't cheap but they are indispensable. An XMPP server without a media relay would mean that a percentage of our users will be seeing cryptic "ICE failed" errors when trying to do audio and video.

Everyone is free to do what they want with their servers but we can't recommend them unless they have a relay.

8. File transfer

File transfer is mostly a client issue, not a server issue. But see
above on media relays.

Jitsi currently only supports in-band file transfers so we'd need the server to support those. Once we add support for pseudo TCP / jingle file transfers, we'll need them to also have a relay.

9. Allow use of HD audio codecs such as Opus or SILK.

That's not an XMPP server issue at all (see above on signalling).

That was mostly for SIP B2BUAs. Asterisk-based providers won't allow for neither of the above.

Cheers,
Emil

[0] Latching/HNT: http://tools.ietf.org/html/draft-ietf-mmusic-latching

···

On 29.05.13, 20:40, Peter Saint-Andre wrote:

On 5/28/13 7:15 AM, Yannik Völker wrote:

--
https://jitsi.org


#6

Hey Yannik,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Could one of the developers, preferably Emil approve the lists so I
could start talking to the server owners?

Yes sorry for the delay. One thing I don't quite understand though: why did we move away from the original single list? All conditions apply to all servers, it's just that some problems are more likely with XMPP others are more likely with SIP.

I believe the only problematic one was IPv6 we could just be considered a bonus option. Same for calling POTS numbers.

Both of the above could just be an extra column in the table.

Chees,
Emil

···

On 13.06.13, 14:29, Yannik Völker wrote:

XMPP:
1. Federation
2. Do not manipulate a users messages
3. Provide free of charge accounts, support for XEP-0077 and XEP-0158
would be desirable
4. having dual-stacked IPv4 and IPv6
5. Provide at least a STUN server and JingleNodes (providing TURN
encouraged)
6. provide a file transfer proxy

SIP:
1. Federation
2. Allow ZRTP handshake to complete (do not use asteriks)
3. TLS
4. IPv6
5. Allow the use of ICE
6. Allow the use of HD audio codecs (do not use asteriks)

- --
Yannik Völker
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJRubsOAAoJEDqk81AiCyXKScYP/R13GUT68vcDLp9yd1QNhhdf
6e+S1TLWm6vEmjww+jaf3Q2zRjHW+u0nCeSzMV0SgW1VRaTg+8Su/BOCkB7PnHKp
gXoJgbGTdKC1BwGraxTODGQrd9A1NTUHYhVUux3XuRPnHJ/SV/EKyDynyOej71SR
MEn8S4dlRmoWIfNMyxq+zQGLuj3TxoWDvJ9zmJktWK8ff7oALuHln86vR7oURnOG
QnjZhoKYy1yYwsAtiuW81uFWGr1OkRGN1S9PCF3EmHHK5a2ACgEItSd1vyfYdjvH
wYOSFwO6b93fc5MgGDbSXb3rXgkm8bw997i33aJ3zYaFPBQdKgnJvcIV3NH1ZJUs
FVOagVREaV6X5GoaP0NS6FfNCR/D4vlG/7E9i8AtdNzoyanaY8a1pK+QSccFnSGM
Uj6Y9kL2xL07m2j+kwLzMRpOnTqBmHWBbIbgmAex1DARhbDA73kMsWTb/L+aJj0E
zqKrSfB1b8JsarpvQAsfi4xVKeuPi2O4X0kY9aWkVqDRdBfpRBfMezfeCYBmY5At
Tnm9wxqrtcIny3l9D68V3zlgXUg2NU1TR60fzMrrmF3nbf5Oig4jSGf63QcZYhvZ
UYtXRj+G/WZEO3Ib8jF10VU9QgQsmgQaV86e8npbfXI1e6rxAEANvwwZ6q8r3sKu
Hva+B6WIACdoUy2yJWuX
=D7MV
-----END PGP SIGNATURE-----

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#7

Ah, ok, I was just thinking about XMPP ( so the list from in my last
mail is for XMPP )
so: who wants to create the list for SIP servers? (I do not know too
much about SIP and I think that it is better to separate the lists to
address protocol specific issues and to reduce confusion

SIP:
1. Federation
2. Allow ZRTP handshake to complete (do not use asteriks)
3. TLS
4. IPv6
5. Allow the use of ICE
6. Allow the use of HD audio codecs (do not use asteriks)

- --
Yannik V�lker

···

On 29.05.2013 20:34, Emil Ivov wrote:

On 5/28/13 7:15 AM, Yannik V�lker wrote:

There was the idea of creating a list of XMPP servers

Actually, when I created this list, I was thinking about both XMPP
and SIP servers. This is important.


#8

Hello,

Hey guys,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There was the idea of creating a list of XMPP servers

Actually, when I created this list, I was thinking about both XMPP and SIP servers. This is important.

which would

be suitable for new users, the Jitsi UI should then display a
account creation window which lets the user choose a username and a
password at a server from that list (one server should already be
preselected, the one with the lowest ping would be preferable). I
would be willing to write mails to the owners of public
XMPP-Servers asking them if they comply with our criteria:

1. Federation

That's a very basic thing that all public XMPP servers support. Unless
of course you're one of the big silos (Google, Facebook, etc.), since
they offer client-to-server XMPP only.

Right. This one was there mostly as a requirement to SIP servers.

federation is implicitly in SIP, as in any service relying on DNS/IP (like xmpp, email and the likes). If a sip service does not do it, is because they restrict it, not because they can't do it.

Now, for me, federation sounds nice enough (no matter the answer - yes/no) for unfamiliar people with the concept. To discourage people using such service (which I would do), better use stronger terms :slight_smile: , like:

- service type: federated
- service type: jailed

... a bit on joking side, but I would look for a way to encourage not using walled gardens (a tech argument: they break the RFC/specs - not that they care about it).

Cheers,
Daniel

···

On 5/29/13 8:34 PM, Emil Ivov wrote:

On 29.05.13, 20:40, Peter Saint-Andre wrote:

On 5/28/13 7:15 AM, Yannik V�lker wrote:

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *


#9

Oops, it seems that I accidentally sent this privately:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Yannik,

On 13.06.13, 14:29, Yannik Völker wrote: Could one of the
developers, preferably Emil approve the lists so I could start
talking to the server owners?

Yes sorry for the delay. One thing I don't quite understand
though: why did we move away from the original single list? All
conditions apply to all servers, it's just that some problems are
more likely with XMPP others are more likely with SIP.

I believe the only problematic one was IPv6 we could just be
considered a bonus option. Same for calling POTS numbers.

Both of the above could just be an extra column in the table.

I think two seperate lists make sense as it are different protocols
with different posibilities and problems, I split them to reduce
confusion.

They don't have to be separate. CUSAX would also work. So here's the
original list of requirements for SIP, XMPP or CUSAX servers, slightly
modified after discussions:

1. Federation
2. Support TLS connections.
3. Allow for the ZRTP handshake to complete. (i.e. full RTP relaying
preferred to transcoding)
4. Provide free of charge accounts.
5. Allow use of HD audio codecs such as Opus or SILK .
6. Do not prevent use of ICE (intelligent hosted NAT traversal should
only be activated when ICE is not in use).
7. Provide a reliable relaying mechanism such as JingleNodes, TurnServer
or Hosted NAT Traversal. (Currently for SIP, we actually require HNT
because we don't have ICE yet).

Option1. Have IPv6 support
Option2. Allow for incoming and outgoing PSTN calls

Hope this helps,
Emil

1. Federation

···

On Thu, Jun 13, 2013 at 10:08 PM, Yannik Völker <yannikv@yahoo.de> wrote:

On 13.06.2013 16:26, Emil Ivov wrote:
3. Provide free of charge accounts, support for XEP-0077 and XEP-0158
would be desirable
4. Provide at least a STUN server and JingleNodes (providing TURN
encouraged)
5. provide a file transfer proxy
optional:
I. dual-stacked IPv4 and IPv6
(II.Landline calls (i do not think this is possible, please correct me))

SIP:
1. Federation
2. Allow ZRTP handshake to complete (do not use asteriks)
3. TLS
5. Allow the use of ICE
6. Allow the use of HD audio codecs (do not use asteriks)
7. Provide a media relay
8. Provide free of charge accounts
optional:
I. dual-stacked IPv4 and IPv6
II.Landline calls

reworked them a bit:

XMPP:
1. Federation
2. Do not manipulate a users messages
3. Provide free of charge accounts, support for XEP-0077 and XEP-0158
would be desirable
4. Provide at least a STUN server and JingleNodes (providing TURN
encouraged)
5. provide a file transfer proxy
optional:
I. dual-stacked IPv4 and IPv6
(II.Landline calls (i do not think this is possible, please correct me))

SIP:
1. Federation
2. Allow ZRTP handshake to complete (do not use asteriks)
3. TLS
5. Allow the use of ICE
6. Allow the use of HD audio codecs (do not use asteriks)
7. Provide a media relay
8. Provide free of charge accounts
optional:
I. dual-stacked IPv4 and IPv6
II.Landline calls

- --
Yannik Völker
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJRuibVAAoJEDqk81AiCyXKwBEP/2zbgLZ75nO/r4Y154z+/kbh
y9SGOJugPV2Mf+Q1etby8gW5N6frj9Kv33zAt+pRge5NJIGu61H224fvyldlOn+a
P6dfwb08DfagbjaAZkpb71DI6TIaWBOlpckyRWuEVn+d5rWysSQF6m+pQu00zH4y
+ABoUPCLAWjQEQVnL5GFfwGrDzt21zHZUt5uk8/LJDVMCc3/xEwV1w2LPdqQJOOU
Kie4b/AwA3zQkZNbQteqxMpz76NteJzrcHqshpMFF3sSnnbicD8Fc+XT8YrGV+dk
1P4zykVqWqN8ZJNJv4HuX+/qZCPCww4LJdarxKxDDBq/ckIPHLBychMvkZtkgHVo
waPNAl9H9CVErsftPdb/G2Y4sa2tn7M1sNBx9AsKNCvUU4tLzFTQroNmGPFSmvAc
nXHGUO9UMfCSjrtyUmPDXbA2Vqys7keS5fG6L1FKFPmBsKPe6V8yrXaMMAUqDPYt
0iSDino0262CdyM+e8z0ouVzjz+Npl0UO/ZmWhLxmeFqlyVfzN7djznJ5xkkF/M2
OEB3uEcTGVafbAHva6UQGmk0200KWuF+iG19sUVqvBXzgqm2Iv+j/QqImZvX8hG+
fJs5cb9OGgp2WHz3ZXjneFSLpDIKGM1Av6e7qMRlQkWafxEd26iNFQ6wUleNQy5S
/uz4EFpBTOgTuDHxb+je
=cy1O
-----END PGP SIGNATURE-----

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#10

Yannik wrote:

so: who wants to create the list for SIP servers?

perhaps a better question resource-wise: who wants to volunteer
to maintain it long term and keep it up to date?
(perhaps a weekly dead-link cron job could help)

Hamish