== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> Are you referring to the ones from 2015 or so with
> Russian titles? Those are the only ones I am aware of
Yes. There are few. Check out this one:
https://youtu.be/jw-63aOOPk0
> how do you know that phone was running against an
> Osmocom network [...]
I know the author. Also, you can see the logs of OpenBSC
on the background of the mentioned video.
> The relation is simple: if phones like Mot C1xx running
> Motorola's original factory fw don't work with Osmocom
> networks, [...]
In order to confirm, I just tested a Motorola C118 running
the original firmware with Osmocom-based network. LimeSDR-Mini
was used as PHY for OsmoTRX. Everything works fine, including:
SDCCH: SMS, USSD, other signaling
TCH/H: both HR and AMR codecs
TCH/F: FR, AMR and EFR codecs
Probably, the author of this topic has some problems
with codec / network configuration.
With best regards,
Vadim Yanitskiy.
Hello Folks,
I am trying to resolve some open questions about the encoding of the AMR
codec configuration bits S0-S15. (see also 3GPP TS 48.008, 3.2.2.103,
"The coding of Speech Codec Element for FR_AMR, HR_AMR and OHR_AMR:" and
3GPP TS 28.062, Table 7.11.3.1.3-2)
Since I do not have any AoIP network that I could trace against to
verify that all my assumptions about the coding of those bits are
correct I would love to see a trace from some other network. It would be
kind if anyone of you could help me out with that.
All I need is a trace from a call. It is important that AMR is
negotiated in the Assignment request.
best regards,
Philipp Maier
--
Philipp Maier <pmaier(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
These build failures are continuously piling up in my inbox. Would it make
sense to either fix or disable it?
~N
On Sat, Sep 22, 2018 at 08:01:31PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/s…
>
> Package network:osmocom:nightly/simtrace2 failed to build in xUbuntu_18.04/x86_64
>
> Check out the package for editing:
> osc checkout network:osmocom:nightly simtrace2
Hi!
I recently wrote a wireshark dissector for the CBSP protocol, which is
a 3GPP standard for the interface between the Cell Broadcast Centre and
the BSC. It's specified in 3GPP TS 48.049 in case you're curious.
The dissector can be found at https://code.wireshark.org/review/#/c/29745/
However, I couldn't find any protocol traces to verify the dissector against.
So if you happen to have done any work on cell broadcast in 2G network
and have a CBSP trace around (or can generate one): Please send it to
me, thanks!
If I ever find the time, I'd love to add CBSP support to OsmoBSC, and
even to go one step further and write a minimal CBC itself.
Contributions are of course always welcome, in case there are other
interested folks.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello everyone,
I was going to add support for CBCH to osmo-bts-trx for a project, then
just by chance I looked at this ticket: https://osmocom.org/issues/1617 and
I've seen that the issue was reopened 13 days ago.
Any chance on getting some pre-pre-pre-alpha patch? I would gladly test and
work on it in whatever state the code is now, still better than starting
from scratch.
Thanks for the awesome work anyway!
Best regards,
Lorenzo
Hey,
I recently stumbled across shellcheck[1] and think we should make it a goal that our shell scripts don't produce errors/warnings with it.
Some of the examples in the GSM tester:
In jenkins-build-common.sh line 76:
cd "$base"
^-- SC2164: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
In jenkins-build-common.sh line 93:
rm -rf *
^-- SC2035: Use ./*glob* or -- *glob* so names with dashes won't become options.
What do you think? My approach would be:
* Install shellcheck into our build containers
* Run them and provide warnings
* Fix them over time and on new code
* Make CI fail with failures
cheers
holger
[1] https://www.shellcheck.net/