[Freedombox-discuss] VoIP

[Yannick]

Le lundi 07 mars 2011 à 23:04 +1030, Paul Gardner-Stephen a écrit :
> Hello,
> 
> On Mon, Mar 7, 2011 at 2:57 PM, Yannick <sevmek at free.fr> wrote:
> > Le lundi 07 mars 2011 à 09:47 +1030, Paul Gardner-Stephen a écrit :
> >> Hello Yannick,
> >>
> >> On Sun, Mar 6, 2011 at 11:49 PM, Yannick <sevmek at free.fr> wrote:
> >> > Le dimanche 06 mars 2011 à 12:46 +0100, Jonas Smedegaard a écrit :
> >> >> On Sat, Mar 05, 2011 at 07:15:18PM -0800, Thomas Lord wrote:
> >> >> >Step 1:
> >> >> >
> >> >> >Let's pick 5 apps.   I suggest email mailbox hosting, chat,
> >> >> >instant messaging, blogging and FB-ish "walls".
> >> >>
> >> >> What is the difference between "chat" and "instant messaging"?
> >> >>
> >> >> If first one is realtime voice chat, I suggest calling it telephony to
> >> >> avoid misunderstanding.
> >> >>
> >> >> And I suggest to aim even lower that for first iterations.  Not because
> >> >> any of them are weak as selling points, but because not all of them
> >> >> really exist yet (or are prepackaged in Debian, if that matters yo you).
> >> >
> >> > Nowadays, there is no more such difference between Instant Messaging,
> >> > Voice/video Chat and Telephony. It all converges.
> >>
> >> Actually, there is a big difference from a technical perspective.
> >> IM can handle latency, jitter and other network issues much better
> >> than voice can, unless you are happy with >1sec voice latency to
> >> buffer your way through these problems.
> >
> > As far as I know, there is no real Quality of Service on the internet
> > yet, which can be regarded as good as it gives the network a property of
> > neutrality. Situation is of course different in a local network with an
> > administrator, witch is not the case with the freedombox.
> >
> > Thus it doesn't matter what you try to put in the network, text message
> > or voice communication, the latency will be the same. Of course,
> > implementors use some "tricks" like using UDP...
> 
> I agree that the latency will be the same.  What is different is how
> acceptable the user's perspective will be.
> 1sec latency on IM is okay, but is pretty annoying for a voice call.

Sure. This is quite important, but I do think those kind of technical
details aren't quite relevant here, about the freedombox. My point of
view about latency is it most probably under a strong influence of the
routing protocol, i.e. BATMAN in the case of your project.

As I pinpointed somewhere else in this mailing list, it seems babel can
be better on this topic (less hops in the routing and bigger throughput,
but BATMAN seems also better handling packet loss), but an average of
100ms is good enough (which is what I get with my not really good
internet connection and regular RTP protocol), still 50ms or below will
be a nice goal to reach inside the mesh network, i.e. quite locally.
Beside the BATMAN code seems more mature as it has reached linux kernel
integration, while this particular implementation raises questions about
the layer architecture...

> 
> >>
> >> > One issue is there is 2 free (as in speech) protocols: XMPP and SIP.
> >> >
> >> > Personnaly, I would prefer SIP because it has a focus on telephony
> >> > features, stong backup by hardware vendors for real telephony and allow
> >> > to call "real" phones too. The downside is the complexity of the
> >> > specification and interoperability issues.
> >>
> >> Yes, SIP is very good in many ways, but at ServalProject.org at least,
> >> we are looking to create a simple alternative protocol (open of
> >> course) which will tolerate latency and excessive packet loss much
> >> better than SIP does, and will be substantially more bandwidth
> >> efficient when calls are not in progress.  We will still support SIP,
> >> and have a SIP to our own protocol gateway, but we will use our own
> >> protocol where both ends support it to improve performance.
> >>
> >> It should also be noted that SIP is very chatty when no call is in
> >> progress, which can easily swamp a mesh network.
> >>
> >
> > Seems nice... Where is your code source? What is the licence? Will you
> > propose a standardisation as an RFC to the IETF?
> 
> We have yet to write much of the source for this part, it is just the
> planning that we have done at this stage.
> However, all going well we hope to have an implementation by mid-year.
>  It will be GPLv2 or GPLv3 or similar.
> We have not had time to think about putting it out as an RFC etc, but
> are certainly willing to consider it.
> Let us get the code together first :)

Fair enough and nice! Did you have put some effort in the patent issue?

> 
> >> > Make no mistake, SIP do support Instant Messaging too:
> >> > http://en.wikipedia.org/wiki/SIMPLE
> >> >
> >> > Another issue is to get a real world wide adress book. The best I know
> >> > is ENUM, still with no real backup by governements yet, but there is a
> >> > community around it ; see
> >> > http://en.wikipedia.org/wiki/Telephone_number_mapping
> >> > If the project is willing to replace DNS, I think it should include ENUM
> >> > as part of it.
> >>
> >> The trouble with ENUM is that it needs government cooperation to work.
> >> This is why ServalProject.org made Serval DNA (open of course), which
> >> lets people claim their own number, and creates a distributed home
> >> location register so that you can make calls using real numbers, even
> >> if partitioned from the rest of the internet.  I am happy to provide
> >> more information on this if people are interested.
> >
> > This is what some communities do with ENUM too yet, like e.g.:
> > http://www.e164.org/
> > which the ekiga softphone (I'm part of the team) does use cf.
> > http://wiki.ekiga.org/index.php/Enum
> >
> > Thus we do have several technologies able to map phone numbers and IP.
> > One issue here is how to securely attach my phone number to my IP, what
> > does prevent a bad guy to attach my phone number to his IP, stealing it?
> > This is why the governments should be in the loop.
> 
> Well, for our (ServalProject's) primary target being disaster
> response, it is better to let people claim a number and then ask
> questions later.  Waiting for government or telco's is a recipe for
> disaster; it just takes too long.
> At present, our protocol takes the form of informing you when you call
> that the number has not been verified.
> We have provision for a distributed certificate system to allow people
> to certify one another's numbers, so that trust can be layered nicely
> on top of this.  I would like to get the post office or a similar
> organisation to be a certification agency, where you pay them a few
> dollars to sign your key.  This makes it separate from government and
> telcos, and thus more resilient.  But of course we are happy to
> support many certification agencies.

Interesting point about the aim you're into. But about the freedombox I
hope we will not wait for some disaster ;) We do need some kind of trust
about this mapping between the network and the telco. In your video talk
there was an interesting attempt at this using some recorded voice
message to let people decide, this is not really safe, but a good
starting point. As far as I know ZRTP is also based on almost the same
idea, but live (reading a word) witch makes it stronger security-wise as
the word can be random.

> 
> > I'm aware of a workaround for french people, as the french government
> > actually use a certificate for online payment, thus I'm able to prove
> > using cryptographic techniques I'm really who I am with a backup by my
> > government. But it was not meant that way and is far from being user
> > friendly at this point.
> 
> I didn't know about that, it is kind of cool.
> 
> >>
> >> > Last but not least issue is the "NAT" issue. But this one is something
> >> > that would include most of the services provided by the freedombox: each
> >> > freedombox will need a public adress to allow real peer to peer
> >> > connection. I would recommend using IPv6 from the start and drop any
> >> > form of NAT. This would ease a structure where any freedombox could be a
> >> > real server and client.
> >>
> >> This is fine for devices with support for IPv6, which clearly the
> >> freedombox will be.
> >> However, if you want compatibility with as many devices as possible,
> >> then you at least need a plan for NAT/IPv4.
> >> ServalProject.org's approach here is using nodes as gateways and ECC
> >> public keys as actual identities.  We can route this as an overlay
> >> over IPv4 if necessary, and you could use a fairly sensible ECC to
> >> IPv6 mapping.
> >
> > If I get this right, some nodes with public IP will relay the voice
> > stream. Which is the classical approach if you cannot get peer to peer
> > connection because of NAT. e.g. see
> > http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT
> 
> More or less.  It might be private-IP nodes relaying within a NAT,
> with hopefully a node at the edge of the NAT also relaying.
> I'll explain this a bit more below.
> 
> > My question here is who will provide this service? Will it be based on
> > your own nodes with your own bandwidth, or is it based on some DHT
> > architecture ( http://en.wikipedia.org/wiki/Distributed_hash_table ) in
> > witch everybody can be eligible to be a relay ?
> 
> All nodes on a Serval compatible network will offer this service
> implicitly as part of being on the mesh.
> Thus if your node offers a data service, e.g., via cellular, DSL or
> satellite, it is simultaneously the gateway and private-IP space
> provider.  Note that there is not actually any NAT, because in this
> model Serval uses a UDP broadcast overlay for the mesh, so if you had
> to, everyone could have the same IP address and it would still work,
> and everyone could still communicate.

Seems to me we are talking about an unstructured network here based in
some flooding mechanism (versus DHT based networks). From what I've read
and some experience I do have with this kind of network it has strength
in some areas and also some weaknesses, one issue might be scalability.

The point about the same IP for everyone might be cool efficiency wise
for VoIP, but I'm afraid it will break almost any other use of the
freedombox we are talking about here.

Best regards,
Yannick