[Commotion-dev] FYI: Serval & OpenBTS integration

[Jeremy Lakeman]

We store DID's as a plain text string in our keystore. If you tried to
store something that wasn't a phone number, or no number at all, I'm
certain there are a number of validation routines that you'd trip over
at the moment.

You can certainly enter any name you like though.

Either way, the rhizome bundle is likely to be addressed to a public
key instead of a logical name. Apart from our MeshMS text UI, we
haven't really dealt with how the user will choose a recipient for
other types of bundles.

We need a better way to indicate which instances of servald have a
connected phone service, and which do not. Perhaps we should
generalise our phone directory lookup to allow for other types of
service discovery.

On Tue, Nov 13, 2012 at 11:32 PM, Dan Staples
<danstaples at opentechinstitute.org> wrote:
> Also, Jeremy, can Serval use non-numeric DIDs? We were thinking that
> that would make it easier for us to integrate Serval/OpenBTS with
> Commotion...for instance for people who wanted to send a Rhizome bundle
> to a Commotion node by using the node's hostname instead of a telephone
> number for the DID.
>
> Dan
>
> On Tue 13 Nov 2012 07:56:41 AM EST, Dan Staples wrote:
>> Thanks for the documentation on integrating Serval with OpenBTS. Here
>> in our lab we're on our way to testing that out, using our Range 5150
>> for the radio hardware. Our snag right now is that for some reason our
>> OpenBTS build isn't talking to the Subscriber Registry db when a
>> registration is made...anyone else experienced that?
>>
>> Everything is working fine on the Range commercial OpenBTS version,
>> however, so I may just try to install servald and serval-asterisk
>> integration on the commercial version to test it out.
>>
>> Dan
>>
>> On Tue 13 Nov 2012 07:09:46 AM EST, Jeremy Lakeman wrote:
>>> 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
>>>
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>> --
>> Dan Staples
>> Open Technology Institute
>
> --
> Dan Staples
> Open Technology Institute
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev