Themyscira Wireless update

[Rafael Diniz]

That is very encouraging Michaela.

If you want to test calls outsite +1, you can call me.

Btw, GSM EFR is also implemented in opencore-amr, as seem in:
https://gitea.osmocom.org/osmocom/gapk/src/branch/master/src/codec_efr.c

Cheers,
Rafael

On 10/14/22 01:26, Mychaela Falconia wrote:
> 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
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community