[Freedombox-discuss] VOIP application layer

[Luke Kenneth Casson Leighton]

> Nice.  If we can get a working VOIP application layer that would be
> huge.  Traffic shaping will be the hard part-- both in getting the
> shaping right and in helping the user configure and troubleshoot it.

james, hi,

i've been keeping an eye on P2P VOIP for some considerable time.
allow me to go through the requirements.

requirements specification:

* there must be *NO* user-configuration required
* there must be *NO* "trouble" to "trouble-shoot"
* no user shall get "unsolicited" calls (unless they want to?)
* the voice call shall be completely private (as best as practical)

this translates into a functional specification as follows:

* firewall-busting (NAT, PnP, STUN, TUNS) is absolutely mandatory
* 2nd-party, 3rd-party (and more) traffic routing is absolutely mandatory
* a "calls allowed list" is absolutely necessary, but is independent
of traffic routing
* end-to-end encryption should really be mandatory.
* some efforts to disguise the phonetic make-up of an encrypted voice
call should really be attempted (by placing it inside a continuous
stream)

"independent" traffic routing requires some explanation: a system
could, like skype does, "assist" in routing of VoIP network traffic
(e.g. act as either an arbitrary STUN server if it happens to have two
open ports or just no firewall at all, or it acts as a packet
forwarder).  the participation of any such traffic routing or network
assistance NEED NOT be dependent on whether the system is part of a
particular "friends network", and in fact it would be both detrimental
as well as hamper anonymity if there was in fact a link made between
the two (as it would in any of these peer-to-peer systems to
prioritise or restrict traffic to being between friends only).
fortunately, end-to-end encryption ensures that, just as it does in
skype, any traffic forwarding carried out by any intermediary is still
secure.

sadly, sipwitch does not fulfil the above requirements specification
nor does it conform to the functional specification.

"SIP on its own" is a complete fucking bitch, as anyone with any
knowledge of SIP knows, due to the utterly stupid requirement that the
RTP protocol be transmitted over completely random ports as specified
by the fucking *initiator* of the incoming SIP call, *not* the
recipient.  this alone _completely_ fucks up SIP for use on the
internet, and it's what sipwitch tries - but does not yet succeed - in
helping with.  sipwitch at present performs a minimal amount of
firewall-busting, thus allowing two parties to communicate if and only
if that firewall-busting succeeds, but makes absolutely no provision
for the case when it fails [which is where the additional
traffic-routing through 2nd and 3rd parties is required].

therefore, you cannot not just "drop in a SIP client on its own" and
have a hope in hell of it working: it *has* to have some assistance in
the form of network bypassing.  preferably secure network bypassing.

so: what software a) exists which can help, that fulfils the
requirements b) happens to be debian-packaged already c) actually
works d) allows any SIP client to talk to any other

well... it turns out that gnunet could provide an answer to a) and b)
- i'm currently checking c) and will get onto d) next.

gnunet 0.8 i've managed to get set up on the "gnubone6" quite happily
when installed on a system which is *not* NAT'd (i.e. is directly on
the public internet) but a NAT'd system it's bolloxed (greaaat).
gnunet 0.9.1pre2 i've managed to get set up with a static IPv6 address
(on the system behind the NAT / ADSL router) and i'll let you know
what happens tomorrow once i recover from a 5-hour late night stint
and start again.

given previous experience i've heard of freeswitch and other VoIP
systems being run over OpenVPN i fully expect SIP clients to not even
notice that they're operating over a VPN.

the only other thing that will be needed is a
"friends-to-IP-address-and-port" registration / resolver system.  in
the event of having to integrate the peer-to-peer network services
*INTO* the sip client (or sip proxy) that becomes a massively complex
task.  in the event of providing a transparently-utilised VPN, it's
actually really really easy: just make sure that the registration
service is a) DHT-based (oh look, gnunet has that, and so does that
bittorrent "chat" application someone created, recently) b) the IP
addresses registered are actually on the bloody VPN...

l.