Update on my GSM network setup

Wed Jul 6 04:52:17 UTC 2022

Hello FC community,

I've been quiet here lately, so it's time for another update on my
work with GSM.  I am still working on improving my toy GSM network at
home, making it feel more real - the big objective toward which I am
still working is interconnection with USA PSTN.  I am currently
experimenting with using bulkvs.com as my PSTN-via-SIP connectivity
provider, and here is my current status:

* I successfully allocated (bought? rented?) a block of 10 real phone
numbers in the North American Numbering Plan from this provider.  I
was able to choose an NPA-NXX prefix of my desired locality, and it
appears that a customer located anywhere in USA can get phone numbers
that are geolocated in any other part of this big country, basically
you pick whichever NPA-NXX you like, subject to availability - old
concepts of "local call" vs "long distance" are now meaningless, all
of USA is now essentially one flat locality for phone number purposes.

* Whenever any of my allocated numbers receives an incoming call from
anywhere on the global PSTN, bulkvs servers send UDP SIP INVITE packets
to my server - I am making use of my recently installed Cox business
Internet connection with a real, non-NAT static IP address.

The remaining work is all software, and here is where I am venturing
into innovative territory.  For connecting voice calls between an
Osmocom GSM network and "something external", Osmocom's official
offering is osmo-sip-connector - except that it is not designed to
connect directly to PSTN-via-SIP trunk services like bulkvs, instead
it is designed to connect to a locally run PBX like Asterisk or
FreeSwitch.  In simple terms, osmo-sip-connector is not a switch: when
it handles an MO (mobile-originated) call, it doesn't have intelligence
to look at the dialed number and decide whether to send the call back
to GSM (calling another local subscriber) or to route it to the outside
PSTN connection interface, instead it expects a separate PBX setup to
do this work, with every local GSM-to-GSM call going to SIP, to the
SIP-based PBX and then back to GSM.  But I don't like this approach:

* In the case of GSM-to-GSM calls, from one local GSM subscriber to
another, I would like to handle them entirely in the land of GSM call
control protocols (MNCC), without ever going to SIP.

* Both Asterisk and FreeSwitch feel too intimidating and off-putting
to me, in terms of size, complexity and learning curve.  While there
certainly exist many many applications where all that sw complexity is
really needed, I feel that my application isn't one of them.  If all I
seek to implement is a simple interconnection between a GSM network
and PSTN, an interconnection that is as direct and not-altering-anything
as possible, then I feel that a PBX isn't the right software for the
job.

Based on this reasoning, instead of using osmo-sip-connector plus
either Asterisk or FreeSwitch, I am putting together my own software
suite:

https://www.freecalypso.org/hg/themwi-system-sw/

I already have my own daemon process (themwi-mncc) connecting to
OsmoMSC's MNCC socket and switching local calls, from one GSM
subscriber to another, and this themwi-mncc provides further hooks
(via UNIX domain sockets) for routing external calls into and out of
the system.

I have also dumped the UDP packets (SIP INVITEs) which bulkvs servers
send to my server whenever someone calls one of my phone numbers, and
here is an example of what I get in the SDP:

v=0
o=- 2702746444 649696 IN IP4 74.120.93.30
s=-
c=IN IP4 74.120.93.30
t=0 0
m=audio 52560 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

We can see from this SDP that this PSTN-via-SIP service accepts G.711
(both PCMU and PCMA) and G,729 as codec choices, but no GSM codecs:
no GSM 06.10, no AMR, not any of the others.  Therefore, unless I am
missing something big here, in order to make an interconnection between
this PSTN-via-SIP trunk and an Osmocom GSM network, I will need to
implement my own RTP bridge MGW (media gateway) that transcodes between
G.711 on the Internet-to-PSTN side and GSM codecs (FR1, EFR, AMR) on
the GSM side.  Osmocom's MGW, called OsmoMGW (what else?), does NOT
implement such transcoding.

I don't know whether or not such a transcoding RTP MGW implementation
already exists somewhere in the bowels of Asterisk or FreeSwitch - the
size and complexity of both of those sw offerings makes it difficult
to investigate even a basic question like this one.  But after studying
this problem of transcoding, I decided to make a shot at my own
implementation.  I am thinking of a simplistic implementation without
timing complications: a simple, non-timing (infinite wait) select loop
that waits for RTP packets to arrive from either side, and whenever an
RTP packet arrives, transcode it and send it out the other side.  The
downside is that whenever the RTP stream on either side pauses
(presumably because the speaker on that end is silent), the effect of
the simplistic transcoding MGW will be immediate cessation of RTP
packets to the other side, as opposed to more intelligent handling with
graceful silence detection, comfort noise generation etc.  I reason
that by professional telephony standards such simplistic transcoding
MGW will probably be subpar, but I have to start somewhere, and the
presumably-proper approach of making my MGW timing-aware looks very
daunting.

As far as the choice between different codecs on the GSM side, my
current plan is to support FR1 and EFR initially, but not AMR.  This
choice is the direct opposite of what I heard was done in setups like
CCC - according to what I heard, they supported only AMR and no older
codecs.  My reasons are:

* There are plenty of old phones that predate AMR: even within Calypso
realm, earlier versions of Calypso silicon (up to C05 rev B, before
C035) lack AMR support, and we have a real TI D-Sample board of this
pre-AMR Calypso C05 vintage.  And of course 1990s phones of pre-Calypso
era also lack AMR.

* Given how much work it is to implement everything I desire, I have
to start small and downscope my first implementation.  If I am going
to support only some of ultimately-desired codecs rather than all of
them upfront, it makes sense to start with older ones.

* My timeslot configuration is all FR channels, no half-rate: there is
simply no need for HR channels when there is absolutely no way I will
ever find enough users to fill my single GSM cell with 6 simultaneously
active call legs.  In terms of the actual codec, the highest mode of
AMR-FR is identical to EFR, hence there is no voice quality advantage
with AMR over EFR, at least as long as the test phone stays inside the
house with the BTS, with super-strong radio signal as a result.

* In the case of GSM-to-GSM calls (as opposed to GSM-to-PSTN or
PSTN-to-GSM, where my themwi-mgw will have to transcode everything to
G.711), there is no current support in Osmocom for handling codec
mismatches between call legs.  Given that some of my test phones
support AMR while others don't, configuring the network to select AMR
when the MS supports it will cause problems in this department.

Interestingly enough, I have not yet found a phone that supports only
FR1 but not EFR.  Of the two 1990s phones in my collection, Ericsson
I888 and Nokia 5190, both support FR1 and EFR - but no HR1 and no AMR.
There was a poster on the openbsc ML just recently who got an old phone
(Siemens S11E) that supports FR1 only, but it's an EU band only model -
gsmarena.com says it's DCS1800 only.  I don't know whether or not
anyone ever made a PCS1900 band GSM phone without EFR support - maybe
such models did exist once, but I haven't found one yet.

And yes, I got a second working 1990s phone in my collection: my first
is the awesome Ericsson I888, described in my previous post a month
ago, but now I also have a working Nokia 5190 - it's a classic DCT3
phone, PCS1900 band equivalent of 5110, which Wikipedia says is mostly
the same as 6110, supposedly the very first GSM phone with an ARM
processor!  This ARM processor is MAD (or is it MAD2?), it was made
for Nokia by TI, and as I understand it, it was TI's initial entry
into the world of GSM - beginning their GSM Skunkworks business which
eventually led to our dear Calypso.

Right now my plan going forward is to do more work on my home GSM
network before going back to the original FreeCalypso project.  I need
to get voice calls to and from PSTN working, and I will also need to
develop a setup for SMS testing.  When it comes to SMS, for the initial
version I am willing to downscope and omit outside SMS connectivity:
IOW, have SMS working from one local GSM phone to another, from a
command line sender to phones, and from phones to a test destination
that logs to a file, but no SMS from or to the outside world.  I am
thinking of such downscoping for cost reasons: I am not interested in
A2P SMS, and AFAICT there aren't any ultra-low-cost options for P2P
SMS, nothing that can compare in terms of cost with voice-only phone
numbers from bulkvs - and because this network of mine is currently
first and foremost for phone testing and "oooh and ahhh" demos to
gathered audiences, certain non-essential features can be omitted in
the first version, to reduce both operating cost and sw development
effort.

Once I have this home GSM network working to my satisfaction, I will
then go back to my earlier idea of producing my long-desired FC Venus
development board.  Having our own GSM network for testing will
insulate the FC Venus board project, including aspects like voice
quality testing, from vicissitudes of T-Mobile and their anti-2G
stance.

Hasta la Victoria, Siempre,
Mychaela aka The Mother