OpenBSC

openbsc@lists.osmocom.org

11 participants
4172 discussions

by Mykola Shchetinin

Hello, It is about how I got a voice working between UE connected to Osmocom 3G (external call handling - Kamailio PBX) and VoIP softphone connected to the PBX. The part about is IuUP only. (Transcoding comes later) I have a traces of a call where a commercial NITB was used and I compared them to traces which I got from a call where Osmocom system was used. (Osmocom Core consisted of libosmocore of branch laforge/iu_up, osmo-mgw of branch neels/iuup and other stuff from Nightly Builds) My femtocell (nano3g ip.access) uses AMR 12.2k as a codec. The difference in IuUP <-> AMR conversion between two. When converting from IuUP to AMR: - Osmo-mgw only strips IuUP header from RTP payload; - Commercial NITB strips IuUP header and prepends AMR header to RTP payload; When converting from AMR to IuUP: - Osmo-mgw only prepends IuUP header to RTP payload; - Commercial NITB strips AMR header and prepends IuUP header to RTP payload; So that means basically that my femtocell sends AMR payload as IuUP payload without AMR header. And expects AMR payload inside IuUP message without AMR header. IuUP header is 4 bytes. AMR header for octet-aligned mode is 2 bytes. To test this I've modified the code of iuup_cn_node.c so that it does: - when converting from IuUP data (rx_data): after stripping IuUP header it prepends 0xf03c as a header (it is for AMR 12.2k). - when converting to IuUP data (osmo_iuup_cn_tx_payload): before prepending IuUP header it strips AMR header. The call performed had voice on both sides. It was performed between a regular phone connected to a femtocell and a VoIP softphone connected to Kamailio PBX. Kind regards, Mykola

6 years, 8 months

3G Working Setup

by Ron

Hi Community, Does anyone successfully run a 3G network using OSMOCOM elements? Currently we are trying to run the following OSMO elements using this URL "https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…. Instead of using a 3G femto cell as HnodeB, does anyone tried to use UMTRX, B210, and LimeSDR? Is there other software that will act as HnodeB between the SDR and OSMOHNBGW? TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

6 years, 8 months

nano3g ip.access femtocells and transcoding

by Mykola Shchetinin

Dear Osmocom community, Did somebody try to use nano3g ip.access femtocells and Osmocom system with external call handling? What I am trying to do is to make calls work between VoIP phones connected to PBX and UEs connected to Osmocom system. I've tried two PBXs: Kamailio with rtpengine and Asterisk. Signalling worked good between VoIP phone and UE with both PBXs; calls between two UEs registered on Osmocom system worked good also... But I fail to do transcoding (calls between VoIP phone and UE). The problem is that it is unknown which codec is used by nano3g ip.access femtocell. So, the question is: Do you know what codecs were used for speech in your setup with nano3g ip.access femtocells? Or do you know how to find out that information? (It was stated by ip.access that they use AMR but I failed to match AMR specs with RTP payload that was sent by femtocell...). I would be very grateful for any ideas. Kind regards, Mykola

6 years, 8 months

switched to gerrit +3, some ideas

by Neels Hofmeyr

There are obvious problems with the current +3 enforcing scheme on gerrit. a) if a patch has +2, the summary shows a tick mark, you don't see that another +1 is needed. b) if a patch has three +1s, the summary shows +1, you don't see that it can be merged. c) voting +1 for an own patch has an effect on the mergability. Ideas to improve: a) +2 hides missing +1 On IRC, we agreed that it is a good idea to require two reviews (by two people) -- three is too much. Currently that would be one +2 vote plus one +1 vote. (alternatively 3x +1, too). Idea: if we remove the "+2" ability, we avoid the problem that a +2 hides the missing +1. Everyone has only +1 votes, and we add up using that plugin. To require only two reviews, we merge once a sum of +2 is reached. b) 3x +1 == "+1" There's no solution short of fixing what gerrit shows in the summary. Everyone will still click on the patch and then see that it already has three votes. c) +1 to self The solution is that you don't vote for your own patches, unless it is really super trivial and not worth wasting others' review time on. Let's see for a few days how we fare with these quirks. ~N

6 years, 8 months

Re: Build failed in Jenkins: master-osmo-sgsn » --disable-iu,1,a3=default,a4=default,osmocom-master-debian9 #7511

by Neels Hofmeyr

Created issue OS#3736 for this. Let's collect failing build details there. ~N

6 years, 8 months

OT: owning a sysmoBTS we could use for 35c3?

by Neels Hofmeyr

Hi, if anyone owns a sysmoBTS and either comes to 35c3 or can easily pass it on: can we use your sysmoBTS for the GSM installation, please? They will get insured by the event, we just need the serial number(s). I might also ask you personally later this week / at sysmocom office. Thanks! ~N

6 years, 8 months

build slave segfaults

by Neels Hofmeyr

I see sporadic segfaults during jenkins builds every now and then... Let's keep an eye on it. This one built on build2-deb9build-ansible ~N On Wed, Dec 12, 2018 at 12:52:59AM +0000, jenkins(a)lists.osmocom.org wrote: > See <https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/IU=--enable-iu,WITH…> > ... > CC auth_milenage.lo > /bin/bash: line 2: 6091 Segmentation fault (core dumped) /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -I/usr/include/p11-kit-1 -DBUILDING_LIBOSMOCORE -Wall -Wall -g -O2 -DBUILDING_LIBOSMOCORE -Wall -MT auth_milenage.lo -MD -MP -MF $depbase.Tpo -c -o auth_milenage.lo auth_milenage.c > make[3]: *** [auth_milenage.lo] Error 139 > Makefile:582: recipe for target 'auth_milenage.lo' failed > make[3]: *** Waiting for unfinished jobs.... > make[3]: Leaving directory '/build/deps/libosmocore/src/gsm'

6 years, 8 months

Re: Build failed in Jenkins: master-osmo-pcu » origin/nrw/litecell15,0,osmocom-master-debian9,lc15,True #1068

by Neels Hofmeyr

whoops, another one On Wed, Dec 12, 2018 at 01:22:09PM +0000, jenkins(a)lists.osmocom.org wrote: > make[1]: Entering directory '<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…'> > CXX gprs_debug.lo > CXX csn1.lo > CXX gsm_rlcmac.lo > CXX gprs_bssgp_pcu.lo > CXX gprs_rlcmac.lo > CXX gprs_rlcmac_sched.lo > CXX gprs_rlcmac_meas.lo > CXX gprs_rlcmac_ts_alloc.lo > gprs_bssgp_pcu.cpp:982:2: warning: #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" [-Wcpp] > #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" > ^~~~~~~ > CXX gprs_ms.lo > CXX gprs_ms_storage.lo > CXX gsm_timer.lo > CXX pcu_l1_if.lo > CC pcu_vty.lo > CXX pcu_vty_functions.lo > CC mslot_class.lo > CXX tbf.lo > CXX tbf_ul.lo > CXX tbf_dl.lo > /bin/bash: line 2: 9155 Segmentation fault /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"osmo-pcu\" -DPACKAGE_TARNAME=\"osmo-pcu\" -DPACKAGE_VERSION=\"0.5.1.38-5b52\" -DPACKAGE_STRING=\"osmo-pcu\ 0.5.1.38-5b52\" -DPACKAGE_BUGREPORT=\"osmocom-net-gprs(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"osmo-pcu\" -DVERSION=\"0.5.1.38-5b52\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 -I. -I../include -Wall -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -fno-strict-aliasing -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -DENABLE_DIRECT_PHY -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -I./osmo-bts-litecell15 -Wall -ldl -pthread -g -O2 -MT tbf_ul.lo -MD -MP -MF $depbase.Tpo -c -o tbf_ul.lo tbf_ul.cpp > Makefile:779: recipe for target 'tbf_ul.lo' failed > make[1]: *** [tbf_ul.lo] Error 139 > make[1]: *** Waiting for unfinished jobs.... > make[1]: Leaving directory '<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…'> > Makefile:466: recipe for target 'all-recursive' failed > make: *** [all-recursive] Error 1 > Build step 'Execute shell' marked build as failure > [WARNINGS]Skipping publisher since build result is FAILURE -- - 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

6 years, 8 months

vty expect script

by Neels Hofmeyr

Hi Keith, I'm now using your vty expect script from https://gerrit.osmocom.org/#/c/osmo-dev/+/11811/ in our congress gsmcore setup, and I absolutely love it! I tweaked the logging, and next to it I also put vty_sticky, which re-opens the vty when the program gets restarted. Attached my current versions. Such a simple and nice way to customize logging, easily attach and detach, quickly change some log levels... much simpler than navigating journalctl. Thanks for that! ~N

6 years, 8 months

voting in gerrit: merge at +3? (+2+1 / +1+1+1)

by Stefan Sperling

There has been some face-to-face discussion about Osmocom's code review process within sysmocom recently. I am posting to this list now with the consent of everyone involved so far, in order to involve the Osmocom community at large in this discussion as well. There has been a lack of code review from people who don't have "+2" super powers in Gerrit. This applies to anyone among us, independently of any individual's relationship with sysmocom. The bulk of the work involved in reviewing code falls on Harald's shoulders, with Pau and Neels sharing most of the rest between themselves. At present, while people who add a +1 have their voices heard, their input does not formally affect the decision to merge a change. A change still has to pass by the pre-selected +2 gatekeepers in order to be merged, no matter how many other people have provided input. The implication for developers without +2 powers is that their time is more effectively spent on advancing their own changes towards a +2 vote, rather than spending time on whatever else is waiting in Gerrit. This may not apply to everyone, of course. But at least for me, this is certainly the case; I have only been reviewing other people's patches when I was explicitly asked to do so. Myself and several other developers hope that with a change to our review process we can fix this inertia, spread code review across more shoulders and encourage more collaborative code review in Osmocom. The basic idea is that everyone's input should count for something. If those among us with +1 powers were given a partial say on the fate of every change, our decisions will carry more weight and our influence within the project will slightly increase. We'd also be encouraged to step out of our own corners of expertise every now and then, and look at what other developers are working on. On the flip side, this means we'd carry more responsibility than we do now. We wouldn't always be relying on our +2 gate keepers and would have to apply our own judgement more carefully. The concrete proposal is to make votes in Gerrit accumulative. Each change would require a total score of +3 to be merged. This score can consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes. Also, +2 developers would keep their ability to unilaterally block or revert changes under this new model. They'd keep their existing role as arbiters in case of disputes. Max figured out how Gerrit could be configured for this behaviour. It involves Prolog code, but since we're all quite smart we should be able to figure that out, right? https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_… We'd be interested to hear what the community thinks about this proposal. Thanks, Stefan

6 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC