Hello FreeCalypso community, A little over a week ago I and my SO made a cross-border visit to Mexico for the specific purpose of more thoroughly exploring that lovely country's GSM network. (MCC=334, MNC=020, Name=Telcel.) A basic report on this visit is posted here:
https://www.reddit.com/r/vintagemobilephones/comments/14vm1g8/the_land_of_milk_honey_and_2g_part_2/ and here are more technical details which our much more technical community will likely find interesting: * They do have a bigger spectrum allocation for GSM than in USA: at least in Tijuana Telcel has a 5x5 MHz block (5 MHz DL, 5 MHz UL) in the PCS1900 band allocated to GSM, to be contrasted with T-Mobile USA operating GSM in front and back guard bands around their 15 MHz LTE signal. However, all Mexican GSM cells we've experienced are still single-carrier, i.e., each cell is just the BCCH carrier and nothing more. I remember Vadim telling me that in at least one of his two home countries (not just if it's RU or KZ) there are still commercial operators who operate GSM with frequency hopping, which implies cells with more than just the BCCH carrier; I was hoping to find the same in Mexico, but nope, no such luck. * The network-imposed order of preference for voice codec selection is the same as on T-Mobile USA: - If the MS supports AMR, the network selects AMR-HR; - If the MS does not support AMR but does support EFR, the network selects EFR; - If the MS supports neither AMR nor EFR, the network selects FRv1; - HRv1 appears to not be used ever - I couldn't coax the network into assigning such TCH. * The G.711 backhaul interface to PSTN appears to be A-law (copying EU telecom culture) rather than mu-law like in USA. How did I observe that A-law backhaul? Answer: I was making test calls from my home server to my Mexican Telcel +52 phone number via Anveo, and following what seemed like a law of chance, it would pick different routes. One of the routes definitely appeared to be transcoded and compressed along the way - I need to figure out a way to reject such routes, no problem with paying more for proper transparent ones - but the other route showed all signs of being a transparent one. My sip-manual-out test program would send out its INVITE with an SDP offer listing both PCMU and PCMA codecs, in this order of preference. When calling +1 destinations, the answer always comes back with PCMU selected; ditto with the compressed and transcoded route to +52 which I need to reject. However, on tries when I got the good route to the +52 Telcel GSM destination, the answer was PCMA, a codec which my SDP offer listed as non-preferred - a definite indication that PCMA is native for the Mexican network. During that Tijuana visit I had my Telcel SIM in a Pirelli DP-L10 phone, and for my experiments I ran RAM-based FreeCalypso VPM firmware controlled via rvinterf and fc-shell. I used my recently implemented AT%SPVER command to artificially restrict the speech version list sent to the network in the Bearer capability IE, and by doing so I coaxed the network into giving me EFR instead of AMR. Once I got the call connected with EFR on the destination GSM leg and PCMA on the VoIP leg back to my home server, I used the TCH UL play feature of Calypso DSP (tch play command in fc-shell) to play a particular crafted sequence of EFR codec frames into the UL of the test call; this test sequence included spec-defined decoder homing frames. And sure enough, I saw the expected results in the PCMA RTP stream received by my home server: wherever I sent two back-to-back DHFs in GSM UL, the RTP stream featured a run of 160 0xD5 octets (EHF turned into PCMA), and the subsequent frames matched the expected output of the EFR decoder turned into PCMA. Thus I got evidence confirming my hunch that the connection is indeed byte-transparent from my calling server to the edge transcoder of Telcel GSM network. There is an additional quirk with networks using PCMA instead of PCMU. When the G.711 PSTN side is PCMU, the speech encoder in GSM DL direction normally won't send homing frames unless the G.711 source on the far end is explicitly sending 0xFE octets, which won't happen on its own - PCMU silence is 0xFF, but making the GSM speech encoder see EHFs on its input requires 0xFE in PCMU. But with PCMA it is different: a silent PCMA channel is 0xD5 octets, and these same 0xD5 octets turn into 0x0008 in 16-bit linear PCM form - and that's an encoder homing frame! Thus when the PCMA input to a GSM speech encoder is total silence, that encoder will be emitting a continuous stream of homing frames instead of going into DTX - but change 0xD5 to 0x55 (change from the smallest positive to the smallest negative sample, smallest in absolute value), and the GSM speech encoder starts doing DTX. I observed this behavior in my test calls, confirming that the path in this direction can be byte-transparent too. But despite all this evidence of a transparent G.711 connection, I couldn't get TFO. No TFO in-band signaling (IS) messages are seen in the PCMA sample stream coming from the GSM network's edge TC, and when I tried sending TFO_REQ IS messages in my outgoing G.711 sample stream in RTP packets, no response was elicited. Thus the hunt for a TFO- supporting GSM network anywhere in the world, or a TFO-supporting TRAU in the hands of some community members which I could play with remotely, still continues. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community