[Commotion-dev] FYI: Serval & OpenBTS integration

[Dan Staples]

That dnahelper debug flag helped me find what the problem was, though I
had to look through the source code to find the config option I needed
to set to fix it. I had to set
dna.helper.argv.1=/home/openbts/app_servaldna/conf_adv/num2sip.ini.
Also, how can I specify a log file to use? I haven't been able to find
the various config options besides the couple listed in
doc/Servald-Configuration.md.

After setting this config option, I was able to successfully resolve
DIDs in both directions. However, I still wasn't able to place calls
from one to the other. When calling a serval number from OpenBTS, I got
the following warnings:

[Nov 19 11:00:56] WARNING[2392]: channel.c:5414 ast_request: No channel
type registered for 'VOMP'
[Nov 19 11:00:56] WARNING[2392]: app_dial.c:2039 dial_exec_full: Unable
to create channel of type 'VOMP' (cause 66 - Channel not implemented)
When calli
This occurred even though I had added app_servaldna.so to
/usr/lib/asterisk/modules/. I also had to add a new context to the
sample extensions.conf provided by serval in order to get my
openbts-registered phones to make calls:

[phones]
include => openbts

In the other direction, when setting the number of a serval phone to the
asterisk echo extension, and calling it from another phone's peer list,
it just goes through as a regular serval voice call between the two
phones instead of going to the echo service. Is this what you meant by
"Remote call to local asterisk test number" in the documentation, or am
I doing it wrong?

Dan

On 11/16/2012 07:22 PM, Jeremy Lakeman wrote:
> It certainly can work. I've successfully placed a phone call in both directions.
>
> Have you looked at the log file produced from the servald instance on
> the openbts box?
> You also could try turning on more debugging options like this one;
> servald config debug.dnahelper 1
>
> On Sat, Nov 17, 2012 at 3:04 AM, Dan Staples
> <danstaples at opentechinstitute.org> wrote:
>> Jeremy,
>>
>> Is number resolution implemented between Serval and OpenBTS? As per the
>> documentation, I tried doing a dna lookup for an OpenBTS number, and got
>> nothing, even doing the lookup from the OpenBTS box itself. Running
>> num2sip.py manually, I was able to get the IMSIs of OpenBTS phone
>> numbers, but that's about it. I'm running servald built from the latest
>> commits.
>>
>> Dan
>>
>> On Wed 14 Nov 2012 11:34:59 AM EST, Dan Staples wrote:
>>> Thanks Alexander, we'll try all those suggestions. Do you know if
>>> Asterisk needs to be running in order for OpenBTS to write to the
>>> Subscriber Registry db, or does OpenBTS write directly to the db?
>>>
>>> Also, you mentioned at the Hackday that some phones have compatibility
>>> problems with OpenBTS...what exactly about those phones in incompatible?
>>> Is it certain brands or chipsets?
>>>
>>> Dan
>>>
>>> On Tue 13 Nov 2012 10:54:09 PM EST, Alexander Chemeris wrote:
>>>>
>>>> On Tue, Nov 13, 2012 at 4:56 PM, Dan Staples
>>>> <danstaples at opentechinstitute.org> 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?
>>>>
>>>>
>>>> There could be several reasons for that. Ones which come to my mind:
>>>>
>>>> 1. Phone thinks that it's already registered and just does not
>>>> communicate with the BTS at all. Then there is not reason for the BTS
>>>> to contact with the Subscriber Registry. This may happen if you power
>>>> on a BTS soon enough after you powered it off - for a phone it looks
>>>> like BTS signal was lost and then re-appear, e.g. like you went to a
>>>> tunnel and came back. To force a phone to register after a BTS restart
>>>> is to change BTS's LAC. In that case a phone thinks it moved to
>>>> another Location Area and will send a Location Update Request (LUR).
>>>>
>>>> 2. "SIP.Proxy.Registration" configuration parameter is not configured
>>>> properly in the OpenBTS installation.
>>>>
>>>> Thus I recommend you to:
>>>> * Double-check SIP.Proxy.Registration configuration parameter.
>>>> * Run Wireshark and check for SIP traffic.
>>>> * Run `tail -f <OpenBTS_logs>` and check whether there is any traffic
>>>> between the phone and the BTS when you expect it.
>>>>
>>>> --
>>>> Regards,
>>>> Alexander Chemeris.
>>>> CEO, Fairwaves LLC / ООО УмРадио
>>>> http://fairwaves.ru
>>>> --
>>>> Dan Staples
>>>> Open Technology Institute
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>> --
>>> Dan Staples
>>> Open Technology Institute
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev

-- 
Dan Staples
Open Technology Institute