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

[Teco Boot]

On service discovery: we use the p2pd plugin. This is more or less
the mdns plugin, but largely cleaned up and added config for filters.
Multicast packets from apps are flooded in the mesh. We use it for MS Groove.

BMF can do similar things, but no filters here. And more overhead.
p2pd and mdns encaps the packet into an olsr message, where bmf sets up
tunnel interfaces and sends the ip multicasts over it.

Because flooding optimization is turned of in *current* olsrd, scaling is
not as good as it should be. Plans for fixing this is for olsrv2. Then,
link metrics is part of the core protocol, instead of the etx hack right now.
olsrv2 should outperform todays' olsr, also because message compression.

Still, multicasting services doesn't scale as well as a service oriented
mechanism like dnsupdate. But then, there is the dependency on this server 
infra.

This is also a topic in Homenet: how to improve multicast DNS for multi-hop 
communication. See new initiative on this:
http://www.ietf.org/mail-archive/web/ietf/current/msg75203.html

Teco




Op 17 okt. 2012, om 04:47 heeft Jeremy Lakeman het volgende geschreven:

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