[HacktionLab] Open Source / federated VOIP?

Jim McTwanky mctwanky at riseup.net
Mon Jan 12 22:17:43 UTC 2015

.....educated /opinion/......that is.

On 11/01/15 20:44, nmd wrote:
>  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:
>> On 31/12/14 16:24, johnc wrote:
>>> 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.
>>> 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.
>> 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
>> HacktionLab at lists.aktivix.org
>> https://lists.aktivix.org/mailman/listinfo/hacktionlab
> _______________________________________________
> HacktionLab mailing list
> HacktionLab at lists.aktivix.org
> https://lists.aktivix.org/mailman/listinfo/hacktionlab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aktivix.org/pipermail/hacktionlab/attachments/20150112/04cd44b7/attachment.html>

More information about the HacktionLab mailing list