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.tar...
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