[Linphone-users] Direct calls with CJDNS

[Stuart Gathman]

The good news is:

We are using linphone in IP6 mode to place direct calls on
"hyperboria.net", the whimsical name of a global IP6 VPN mesh using the
cjdns protocol.  We use the IP6 address as a "phone number", and as it
is the hash of your public key, it is permanent, "portable" to any
device you copy the private key to, mobile, authenticated, and requires
no central servers or routers.  All packets are end to end encrypted and
source routed (which does not have the security problems of source
routing with unauthenticated IPs) - so all relay nodes are untrusted.

The problems (you knew there would be some):

o The linphone GUI for 3.6.1 does not like the private IP space
(fc00::/8) used by hyperboria. 

  It guesses one of your IANA IP6 addresses if you have any, and then
will not let you change it in the GUI.  To work around this, we have to
exit linphone, edit .linphonerc with a text editor, and change the
default identity ( [sip] contact= ).

o Linphone direct calls over IP6 work really well over IANA
(conventional) internet with no NAT issues - they just aren't encrypted
(except by the application level SIP and media encryption options
offered).  And for mobile devices, the IP6 changes  with location.  Is
there a way to enter alternate direct identities in the GUI - perhaps as
a "dummy" proxy of some sort?  That would also solve the previous
problem, but I couldn't figure out a way.

o Linphone cannot run both IPv6 and IPv4 at once.

  There is probably a valid technical reason for this - as the ugly NAT
workarounds for IPv4 SIP probably mean it has its own stack.  However,
this is unfortunate - as most VOIP -> telco providers do not support
IPv6.  This means we cannot accept telco calls while in IP6 mode to talk
to cjdns peers - and vice versa.

Wishes:

o linphone plus cjdns (and other mesh protocols like batman-adv) provide
the features of servalproject.org without reinventing IP or requiring a
specialized VOIP client.  However, it is a shame that the mesh protocols
are incompatible, as any mesh protocol needs lots of people
participating.  There are ways to bridge mesh protocols, so that both
can take advantage of the others users - but that requires someone to
work on it.