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@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
_______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community