OpenBSC

openbsc@lists.osmocom.org

6 participants
4179 discussions

by SADANAND VISHWAS

Hello, I was going through libosmo-abis codebase to understand how it handles “Rtp to Trau” and vice-versa GSM-EFR conversions. I was able to find “RTP to Trau” and “Trau to Rtp” conversion code of EFR speech frames, but could not find anything related to EFR SID (silence) frames. can you please guide me if above is already present in the library or how can we implement it? Thanks, Sadanand Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

2 years, 6 months

Seeking pcap of RTP stream from nanoBTS

by Mychaela Falconia

Hello GSM community, Would anyone in either of the two sub-communities of GSM (OsmoCNI and FC) happen to have a working setup with an ip.access nanoBTS, specifically with working voice calls? For the purpose of this inquiry, that "working setup" can be either with Osmocom CNI sw or with whatever original proprietary sw was once "official" for these ip.access nanoBTS units. If anyone does have a working nanoBTS setup with any sw, would you be willing to produce and share a packet capture (pcap file) of a working voice call, particularly the RTP stream originating from the nanoBTS? I am particularly interested in seeing a nanoBTS-generated RTP stream in either FR1 or EFR codec, as opposed to AMR or HR, coming from a GSM call UL with DTX enabled - having a 'dtx uplink' line in OsmoBSC config under 'bts N' should do it. The reason for my interest? I am looking to see what the pre-existing (before Osmocom) implementation of GSM-UL-to-RTP conversion in nanoBTS does in the two corner cases of (1) the MS exercising DTX during speech pauses and (2) speech frame 20 ms windows on TCH UL being stolen for FACCH. In case 1, does nanoBTS produce an intentional gap in its transmitted RTP stream (no packets sent at all) like OsmoBTS does, or does it do something different? Does it perhaps send RTP packets with zero-length payload, or some in-band bit pattern that is meant to indicate "bad frame, no data"? Case 2 is also interesting: current osmo-bts-trx (based on my reading of code, no hw to test on) invokes FR1 ECU and emits its output in this case, whereas stock (without my hacky patches) osmo-bts-sysmo exhibits an outright bug whereby nothing is emitted on RTP during the FACCH-stolen 20 ms window, and that gap in the RTP stream is NOT accounted for in the timestamps of subsequent RTP packets. Once again, I can only wonder what the pre-Osmocom implementation in nanoBTS does in this case. I would really like to produce a clean, potentially-mergeable patch to OsmoBTS and submit it to Gerrit, a patch that would add vty config settings selecting among several possible behaviours for RTP output in cases of DTX silence, FACCH stealing or bad radio Rx - but I really need to know what the different "reasonable" behaviour choices are, and I feel that we as in FOSS GSM community also need to know what our proprietary predecessors did in this area. I am not able to test this nanoBTS behaviour myself because even though I have nanoBTS hw (one PCS1900 unit and one GSM850), I have had no success in getting it to work with Osmocom - and my troubleshooting attempts hit a brick wall when the misbehaviour appears to be somewhere in the proprietary black box of nanoBTS. Hence I really need help from someone in the community who does have a working nanoBTS setup (with any sw) and who could make some test voice calls (ideally one FR1 and one EFR, but even just one of these two codecs would be interesting to see) with an RTP packet capture running, and then share the resulting pcap file. During that test voice call, it would be ideal if the tester could alternate between speaking and silence, and also cause some FACCH activity, perhaps by pressing DTMF keys. M~

2 years, 6 months

ttcn3-bts-test regressions

by Vadim Yanitskiy

Hi all, I was planning to do this long time ago, but somehow kept leaving this for later. Today I revisited the state of ttcn3-bts-test, which shows quite a few regressions. I believe they need to be investigated and eventually fixed, so I created several tickets for tracking these regressions in Osmocom's Redmine: * OS#5951: TC_early_immediate_assignment, * OS#5952: TC_ho_physical_info, * OS#5953: TC_ms_pwr_ctrl_{constant,pf_ewma}, * OS#5954: TC_pcu_data_ind_lqual_cb, * OS#5955: TC_pcu_[ext_]rach_content, TC_pcu_ptcch, * OS#5956: TC_rsl_rf_resource_ind. The following tickets already existed prior to my checkup: * OS#4023: TC_pcu_oml_alert, * OS#5242: TC_ipa_crcx_ack_addr, * OS#5517: TC_tx_power_ramp_adm_state_change. So far this is all about non-hopping configuration: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… The freq. hopping configuration exhibits slightly more red TCs: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… 92% vs 84% passing TCs to be precise, but this is kinda expected because of the limitations we have in fake_trx: FAKE_* CTRL commands are applied to just one transceiver, not affecting others, which are also part of the Mobile Allocation. Mostly the meas related TCs are affected. The following TC groups are quite stable and mostly all green: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… The following two TC groups have never been stable/all green, AFAICT: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… We may want to create more tickets for those, maybe less granular (i.e. one ticket per group). I am not familiar with these two TC groups, so would be nice to get some input from those who write them. What would it take to get them fixed? Are there any tickets already? If could not find any, but I only did a quick search. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at 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

2 years, 6 months

OsmoDevCall on Mar 15, 2023: Circuit Switched Data (CSD) in GSM

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: March 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @laforge be presenting on Long range communications in the HF band CSD is the mechanism by which circuit-switched data calls can be made over classic GSM/2G (and later also UMTS/3G) networks. They resembled the modem call of circuit-switched networks, but of course no voiceband modem is involved. For more information, see our CSD wiki page at https://osmocom.org/projects/cellular-infrastructure/wiki/CSD This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation 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 years, 6 months

Play RTP packets payload obtained from the mobile phone in a call service

by morteza ali Ahmadi

Hi, I have developed a UMTS core network using a home nodeB (HNB) which the mobile phones (or UEs) can register on my network and get the required services such as call service. I have implemented all the required procedures for call service and I can establish a successful call for my connected UEs. In one of the most important procedures, i.e **Call Proceeding**, I have identified the coding of speech transferred between UEs and core. Here is my coding options (in wireshark): GSM A-I/F DTAP - Call Proceeding Protocol Discriminator: Call Control; call related SS messages (3) .... 0011 = Protocol discriminator: Call Control; call related SS messages (0x3) 1... .... = TI flag: allocated by receiver .000 .... = TIO: 0 00.. .... = Sequence number: 0 ..00 0010 = DTAP Call Control Message Type: Call Proceeding (0x02) Bearer Capability 1 - (Spare) Element ID: 0x04 Length: 6 Octet 3 0... .... = Extension: Extended .11. .... = Radio channel requirement: Spare ...0 .... = Coding standard: GSM standardized coding .... 0... = Transfer mode: circuit .... .000 = Information transfer capability: Speech (0x0) Octets 3a - Speech Versions 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2) 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 1000 = Speech version indication: GSM full rate speech version 5(FR AMR-WB) (0x8) 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4) 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5) 1... .... = Extension: No Extension .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1) So I can see the RTP packets transferred between UE and core. An instance is mentioned here (in wireshark): Real-Time Transport Protocol [Stream setup by RANAP (frame 2950)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 .... = Extension: False .... 0000 = Contributing source identifiers count: 0 0... .... = Marker: False Payload type: DynamicRTP-Type-96 (96) Sequence number: 56611 [Extended sequence number: 56611] Timestamp: 424448575 Synchronization Source identifier: 0x5c260101 (1545994497) RFC 2198: Redundant Audio Data Header 1: PT=ITU-T G.728 0... .... = Follow: Not set .000 1111 = Payload type: ITU-T G.728 (15) Payload: 0028ba44776b3eee7a050039cdaa521cc20ac08d2bcf1818… I have aggregated all RTP packets payload. How can I convert the aggregated bytes to a hearable audio? -- *When there is much light, The shadow is deep...*

2 years, 7 months

Extract and parsing TCAP + CAP parts from SCCP messages

by Hadi Rezaee

Hello there, I was wondering if there is any snippet or sample code for extracting TCAP and then CAP parts from SCCP messages. So, What I've done so far was to connect to SG system as a client and called to 'osmo_sccp_user_bind' function to catch SCCP message: osmo_sccp_user_bind(sccp, 0, handle_sccp_msg, NULL); . . . int handle_sccp_message(struct osmo_prim_hdr *oph, void *ctx) { struct osmo_scu_prim *scu_prim = (struct osmo_scu_prim *)oph; struct osmo_sccp_user *scu = ctx; struct gsm_subscriber_connection *conn; int rc = 0; switch (OSMO_PRIM_HDR(&scu_prim->oph)) { case OSMO_PRIM(OSMO_SCU_PRIM_N_UNITDATA, PRIM_OP_INDICATION): // TCAP parsing ?! break; default: break; } return rc; } Thanks

2 years, 7 months

A new GSM codec libraries and utilities package

by Mychaela Falconia

Hello GSM community, I am pleased to announce the first release of Themyscira GSM codec libraries and utilities package: ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-r1.tar.bz2 The two principal libraries contained in this package, libgsmefr and libgsmfrp, continue the tradition that was started back in 1990s with the first release of libgsm, a Unix-oriented, C-library-embodied, Free Software implementation of GSM 06.10 speech transcoder. The original libgsm was written and released long before anyone in the hacker community even dreamed of running their own GSM network or building their own GSM MS, but it is now used somewhere deep under the hood (under lots of higher layers) by every GSM network-side implementation that includes an RTP transcoding gateway to other voice networks, activated whenever a GSM voice call is connected using good old FR codec rather than AMR, and is likewise used for the same purpose by anyone seeking to achieve working voice in an SDR-based GSM MS implementation. The present gsm-codec-lib release - a public works project of the Women's Republic of Themyscira - continues in the spirit of libgsm by offering two more similar libraries: 1) libgsmefr is a librified (turned into a library) version of the EFR reference code from ETSI, with all state variables converted from global vars into proper state structures, and with additional code clean-up to make it function as a speech encoder and decoder library on the same principle as libgsm, but for EFR codec instead of FR1. All beyond-speech functions of the original EFR reference code (VAD, DTX, comfort noise, error concealment) are included in libgsmefr, allowing this library to be used to implement a *proper* speech transcoder for GSM-EFR voice service. I have previously noted that the general trend in the FOSS GSM community is to use the popular AMR library libopencore-amrnb not only for AMR, but also for EFR. However, this approach is incorrect: the SID and comfort noise mechanism of EFR is different from AMR, and if you feed the uplink of a GSM-EFR call, containing SIDs and BFI skipped frames, to libopencore-amrnb decoder, there will be strange noises in the output in places where the GSM MS sent SID. Decoding EFR from a GSM call uplink requires a proper EFR library, not AMR, and I wasn't able to find any workable pre-existing implementation prior to producing Themyscira libgsmefr. 2) libgsmfrp is a preprocessor intended to be called prior to gsm_decode() from libgsm, implementing Rx DTX handler functions of GSM 06.11, 06.12 and 06.31. This preprocessor is required for anyone seeking to implement GSM FR service in the traditional way depicted in Figure 1 in 3GPP TS 46.001, as opposed to the "cut corners" way that seems to be favored in the land of Osmocom. When used as part of GSM network deployment, as opposed to lab experimentation on the mobile side of GSM, the two just-released Themyscira libraries work best together with this patch to osmo-bts: https://www.freecalypso.org/hg/themwi-system-sw/file/tip/osmo-patches/osmo-… implementing this extension to RTP transport format: https://www.freecalypso.org/hg/themwi-system-sw/file/tip/doc/RTP-BFI-extens… The "go along to get along" community appears to operate on a consensus that the RTP stream should be paused when the uplink is in DTX, or when a traffic frame was stolen for FACCH or lost to radio errors - but I disagree with that approach, and instead operate my GSM network on the principle of sending an RTP packet in *every* 20 ms slot, be it rain or shine. In the "consensus" approach the speech decoding path in the transcoding MGW never executes at all during frame stream pauses (when no RTP packets are sent), but in my "traditionalist" approach (mimicking the ways of TDM) that decoding function does get called every 20 ms, and it must produce *some* output toward PSTN in every 20 ms window, whether the MS was transmitting or not, and whether this MS output was received or lost. The Rx DTX handler becomes essential in such operation: when there is no speech traffic from the MS, libgsmfrp fills in comfort noise or previous speech frame substitution and muting as appropriate per the rules of GSM 06.31. In the case of EFR this functionality is integral to the original reference code from ETSI and thus appears in libgsmefr, but in the case of FR1 codec this functionality takes the form of a preprocessor, implemented in libgsmfrp. In any case, the two newly released libraries are intended to sit on the same "rank" in the software integration hierarchy as classic libgsm from 1990s, and higher-level projects by various parties should feel free to use them in the same manner how they currently use libgsm and libopencore-amrnb. I encourage gapk and various people's transcoding MGW implementations to take advantages of these newly available production quality GSM codec libraries. With devotion to GSM Forever, (Hasta la Victoria, Siempre,) Mother Mychaela

2 years, 7 months

SCCP RLC

by Neels Hofmeyr

I'm trying to clean up the connection management in osmo-hnbgw. For that purpose I'd like to be notified of the SCCP RLC message: I'd like to free a HNB-to-CN / RUA-to-SCCP context mapping when the SCCP local reference becomes invalid. I kind of thought I would receive a OSMO_SCU_PRIM_N_DISCONNECT PRIM_OP_CONFIRM up the user_sap, but that's not happening. I see the SCCP RLC logged like this: 20230216042453894 DLSS7 DEBUG 0: asp-asp-clnt-OsmoHNBGW: xua_cli_read_cb(): sctp_recvmsg() returned 40 (flags=0x80) (osmo_ss7.c:1906) 20230216042453894 DLM3UA DEBUG 0: asp-asp-clnt-OsmoHNBGW: Received M3UA Message (XFER:DATA) (m3ua.c:714) 20230216042453894 DLM3UA DEBUG 0: asp-asp-clnt-OsmoHNBGW: m3ua_rx_xfer (m3ua.c:543) 20230216042453894 DLM3UA DEBUG 0: asp-asp-clnt-OsmoHNBGW: m3ua_rx_xfer(): M3UA data header: opc=188=0.23.4 dpc=189=0.23.5 (m3ua.c:566) 20230216042453894 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=189=0.23.5 as local (osmo_ss7_hmrt.c:276) 20230216042453894 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:RELCO,V=0,LEN=0), PART(T=Destination Reference,L=4,D=000003f0), PART(T=Source Reference,L=4,D=0073dcf0) (sccp_scrc.c:472) 20230216042453894 DLSCCP DEBUG Received CO:RELCO for local reference 1008 (sccp_scoc.c:1799) 20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{DISCONN_PEND}: Received Event RCOC-RELEASE_COMPLETE.ind (sccp_scoc.c:1833) 20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{DISCONN_PEND}: state_chg to IDLE (sccp_scoc.c:1309) 20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{IDLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST) (sccp_scoc.c:539) 20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{IDLE}: Freeing instance (sccp_scoc.c:539) 20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{IDLE}: Deallocated (fsm.c:568) but nothing arrives at sccp_sap_up() in hnbgw_cn.c Is my idea flawed somehow, or is the prim dispatch missing in libosmo-sigtran? Thanks! ~N

2 years, 7 months

OsmoDevCall on Feb 15, 2023: Long range communications in the HF band

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: February 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall This time, @rafael2kwill be presenting on Long range communications in the HF band This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation 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 years, 8 months

Card initialization failed with exception

by bhogendra.rao＠gmail.com

Hi all I am new bee into pysim and python too. I have successfully installed all dependenceis and my code start running. I was too delighted and connected my card reader and ran the following command $python4 pySim-read.py -p 0 and the responce is like below. qt5ct: using qt5ct plugin Using PC/SC reader interface Card reader initialization failed with exception: Exception was not showing any reason for failure but an empty string. Can someone please help me

2 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC