19 Apr
2022
19 Apr
'22
11:12 a.m.
Hello Osmocom CNI folks,
I got my first GSM network up and running, using nanoBTS hardware and
Osmocom CNI sw stack. I compiled everything from source (to my
knowledge, no one makes binary packages for Slackware), but rather
than grabbing the state of git master on some random day, I checked
out tagged versions corresponding to the latest official 2021-11 CNI
release. My configuration is 2G-only, CS-only, minimal split-NITB,
thus the 5 processes I am running are OsmoSTP, OsmoHLR, OsmoMGW,
OsmoMSC and OsmoBSC. I'm using the same OsmoMGW instance for both MSC
and BSC.
The functional state is: phones with FCSIM1 cards in them whose
programming matches the data I entered into HLR are able to connect
(location update succeeds), SMS from one phone to another works, and
USSD requests *#100# and *#101# also work. However, voice calls don't
work. The user-visible symptoms are:
1) When I dial a call from one connected phone to another, the
destination phone starts ringing, and it shows the calling number on
the display - thus CC signaling works correctly at least in the
initial phases.
2) However, a short time (I measured a little under 20 s) after the
start of the process, the destination phone stops ringing and shows a
missed call indication. However, the origin phone continues playing
its NOIBT ringing tone as if it is still waiting for the call to be
answered, and it keeps going for another 15-20 s or so, before it
gives up.
3) Trying to press the answer button on the destination phone before
it stops ringing and goes into the "missed call" state does NOT
produce a connected call state either.
To see what's going on, I turned on maximum verbosity logging in all
OsmoCNI components and plowed through the resulting massive log.
(I am logging via syslog - the whole point of running Slackware is
principled opposition to systemd.) And I see what appears to be the
culprit - see lines 7558 and 7559 in the attached log, UTC timestamp
02:48:54, 11 seconds after I initiated the test call from the origin
phone. It appears that the BTS is telling the BSC that this error
occurred: "Timer T200 expired (N200+1) times", and based on the
lchan(0-0-2-TCH_F-0) annotation, this error is happening on the origin
leg of the call, rather than the destination leg.
I looked up what T200 is:
https://www.rfwireless-world.com/Terminology/GSM-timers.html
T200: "It is used as retransmission on data link layer. Value varies
depending on different messages (for FACCH it is set to 155ms)"
Why in the world are FACCH (or is it SACCH?) data link transmissions
suddenly failing on the origin leg of the call, some 11 to 13 seconds
in? I have tried 4 different phones in the call-origin role (Motorola
C139 running its original fw, Pirelli DP-L10 likewise, Nokia C3-00 and
my own FreeCalypso fw), and the behaviour is always the same.
Has anyone seen this problem before? Is it perhaps a known issue with
nanoBTS that requires some special workaround? This tarball:
https://www.freecalypso.org/members/falcon/osmo-cni/t200-fail-config+log.ta…
contains my configuration files for all 5 OsmoCNI components and an
excerpt from syslog. The syslog excerpt begins with all 5 OsmoCNI
components booting up, followed by two phones connecting, and finally
the test call.
I would really appreciate it if someone could give me some pointers
for debugging this voice call show-stopper.
TIA,
Mychaela