[Olsr-dev] OLSR nameservice to do something like E.164 ENUM and SIP SRV records?
Wed Oct 17 03:13:22 CEST 2012
On 17/10/12 01:45, Kim Hawtin wrote:
> On 17/10/12 09:18, Daniel wrote:
>> Can anyone imagine a good solution?
>> Maybe a generic way for more complex distributed DNS is the answer, I know that
>> people are cracking their heads with this already for a while... Again:
>> mesh-relevant results and experience is most welcome :)
> It might pay you to have a look at the Serval project to see if what they are
> doing is relevant.
I'm aware of Several/Commotion, afaik it's basically village-telco's batphone
and certainly very useful for a pure mobile ad-hoc scenario such as what they
describe on the page.
However, I think of OLSR-routed VoIP more as a supplement, peacefully
co-existing with other SIP-based VoIP services, allowing me to reach friends in
the community network directly, while still using sipbroker if possible and if
not then any POTS-termination and DID services for the rest of the world...
batman has the advantage to behave nicely in very dynamic mobile setups, such as
smart-phones with low-powered omni-directional wifi moving around all the time.
The sad thing about most smartphones and tablets is that the range of my (bio)
voice is higher than the built-in wifi, it's obviously intended for tethering
with nearby devices and got a range which in most cases can compare with
bluetooth (i.e. a few meters). Of course, this can be supplemented by some more
powerful routers, like village-telco boxes or anything which can also run batman.
Anyway, arig is a community infrastructure mesh, i.e. less "mobile" and
including some long-distance links and we are using OLSR for now.
Surely, if (some of) the nodes run asterisk and we also got some "usual" APs in
infrastructure mode with DHCP, everyone can use a normal SIP app like sipdroid
to connect to it with a smartphone.
No judgment on which tech might be better (despite the "B" of BATMAN), I can see
that both got advantages and disadvantages (the whole proactive vs. reactive vs.
hybrid story has been discussed a lot in the past and I won't get too deep into
In VoIP, think of pro-active as in having a decentralized DNS-like service
distributing something like E.164 ENUM and SRV records, in short: make sure to
distribute the phone directory to everyone in town :)
Contrary to that, I'd call stuff like DUNDi or (I guess, correct me if I'm
wrong) batphone "reactive". This works by shouting out for anyone you (or
someone you just heard shouting) want(s) to reach until you get an answer from
Similarly to IP routing, both have their bottlenecks. Proactive results in a
relation between number of nodes and the consumed resources (RAM, CPU power) on
each node. Reactive means that there is a relation between number of nodes and
the (shared!) bandwidth consumed for flooding/"shouting out for someone".
Probably the solution is somewhere in the middle (e.g. reactive with excessive
caching) or by having several pro-active and re-active layers.
Or maybe just share the "phonebook" in a protocol-agnostic way, e.g. use another
DHT thingy on top of whatever routing protocol...
So: DUNDi would be nice, but it's on Layer 2 i.e. would only work in a
batman-adv or AODV mesh.
As we somehow need distributed DNS anyway, just have it done in a way which also
allows distributing SRV (and ENUM) records, not just a /etc/hosts file and a
very custom way for service announcement in OLSR nameservice...
More information about the Olsr-dev