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