From mychaela.falconia at gmail.com Wed Jul 6 04:52:17 2022 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Tue, 5 Jul 2022 20:52:17 -0800 Subject: Update on my GSM network setup Message-ID: 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