[Commotion-dev] FYI: Serval & OpenBTS integration

[Jeremy Lakeman]

On Tue, Nov 13, 2012 at 9:51 PM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
>>> How does an OpenBTS user know his number? Do you send a welcome SMS
>>> with a number on registration?
>>
>> That's something we haven't changed from the default install. This
>> setup still uses the same database for local number registrations via
>> the web UI or SMS message.
>
> I.e. BTS allocates phone numbers by itself and just announce them to
> the network? I thought originally that Serval DNA allocates phones
> numbers for users.

With our android app, you assign your own phone number and roll a
public key when you use it for the first time.
Then an instance of our servald daemon will run in the background to
answer phone number lookups.
With this BTS solution, a single instance of servald with a single
public key, answers phone number lookups by checking the registrations
in the database.
Then when you place a phone call to that instance of servald, we run
the asterisk diaplan for the phone number you dialled.

>>> Do you think there are benefits of using Serval DNA in a pure OpenBTS
>>> multi-site installations, i.e. without other non-OpenBTS Serval
>>> devices?
>>
>> With no single point of failure, one BTS box could still allow local
>> phone calls and any two boxes could form a working network.
>> Though we still have a lot of work to do, improving codec support and
>
> Do you mean codec support in your Android application? I thought
> you're using a normal SIP and thus shouldn't have any issues with
> codec support.

We used to use SIP and asterisk on each phone, but it wasn't really a
good fit for all of the other things we wanted to do. And sip has some
weird timing failures based on packet loss.
So we've built our own session protocol and audio transport, on top of
a network layer that provides transparent encryption and routing of
payloads, using public keys as network identifiers.
Removing asterisk has drastically reduced the size of the application
and reduced the number of things that could go wrong. But essentially
re-implementing the entire network stack in user-space is taking some
time.
Are we headed in the right direction? Maybe, time will tell.

>> our routing protocol. With servald handling the network routing and
>> packet delivery, the network layer has the potential to carry more
>> simultaneous calls over a wifi network.
>
> Do you aggregate packets to increase number of voice calls over WiFi?

With a single 2.4Ghz wifi channel, the network tends to top out at
around 3,500 packets per second regardless of how small they are. With
an rtp packet every 20ms, that would give you maybe 30 usable phone
calls over one wifi link. Less if you need to repeat these packets
over multiple hops on the same channel.
We aggregate any payloads travelling over the same network link
between nodes, based on our routing table and QOS flags. With a good
audio codec we should be able to beat that number of concurrent calls.

>>> Does Serval DNA works well with thousands of users?
>>
>> Good question, no idea. There will probably be scalability issues
>> we'll need to deal with so we don't flood a large network just trying
>> to resolve phone numbers. Probably some kind of election process to
>> pick a small number of network nodes to collect and search the entire
>> phone directory.
>
> Ok.
> GSM network may easily cover thousands of users, even with a single
> base station and thus scalability is an issue.

The main scalability limits for phone number searches would be based
on the number of nodes on the network. If you don't have that many
base stations, everything should be fine for now.

>>> Does Serval support SMS messages?
>>
>> We have a text messaging solution for android, where we can assume
>> that one identity is only reachable via one instance of the software.
>> We'd need to build something a bit different to deliver messages to
>> users roaming between BTS boxes. We haven't tackled that yet, but we
>> might get around to it eventually.
>
> Would be a great thing.
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ООО УмРадио
> http://fairwaves.ru