- OpenBSC - lists.osmocom.org

EFR and/or AMR codec with Osmo-BSC/SIP-connector/Asterisk
by Sipos Csaba 07 Aug '23

07 Aug '23

Dear list, I managed to set up my E1 based Nokia BTS, the complete Osmo-CNI stack, SIP-connector and Asterisk. MO/MT calls do work as well as external SIP calls to and from mobile as well. But no matter what I do only plain FullRate calls are possible. Under osmo-bsc.conf code support is set like this (the BTS HW do support all of these codecs): codec-support fr efr amr but once I also add "codec-list fr3 fr2 fr1" to the MSC section of the osmo-bsc.conf, the calls wont establish anymore. I watched Neel's OsmoDevCall presentation on this topic, but it is not very clear what codecs are supported when osmo-sip-connector and an external PBX is used? Regards, Csaba

5 5

OsmoBTS project
by catalinaelena119＠yahoo.com 07 Aug '23

07 Aug '23

I have git-cloned https://gitea.osmocom.org/cellular-infrastructure/osmo-bts this project in order to have a solution for calling 2 mobile phones in my own network. I dont have any experience with this. I have instaled and configured in the past the same solution from PenHerts git but it is a lil bit old. I want to configure and install this solution bu i do not know the exact steps to do that. I dont find any configuration file or i do not know what to do with them. I do not have any experince with this domain and i want to know the steps in order to run this project properly. Could you help me with any directions?

2 1

Deprecating support for big endian in Osmocom
by Harald Welte 31 Jul '23

31 Jul '23

Hi all, during recent patch review (https://gerrit.osmocom.org/c/osmo-trx/+/33737) the topic of continuing to maintain support for big endian machines has come up. While traditionally I've always been a strong proponent of writing portable code that can run also on big endian systems, it is not the year 2003 or 2008 anymore, and PowerPC (the main big endian platform) is dead by now, as is SPARC. Not just in newly-built processors, but also in existing and still operating machines, at least of the class that would run our code. So unless somebody objects with strong arguments, I'd propose to officially and explicitly drop supporting big endian systems from osmocom CNI projects. From what I can tell, this would primarily mean * drop the struct_endianness check from the commit verification * removing all our struct_endianness-generated or other code that explicitly adds big endian support * adding some kind of #warning or even #error to a common libosmocore header file if anyone tries to build on big endian This obviously doesn't mean we can abandon using [osmo_]{htonl,ntohl}, as network byte order is still network byte order. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

5 6

Trying to disable the UST service 124.
by Alejandro Blanco Pizarro 28 Jul '23

28 Jul '23

Hi all, It's Alejandro Blanco. I would like to disable the UST service 124 so that I connect the smartphone to a gNB based on srsRAN. However, there is an error after trying it. Find a screenshot below that shows the error message. Do you know how to fix this? Thank you. [image: image.png] Best regards, Alejandro ---------------------------------------------------------- *Alejandro Blanco Pizarro, PhD <https://alejandroblancopizarro.github.io/>* *Post-Doc at **The University of Edinburgh* ----------------------------------------------------------

3 4

Osmocom discourse as alternative to mailing lists
by Harald Welte 27 Jul '23

27 Jul '23

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Re: EFR and/or AMR codec with Osmo-BSC/SIP-connector/Asterisk
by Sipos Csaba 25 Jul '23

25 Jul '23

Hi, So, I migrated to today's master, and tried with MNCC local to make sure the PBX is not participating. Using an E1 based Nokia InSite and the target codec is EFR (as the InSite does not support AMR). And the test case is a MO - MT call. On the BSC config: codec-support fr efr codec-list fr2 On the MSC config: mncc-int default-codec tch-f efr default-codec tch-h hr The BSC log say: Tue Jul 25 21:53:45 2023 DCHAN abis_rsl.c:1291 lchan(0-0-2-TCH_F-0)[0x562876541b90]{ESTABLISHED}: (type=TCH_F) CONNECTION FAIL (cause=Remote Transcoder Failure [ 28 ]) Tue Jul 25 21:53:45 2023 DMSC osmo_bsc_bssap.c:1465 SUBSCR_CONN(msc0-conn1_subscr-IMSI-001010101000050-TMSI-0x910bc287)[0x562876543a00]{WAIT_CLEAR_CMD}: Event MT_DTAP not permitted The MSC log say: Jul 25 21:56:46 openbsc osmo-msc[759]: <0001> transaction.c:130 LCLS disabled globally Jul 25 21:56:47 openbsc osmo-msc[759]: <0007> mncc_builtin.c:373 (call 80000007) Message 'MNCC_RTP_CREATE' unhandled Jul 25 21:56:47 openbsc osmo-msc[759]: <0001> transaction.c:130 LCLS disabled globally Jul 25 21:56:48 openbsc osmo-msc[759]: <0007> mncc_builtin.c:373 (call 7) Message 'MNCC_RTP_CREATE' unhandled So this seems to be an issue within the Osmocom stack, the external MNCC connection was disabled. Regards, Csaba

1 0

<0006> msc_main.c:572 Failed to parse the config file: '/etc/osmocom/osmo-msc.cfg'
by Sivanesh Kumar K 21 Jul '23

21 Jul '23

Hi all, I deployed osmomsc in docker in open5gs on raspberry pi4b with ubuntu22.10 OS. I am able to build the oscmomsc but osmomsc is excited having below error: $ docker logs osmomsc There is no such command. Error occurred during reading the below line: sgs <0006> msc_main.c:572 Failed to parse the config file: '/etc/osmocom/osmo-msc.cfg' I followed below steps in docker file to build FROM ubuntu:focal ENV DEBIAN_FRONTEND=noninteractive # Install updates and dependencies RUN apt-get update && \ apt-get -y install wget gnupg telnet RUN wget https://downloads.osmocom.org/packages/osmocom:/latest/xUbuntu_20.04/Releas… && \ mv Release.key /etc/apt/trusted.gpg.d/osmocom-latest.asc && \ echo "deb https://downloads.osmocom.org/packages/osmocom:/latest/xUbuntu_20.04/ ./" > /etc/apt/sources.list.d/osmocom-latest.list && \ apt-get update && apt-get -y install osmo-msc CMD /mnt/osmomsc/osmomsc_init.sh && \ rm -f /mnt/osmomsc/sms.db* && \ cd /mnt/osmomsc && /bin/osmo-msc -c /etc/osmocom/osmo-msc.cfg Please help me to resolve the issue Mobiveil INC., CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain proprietary confidential or privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender and destroy all copies and the original message.

1 0

Assignment of 90170 MCC/MNC withdrawn by ITU.
by Robert Falkenberg 20 Jul '23

20 Jul '23

Hi all, this is some info for users of older Sysmocom SIM cards that came with IMSI prefix 90170. The ITU has withdrawn the assignment of the MCC/MNC 901/70, which was initially assigned to "Clementvale Baltic OÜ" back in 2020. Hence, the users of these SIM cards will no longer risk collisions with the public operator. (Newer cards as of 2020 come with an IMSI that starts with 99970 anyway.) Further reading: * https://en.wikipedia.org/wiki/Mobile_country_code#International_operators * https://www.itu.int/pub/T-SP-OB.1240-2022 Best regards Robert -- RobertFalkenberg Senior Engineer Software Radio Systems robert(a)srs.io <mailto:robert@srs.io> www.srs.io <//www.srs.io> Dortmund, Germany twitter <https://twitter.com/srssystems>

1 0

OsmoDevCall on Jul 17, 2023: Building wired cellular test setups
by Harald Welte 17 Jul '23

17 Jul '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: July 17, 2023 at 20:00 CEST where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @laforge will be presenting on Building wired test setups for mobile communications Particularly in lab and test setup involving cellular technology there is often a need for wired (coaxial) connection of cellular equipment, such as connecting a number of UEs (phones/modems) with one or multiple cellular base stations. For example, this is the only way to get defined power levels and test the actual transmit power or receive sensitivity of a device. The talk will cover how to build such test setups from parts like coaxial cabling, attenuators, RF splitter/combiners, duplexers, etc. This meeting will have the following schedule: 20:00 meet + greet 20:10 topic as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

code review
by Neels Hofmeyr 03 Jul '23

03 Jul '23

Hi community, I feel a bit frustrated by how code review is going recently at osmocom. Let me compare two larger feature branches: There are weeks of review on 19 patches in osmo-hnbgw/cnpool, and <24h from submit to merge on 14 patches in osmo-msc. That may in some situations be ok and justified, but I feel that it is not: The cnpool patch series for osmo-hnbgw spawned huge discussions and long delays on account of minor issues: log lines, event names and comments. I said so, yet it droned on and even spawned offspring. None of the important features was part of code review: larger design choices of the API, efficiency in handling the actual signalling, correctness of the signalling. Maybe that's because all those were mint perfect and no bugs anywhere, but I doubt that I'm really that good =) And at the same time I was "just now" asked to review some patches for osmo-msc, which changes an API that I have recently added and had ideas and reasons for. Before I get a chance to even glance, I see that all the patches are already merged! It is now basically too late to bring in my feedback, because the patches are in, and why spend more time on it. Suck it up, bygones. This very API that was being changed in osmo-msc in under 24 hours was itself under code review scrutiny for at least three years. Also I have (in my own free time) tried to get an improved logging timestamp into libosmocore. This is tagging along for years and years now, because every time over it is being blocked by minor details that are matters of taste. For years I lose precious moments every time i have to read an 'extended-timestamp' in osmo logging and identify the boundary of hours, minutes and seconds. This I consider important. AFAIR the reasons for blocking the patches were, objectively, all not important. These examples are starkly unbalanced. I'm sure you're aware of the bikeshed phenomenon -- it is a precise description of what is happening. It would be great if we could turn that around a bit? http://www.catb.org/jargon/html/B/bikeshedding.html Let's say, I know from experience that it is hard to give good code review, so count me in on this advice. Let's still give all the code review we can, but let's keep in mind the actual impact the particular code change has. If it goes in the "fringe detail" bucket, let's mention it, but just let it pass if the author disagrees. Hope you understand my frustration and maybe even agree. Thanks, ~N

2 2