<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi, Thanks for everyone's suggestions and thoughts - I tried jitsi
and was <br>
semi-successful (got sound and video working in one direction and
the problems<br>
may have been specific to one of the laptops). Might try that again
in the<br>
future but will also hope that these things get a bit simpler with
time!<br>
Cheers,<br>
Nick<br>
<br>
On 02/01/15 11:26, Tim Dobson wrote:<br>
<blockquote type="cite">On 31/12/14 16:24, johnc wrote:<br>
> Some Problems: -Mobile phone specific: -- mobile phones vary<br>
> greatly in their ability to run sip clients using crypto.
I've seen<br>
> sip clients use 100%CPU with awful audio quality on a few
phones<br>
> including high end samsung models. -- The latency on 3G is<br>
> typically around 1 second. Expect horrible lag etc. Using
WiFi is<br>
> the only way to go unless you are lucky enough to be on 4G.<br>
<br>
> Non mobile phone specific: - ostel's only server is in the
US,<br>
> latency is about 120ms. Not so good if you are in Europe. We
could<br>
> build our own :-). - If you are going to build an ostel
system I<br>
> suggest you include the topology hiding setup from my wiki or<br>
> elsewhere in your Kamailio config. SIP leaks IP/location<br>
> information unless you make an effort to obfuscate it.<br>
<br>
One solution I quite like, which works *if* you:<br>
a) trust the clients to a degree<br>
b) are happy with non-federated, centralised phone system, with
the<br>
PBX as a single point of failure<br>
<br>
is:<br>
<br>
Your favourite SIP-based PBX system over OpenVPN.<br>
<br>
So, your phone connects to OpenVPN, and then the sip clients
connects<br>
to the PBX via SIP, over a VPN.<br>
<br>
Pros:<br>
a) as secure as your deployment of OpenVPN<br>
b) removes NAT issues - there aren't any - the SIP/RTP goes via
OpenVPN<br>
c) It mostly 'just works' (tested with .bg client connected to .uk<br>
server with no issues)<br>
d) possible on mobile [android], desktop and in modern Snom
firmwares<br>
<br>
Cons:<br>
a) nontrival to setup<br>
b) centralised [not federated, and not designed to be]<br>
c) requires the giving out of VPN certificates to each client in
advance<br>
d) SPOF [or compromise] on PBX system<br>
e) not really possible to 'just leave on' on mobile without
emptying<br>
your battery<br>
f) only known to be *super reliable* on Snom desk phones,
connected to<br>
an uncongested network<br>
g) certainly not without points of weakness<br>
<br>
---<br>
<br>
It's not foolproof. It's not bombproof. But it is a nice
architecture<br>
that works for some scenarios. :)<br>
<br>
-Tim<br>
</blockquote>
<span style="white-space: pre;">><br>
> _______________________________________________<br>
> HacktionLab mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:HacktionLab@lists.aktivix.org">HacktionLab@lists.aktivix.org</a><br>
> <a class="moz-txt-link-freetext" href="https://lists.aktivix.org/mailman/listinfo/hacktionlab">https://lists.aktivix.org/mailman/listinfo/hacktionlab</a></span><br>
<br>
<br>
</body>
</html>