Hi.
A little heads-up - I've noticed that certificate on gerrit server has
expired:
gerrit.osmocom.org uses an invalid security certificate. The certificate
expired on 08/01/2016 12:24 PM. The current time is 08/01/2016 12:33 PM.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi,
Is there any intention / interest among current community developers to
implement the DTMF for osmo sip connector?!
Thanks,
Stefan
On Jul 27, 2016 3:33 PM, "Holger Freyther" <holger(a)freyther.de> wrote:
> On 27 Jul 2016, at 20:19, Brian Butterly <bbutterly(a)ernw.de> wrote:
>
> Hi,
Hi!
> has anyone recently put together a functional setup with OsmoNITB and
> Asterisk (+LCR)?
why asterisk? why LCR? The osmo-sip-connector is a "trivial" piece of
software that bridges MNCC to SIP (and back) and let's everyone else do the
heavy lifting. In contrast to LCR it currently lacks:
* Multi-party calls (a bit harder)
* DTMF (quite easy but not done)
holger
Hi,
has anyone recently put together a functional setup with OsmoNITB and
Asterisk (+LCR)?
I've got multiple errors while compiling LCR with Asterisk, mainly
unknown definitions and a set of missing functions.
My setup:
-NanoBTS
-current OpenBSC (running perfectly)
-Ubuntu Xenial, 64Bit, VBox VM
-current LCR from Osmocom Repos
-Asterisk (build without any issues)
--1.8.32.3 from Asterisk Page
--1.6.2.24 from Asterisk Page
--11.32.0 form Asterisk Page
--last 13.x release vie apt
I had expected the newer versions to be incompatible, still gave them a
shot anyways.
I've started fiddling with LCR, but before I go deeper into that, I just
wanted to check if there was some defined approach which would get
everything up and running.
I'd be very thankful for any hint or maybe some information on which
versions of what will actually work together.
Thanks!
Brian
Hi all,
I have some patches that probably fix some corner cases of dynamic pchan
switching. However, since I'm technically already in vacation, I will only be
able to properly test them in about 10 days' time.
If they should become interesting before that, the changes are pushed to
branches called neels/dyn_fixes in openbsc and osmo-bts.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
I just came across this compiler warning:
l1sap.c: In function 'gsmtap_ph_rach':
l1sap.c:291:8: warning: assignment from incompatible pointer type [enabled by default]
*data = &l1sap->u.rach_ind.ra;
^
It's a
uint16_t ra
and used like this in common/l1sap.c:
static int gsmtap_ph_rach(struct osmo_phsap_prim *l1sap, uint8_t *chan_type,
uint8_t *tn, uint8_t *ss, uint32_t *fn, uint8_t **data, int *len)
{
[...]
*data = &l1sap->u.rach_ind.ra;
*len = 1;
A cast like this would fix the compiler warning and make sense if data is
interpreted to point at a 16 bit data block, probably in host byte order
though:
*data = (uint8_t*)&l1sap->u.rach_ind.ra;
*len = 1;
But *len = 1 means that **data is an 8bit value?
This is sent to gsmtap.
Is *len = 1 something we should fix?
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi folks, I'm seeing some unexpected behavior from OsmoNITB. I am running from the Debian 8 nightly builds from July 25 for everything.
My OpenBSC configuration is set as follows:
network
[...]
auth policy accept-all
[...]
nitb
subscriber-create-on-demand
assign-tmsi
[...]
When a new phone tries to camp to the network, it's rejected as follows: https://gist.github.com/shaddi/7674680c329f14c0042fbeca5227962e ("Failed to find subscriber"). My full openbsc.cfg is in that gist as well.
If I create the subscriber by IMSI via the VTY though, it camps fine and everything else works as expected. When I tested this this configuration a few weeks ago with an earlier build (sorry, can't recall which one), adding the subscriber manually wasn't necessary, and with the configuration above seems like it also shouldn't be necessary. Couple questions:
- Is this the expected behavior for this configuration?
- If so, is there currently a way to achieve the prior behavior (subscriber created automatically when a new phone tries to camp, rather than being rejected)?
Thanks,
Shaddi
Today, gerrit has merged four of my changesets twice for some reason (even
though they had the very same Change-Id), meaning that openbsc.git master got
four empty commits.
It could end up being a stupid thing to do, but I thought if at all then right
now and no later: I forced master HEAD back so that we don't have empty commits
in it, back to d1c0e3755f2832270a16bdb2d350463409cad887.
I apologize in advance for any inconvenience caused. If you need help to
recover from a diverged master branch, don't hesitate to ask!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi All,
On one of our sites osmo-nitb was hanging a few seconds after startup.
It took me a while to track it down, and I'm sorry I do not have log
output as it has gone to scroll buffer heaven, and I do not want to
break the system again right now to get another output, but I can say
more or less what happens.
If I see it again, I'll be sure to capture full debug log. I also have a
backup of the state of the offending hlr, so I can bring it up locally
and see if I can replicate and send the log.
In fact, there was nothing out of the ordinary in the log anyway before
nitb simply stops responding. (CTRL-C still shuts down cleanly if would
seem)
This 'bad' hlr has some 30,815 subscriber entries, one of them has empty
string for extension.
(We normally never get to anything near 30,000 as we purge inactive
subscribers regularly, but the blank extension had broken our purge job)
On this blank extension issue, i'm not sure it coincides with the hang,
but I noted this error followed by DBI traceback from here:
http://git.osmocom.org/openbsc/tree/openbsc/src/libmsc/db.c#n54
Error was non unique value for column extension, which makes sense of
course, as we don't give it a value.
Also seems we don't recover from this, as |db_subscriber_alloc_exten()
will never be called?
|
I deleted some 28,000 subscriber entries that were not commissioned
users, and the nitb then functions, so I'm at a loss to know where it
might have been actually stuck, or if it might be related to the blank
extension, or to the large amount of subscriber entries, or something else.
Maybe it's obvious to somebody. I have of course deleted the blank
extension entry now from the hlr.
Thanks!
Keith.
Just to let you know, the addition of GSM_PCHAN_TCH_F_TCH_H_PDCH in libosmocore
implicitly broke the ctrl interface tests in openbsc.
FAIL: testBtsChannelLoad (__main__.TestCtrlBSC)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./ctrl_test_runner.py", line 237, in testBtsChannelLoad
self.assertEquals(r['value'], 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0')
AssertionError: 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0 unknown 0xb,0,0' != 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0'
because this is unexpected output: "unknown 0xb,0,0"
So *any* commit submitted to openbsc will currenty fail.
I'll probably fix it shortly with a commit to openbsc...
This also directed my attention towards the pchan_load mechanics. It always
shows a TCH/F_PDCH entry, but in PDCH mode those would not have any load. I
guess it makes sense in the current scheme of things, though it could make even
more sense to record channel load not as separate TCH/F_PDCH but in the TCH/F
slot, depending on current pchan mode? Similarly for upcoming
TCH/F_TCH/H_PDCH: record in the TCH/F or TCH/H slot according to current pchan
mode... (For now I'm focusing on completion of TCH/F_TCH/H_PDCH usability, if
at all pchan_load tweaks would come later)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
I've added permission to submit a reviewed patch to the known users group,
re:
On Sun, Jul 24, 2016 at 04:08:35PM +0000, lynxis lazus wrote:
> @Holger: I'm not allowed to do so on gerrit.
On Mon, Jul 25, 2016 at 08:08:00AM +0000, Tom Tsou wrote:
> Holger, Gerrit does not allow me to submit.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte