Themyscira Wireless update

[Mychaela Falconia]

Hello FC community,

My Themyscira Wireless network setup is progressing along.  The GSM
part is still mostly unchanged Osmocom CNI sw driving a sysmoBTS, but
my own add-on software that connects it to USA PSTN via a SIP trunk is
progressing quite well.  Since my previous update, I now have both
inbound and outbound calls working - inbound means calls placed from
anywhere in the world to one of my allocated +1 numbers, and outbound
means calls made from a ThemWi GSM phone to any phone number in USA.
No international outbound yet - I don't have anyone outside of USA to
talk to currently, hence I haven't bothered with researching service
providers for SIP to international PSTN, comparing prices etc.

Also as a new development since my previous update, these working
inbound and outbound calls also include a working voice path!  In
terms of technical implementation, my gateway between Osmocom-based
GSM and SIP-accessed PSTN is divided into 3 separate daemon processes:

* themwi-sip-in receives inbound SIP calls and connects them through
to the GSM network, passing through themwi-mncc (see below) and onward
to OsmoMSC.

* themwi-sip-out receives outbound calls that originate from GSM phones
(passing through OsmoMSC and themwi-mncc) and converts them into SIP
outbound calls, going to the configured SIP destination - this is the
component where international routing to different country codes could
be configured, as well as mapping of special numbers like N11.

* themwi-mgw handles the voice traffic plane (RTP) for both PSTN to GSM
and GSM to PSTN calls.  Both themwi-sip-in and themwi-sip-out connect
to and control themwi-mgw through an hoc internal protocol.

There is also a fourth daemon process themwi-mncc, but I don't count
it as part of the gateway because it goes together with OsmoMSC, not
with any of the gateway processes.  If themwi-mncc is up while all
other just-named processes are down, internal calls from one ThemWi
GSM phone to another will continue to work just fine, switched by
themwi-mncc, but there won't be any outside calls, in or out.  Between
themwi-sip-in and themwi-sip-out, one could be up while the other is
down, in which case outside calls will work in only one direction
(whichever gateway process is still up), but if themwi-mgw is down,
then no outside voice calls are possible, in or out, because this
transcoding RTP gateway is absolutely required: Osmocom components
don't speak G.711, while PSTN-via-SIP connectivity providers don't
speak any GSM codecs.

Speaking of GSM codecs, right now I only have the original GSM 06.10
codec implemented in themwi-mgw, which means that I have to artificially
restrict codec selection to fr1 only via OsmoBSC configuration,
otherwise outside calls won't work.  The next step in my roadmap is to
add EFR codec support - I already found the original reference C code
from ETSI (ts_146053v080000p0.zip), now I need to integrate it into
themwi-mgw.

I will also need to investigate what needs to be done to enable a
continuous RTP stream from the BTS in the uplink direction.  When I
establish a SIP call with my PSTN-via-SIP connectivity provider, be it
inbound or outbound, the RTP stream (G.711) which I receive from the
PSTN far end is continuous - there is always a packet arriving every
20 ms without gaps, even when the far end is silent - and they are all
plain G.711 RTP payload, no funky silence suppression schemes, just as
if I were on a traditional circuit-switched TDM connection.
Transcoding this RTP stream to the selected codec for GSM is a breeze:
I am essentially performing the same function as a traditional E1-based
TRAU would do, just doing it in software with RTP.  This transcoded
RTP stream then passes through two OsmoMGW hops (one for OsmoMSC, one
for OsmoBSC) and arrives at the BTS, for the latter to resync this
incoming RTP stream to its own TDMA timing.

But the situation gets messy in the other direction: because I have
uplink DTX enabled on the Um interface (I could of course disable it
in OsmoBSC config, but it really needs to be enabled in a "proper" GSM
network, to avoid needlessly wasting MS battery power), the MS stops
transmitting during speech pauses.  Having MS transmissions stop on
the air interface during speech pauses isn't the problem - this part
is desired - but the problem I am seeing is that when the MS exercises
uplink DTX, the RTP stream from the BTS also pauses.  Now for many
people in Osmocom community this OsmoBTS behaviour is probably a
feature, not a bug - saving IP network bandwidth - but for me it's a
problem because my RTP gateway (themwi-mgw) relies on regularly
arriving RTP packets as its timing source.

Think of it this way: whenever an RTP stream is active at the source
(not paused), the optimal behaviour for any transcoding gateway is to
transcode and forward every received RTP packet (provided it's in
proper sequence, no errors, etc) as soon as the incoming packet
arrives, without inserting artificial delays in an attempt to
resynchronize to a different time base.  But when the RTP stream stops
at the source (in this case the BTS), all downstream gateways are
suddenly left without this timing - and if a downstream gateway wishes
to keep its output continuous (generating its own comfort noise, or
perhaps generating in-band DTMF), it cannot do so using the original
timing source.  Of course that gateway can switch to its clock, and
then switch back to the original timing when the incoming RTP stream
resumes - that's what I do currently for DTMF generation - but
experiments reveal that typical USA PSTN call destinations don't like
these RTP stream pauses and timing switches.  I really need to modify
my design so that the RTP stream leaving themwi-mgw toward PSTN will
be perfectly continuous, without pauses or timing glitches, and in
order to do so, I need to make the original timing source (the BTS)
emit its RTP stream continuously too, without pauses.

I reason that what I seek should be easily achievable in OsmoBTS,
including osmo-bts-sysmo version running inside my sysmoBTS -
regardless of whether the MS chooses to transmit its uplink bursts or
keep silent, the structure of GSM TDMA prescribes a very rigid timing
window for when those uplink bursts *can* happen, and the BTS is
intimately synced to this timing, it knows exactly when to listen.
Therefore, it should be a simple configuration setting to select the
desired behaviour when no uplink speech frame has been received in the
expected time window - either send nothing on RTP like it does now, or
send a synthesized packet to serve as a timing tick for downstream
transcoding gateways.

What I still need to research is whether the configurable setting I am
after already exists or not - in other words, has anyone already
implemented it, or not yet.  If this feature already exists and I just
need to figure out how to enable it, great - and if not, I will need
to delve into OsmoBTS code and implement it myself.  Of course I will
also have to set up a build environment to recompile osmo-bts-sysmo
which can only run on the sysmoBTS box itself - but oh well, that's
life.

Hasta la Victoria, Siempre,
Mychaela aka The Mother