[Olsr-dev] OLSR nameservice to do something like E.164 ENUM and SIP SRV records?

[Jeremy Lakeman]

On Wed, Oct 17, 2012 at 11:43 AM, Daniel <(spam-protected)> wrote:
> Hi Kim,
>
> On 17/10/12 01:45, Kim Hawtin wrote:
>> Daniel
>>
>> 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.
>>
>>   http://www.servalproject.org/
> 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.

It certainly started that way, our upcoming 0.90 release is very
different though.

> 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...

We're thinking of those kinds of use cases. We've written a prototype
asterisk channel driver that can talk to serval devices, so we don't
need to bundle asterisk on every phone and could add security without
dealing with the complexity of SIPs/zRTP.

When a serval phone searches for a phone number, a local asterisk box
can indicate their ability to handle the call for you, based on its
configured dialplan, bridging between any protocols asterisk supports
seamlessly.

We're also thinking about a global DHT based phone book for
serval-to-serval calling. And we may build a central service using
asterisk for POTS termination. Though we will need to think about how
we cover the cost of our expenses...

> 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.

As above you could deploy asterisk on multiple nodes, each with the
serval channel driver & daemon, responding to remote requests for
their locally configured extensions. And with their local dialplan
configured to search the mesh for outgoing calls as well.

We've built this specifically for integration with OpenBTS GSM towers,
which use a database for their extensions, but it also works with much
simpler dialplan configurations. How you structure phone number
allocations and dialplan pattern matching is completely up to you.

Plus I've been working on getting the serval daemon to co-exist on an
olsr based mesh. So olsr handles the topology, and a plugin is used to
flood phone number lookup packets across the mesh in an efficient
manner. But otherwise serval assumes the network structure is
transparent for direct communications once it has discovered IP
addresses.

> 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
> that now).
>
> 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
> somewhere.
>
> 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.

As a step towards our DHT based directory, we've built a simplistic
in-memory directory service. Each node periodically sends their
details to a configured node running the service. The service will
respond to phone number requests on your behalf, and can also relay
packets for you. Though we haven't implemented any automated
announcement / discovery of directory service nodes, or STUN-like
direct path detection yet.

A network might have multiple nodes that are [configured / decide] to
run the directory service for redundancy. Though we haven't finalised
the design yet.

> 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...
>
>
>
> Cheers
>
>
> Daniel
>
> --
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev