retronet-discuss March 2024

discussion@lists.retronetworking.org

2 participants
3 discussions

My interconnection with USA PSTN
by Mychaela Falconia 08 Mar '24

08 Mar '24

Hello fellow retronetworkers, In the USSE portion of this week's RetroNetCall (approximately 2 days ago, depending on how you look at time zones) I made some mentions about my SIP setup for interfacing with the outside world, and I got the impression that my attempts at explanation in that RetroNetCall weren't so great - so let me try explaining it better by way of the written word. Why connect to real PSTN? ------------------------- It appears that most retronetworkers other than me connect their retro phone systems to separate "not real" networks like C*NET, rather than real live PSTN. Why am I different in this regard? Answer: my main objective in this entire retronetworking venture is to use my choice of retro phone (in my case, GSM/2G) as my primary daily driver phone for real human communication. I know that other people somehow keep those sides of life separate, i.e., they will play with retronet toys for fun, but use some modern iPhone for everyday communication - but that is NOT me. I refuse to own or use or touch an iPhone, to the point that if I were to get into a horrible accident on a highway, I would rather bleed out to death on the side of the road than use an iPhone to call for help. Being able to use a retro GSM/2G phone as my main personal phone, and do so without depending on the fickle whim of T-Mobile, requires operating my own GSM network - that's what Osmocom CNI is for - and connecting said network to real live PSTN, as opposed to "toy" networks like C*NET. For my interconnection with real live PSTN in USA, I currently use the services of BulkVS and AnveoDirect, as well as Sopranica Telecom (jmp.chat) for SMS interconnection. More specifically, I rent real phone numbers from BulkVS, I receive all inbound calls to these numbers through BulkVS, and I use both BulkVS and Anveo as outbound routes. I use BulkVS as the outbound route for calls going to North America +1 destinations, and Anveo for calls going to any other country code destination. How inbound calls work ---------------------- I have a public-facing SIP server listening on standard port 5060; this server is located at DNS name sip-gw.sandiego2g.org. More specifically, on the time scale of years the actual IP address may change if I have to change ISPs or move the server from my home to some datacenter hosting when San Diego 2G Association expands (hopefully), but it will always be some static and public IP address (like it is now), and DNS will be updated in the case of any moves. (Right now I am hosting the server at my home on a business-grade Internet connection, but that's an implementation detail that can change without affecting the architecture or the public interface.) I have my BulkVS service configured to send inbound calls via SIP to this sip-gw.sandiego2g.org server, to the same IP to which this DNS name points. There is _no_ SIP registration or authentication or any of that complexity - instead BulkVS servers simply send a SIP INVITE to port 5060 at my static & public business IP address whenever an inbound call comes in to any of the phone numbers I rent from them. USA phone numbers cost only 6 cents per number per month with BulkVS, hence I have a bunch of them, many more than just my own personal phone number. However, my inbound SIP gateway (meaning themwi-sip-in process, all written by me, running on this sip-gw.sandiego2g.org server) is happy to accept inbound calls from anyone, not just from BulkVS servers. In other words, I fully support the principle of settlement-free peering in public phone interconnection. USA is a huge country, whereas the scope of San Diego 2G Association is explicitly limited to the named locality. Suppose someone else, somewhere else in USA, decides to mimic what we are doing and set up their own community-based GSM/2G network. Suppose that other community network (e.g., Keene NH) then wishes to peer with SD2G, such that SD2G routes calls to Keene-owned numbers directly to Free Keene network, and FKnet likewise routes calls to SD2G-owned numbers directly to SD2G, without paying BulkVS or Anveo or any other carrier to ferry those calls - from my side I will always warmly welcome any such peering arrangements! The technical implication of this "open arms" policy is that my public- facing SIP server is wide open to the world, receiving junk "probing" SIP packets from script kiddies 24x7x365. But all that junk is statelessly rejected without wasting server resources. In order for my gateway to do anything with an incoming SIP INVITE other than just toss it, that INVITE would have to be directed to one of NANP numbers that specifically belong to my network and not to someone else - and if someone is actually calling one of my numbers, then my gateway is happy to accept that call and route it to the respective GSM subscriber, no matter which IP or party or entity that SIP call came from. How outbound calls work ----------------------- My outbound gateway (themwi-sip-out) routes each outbound call to either BulkVS or Anveo, depending on E.164 destination country code - or more precisely, I can set up any number of routes, matching on any desired E.164 prefixes. But the mechanism is once again plain SIP INVITE packets only, no registration or authentication or any other complexity. Like every other reasonable wholesale SIP trunk provider, both BulkVS and Anveo support IP-based authentication: I simply go into my customer portal with each of these companies, and list in there that any SIP calls coming from my IP address are to be billed to my account. When I tried to explain this last part in RetroNetCall USSE, I was met with derision, people saying something about security holes etc. But I still stand by this architecture: we are NOT talking about a consumer or personal VoIP user connecting from their nomadic personal IP that will likely change all the time, this is a production deployment of SD2G (a long-term-established business entity) sending wholesale traffic to its contracted carriers. Whatever servers SD2G uses, these servers will always have static IP addresses - so what's wrong with simply whitelisting them? In that RetroNetCall USSE, I seem to have heard someone say something about IP spoofing - but how would such spoofing help any would-be attacker in my case? Suppose that someone wishes to impersonate SD2G, i.e., send a rogue call out to BulkVS or Anveo, but make it look like their call is coming from SD2G. A successful SIP call establishment requires a 3-way handshake: the caller sends INVITE to the callee, the callee responds with 200, and the caller follows up with ACK. Suppose an attacker sends a spoofed UDP packet to BulkVS or Anveo, with the source IP forged to indicate my SD2G server, and the packet content being a SIP INVITE which BulkVS/Anveo would accept as valid. The SIP carrier would then sends SIP responses to my IP address, hence those responses will go to my server and not to the attacker. The attacker will never learn the To tag assigned by BulkVS/Anveo to this call, and they will thus not be able to construct a valid ACK. And without that ACK, they won't get a successful call - so where is the problem? IP telephony carriers mucking with RTP -------------------------------------- I still don't understand why enterprise-oriented, business-serving (NOT consumer or end-user oriented) ITSPs modify SDP to make the RTP stream pass through their nodes, as opposed to letting it pass directly end to end. Suppose Alice Enterprises, a customer of ITSP-A, sends a SIP call to Bob Enterprises, a customer of ITSP-B. When BobEnterp receives the SIP INVITE addressed to them, they will see SDP pointing at some carrier nodes owned by unclear-whom (maybe ITSP-A, maybe ITSP-B, maybe some other "shared" party in that ecosystem), but not the original SDP from AliceEnterp pointing to AliceEnterp servers. Why??? In the RetroNetCall USSE I was told something about customer privacy, removing customer IP addresses. I totally understand doing that practice for consumer-oriented VoIP services, but why in the heck do they do it in the _wholesale_ SIP trunking business? It is my understanding that wholesale carriers like BulkVS work only with enterprise-level business entities - and surely a business entity of the latter type will have no need to hide their production servers? BulkVS say that they *don't* proxy RTP traffic, i.e., supposedly my RTP traffic does not pass through BulkVS servers, only SIP does. But then BulkVS is primarily a reseller of even bigger wholesale carriers like Bandwidth and/or Inteliquent, and it appears those parties then do proxy RTP, i.e., SDP blurbs I get from BulkVS (incoming INVITEs and answers to my outbound calls) are probably pointing to those carriers. I was also told in that RetroNetCall USSE that these carriers "don't want" to be transcoding my RTP traffic, at least domestically within USA, that doing so costs them CPU cycles etc. But who is then denying me the ability to talk AMR directly to the other party when calling or receiving a call from a VoLTE user on any of the 3 national carriers? All mobile phone users in USA, other than hard-core 2G holdouts like me, are on VoLTE: AT&T and Verizon only have VoLTE networks, they don't have any circuit-switched networks at all; T-Mobile has GSM only for "grandfathered" customers like me, and they push like hell to get these users to "upgrade" - hence mainstream, not hard-code-rebel T-Mobile users are also 100% VoLTE. And although I am no VoLTE expert, it is my understanding that VoLTE phones don't speak G.711 directly - instead they speak either AMR-WB (their preference) or AMR-NB as fallback. Yet whenever I receive a call from a VoLTE user, the SDP offer from BulkVS only lists PCMU, PCMA and G729 in this order - no AMR. In the other direction, if I send a call to BulkVS addressing the number of a VoLTE user, I can offer AMR and/or GSM codecs until I am blue, but only PCMU will be accepted in the answer - and if I send an offer that includes only AMR and/or GSM codecs, without PCMU, the call is rejected. Thus the result is that someone somewhere is transcoding between the PCMU they speak with me and the (presumed) AMR codec on the VoLTE leg. Who is doing this forced transcoding, and why? What is their perverse justification for denying non-transcoded AMR in outside calls to/from VoLTE carriers, and why is it so important to them to effect this denial that they gladly expend CPU cycles to do it? Still bewildered, Mother Mychaela

1 0

GSM module inside Possio Greta fax machines
by Mychaela Falconia 06 Mar '24

06 Mar '24

Hello fellow retronetworkers, Today I received a pair of Possio Greta GSM fax machines from Harald. I haven't powered up either of them yet, as I have no CSD-capable BTS up and running currently (sysmoBTS sadly does not support CSD, and I have yet to tackle the project of trying to bring my ebay-sourced UmTRX to life with osmo-bts-trx), but as I was examining these devices visually, I noted that they are a lot more "modern" than I thought they were. The CE mark on the label sports year 2009, and the IMEI begins with 35368104. The 04 in the FAC field told me right away that it must be a "late GSM era" device, NOT early GSM era, but then I tried looking it up in the IMEIDB leak I once found on Scribd: https://www.freecalypso.org/pub/GSM/IMEI/186248059-Tac.pdf And sure enough, it is right there on page 667: this IMEI belongs to Cinterion MC55i module! So now we know exactly which GSM MS engine these fax machines have inside. :-) And here is the best part: as the IMEIDB entry says and searches for MC55i datasheets confirm, this GSM module and hence the GSM fax machine built around it is quadband! Prior to this discovery, I feared that I would have to not only get a CSD-capable BTS up and running, but also operate it in an EU band for this gear to work - but since it is quadband, I now know that once I do get a CSD-capable BTS, I can run it in whichever band makes the most sense given the spectrum-political situation in my neck of the woods. Needless to say, I look forward to tomorrow's presentation by Harald, where we will hopefully learn how ISDN fax differs from analog and GSM kinds. :-) M~

1 0

RetroNetCall on Mar 6, 2024: Telefax G4 protocol trace decoding
by Harald Welte 04 Mar '24

04 Mar '24

Dear Osmocom community, we're happy to announce the next incarnation of RetroNetCall[1], the retronetworking oriented spin-off of OsmoDevCall[2]. when: Mar 6, 2024 at 20:00 CET where: https://osmocom.org/RetroNetCall This time, @laforge will be presenting on Decoding of Telefax G4 protocol traces. We'll look into the ITU-specs of Group 4 Facsimile Service as well as at an actual B-channel protocol trace taken a few days ago. This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [3] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about RetroNetCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/retronetworking/wiki/RetroNetCall Looking forward to meeting you soon! Best regards, Harald [1] https://osmocom.org/projects/retronetworking/wiki/RetroNetCall [2] https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall [3] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

2025

2024

2023

2022

retronet-discuss March 2024