Dear Osmocom community,
we're happy to announce the next incarnation of RetroNetCall[1],
the retronetworking oriented spin-off of OsmoDevCall[2].
when:
Sept 4, 2024 at 20:00 CEST
where:
https://osmocom.org/RetroNetCall
This time, we won't have a presentation but intead a joint,
collaborative session where we're analyzing and debugging any
potentially remaining (or new?) issues with divf.retronetworking.org,
our central soft-switch of the OCTOI community TDMoIP network.
Participants are invited to try making certain calls and we will look at
logs/traces and see what we can fix or improve.
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)
Dear Osmocom community,
we're happy to announce the next incarnation of RetroNetCall[1],
the retronetworking oriented spin-off of OsmoDevCall[2].
when:
Aug 8, 2024 at 20:00 CEST
where:
https://osmocom.org/RetroNetCall
This time, @laforge will be presenting on
*classic PCM30 trunks with channel-associated signaling*
followed by a discussion how to potentially implement this using
the icE1usb (See also: #6526 [4]).
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.
[4] https://osmocom.org/issues/6526
--
- 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)
[My apologies, I misread the calendar. It's August 7, not August 8]
Dear Osmocom community,
we're happy to announce the next incarnation of RetroNetCall[1],
the retronetworking oriented spin-off of OsmoDevCall[2].
when:
Aug 7, 2024 at 20:00 CEST
where:
https://osmocom.org/RetroNetCall
This time, @laforge will be presenting on
*classic PCM30 trunks with channel-associated signaling*
followed by a discussion how to potentially implement this using
the icE1usb (See also: #6526 [4]).
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.
[4] https://osmocom.org/issues/6526
--
- 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)
Hello fellow retronetworkers,
I am now looking into possibly using icE1usb to talk to my Nokia TRAU.
My original was to use a Digium PCI card, but I ran into issues:
a) The only machine I have with a PCI slot is a production machine;
b) My naive hope that DAHDI would "just work" did not pan out;
c) Deeper troubleshooting would require subjecting this production
machine to more downtime than allowable.
Hence I am looking at the alternative of using icE1usb instead. There
is one sticking point though: unlike a BTS, playing with a TRAU requires
a minimum of two E1 circuits, one for A i/f and one for Ater. And I
know that few host systems can drive icE1usb with both interfaces in
terms of USB limitations.
However, this page says that Raspberry Pi 5 should do the trick:
https://osmocom.org/projects/e1-t1-adapter/wiki/Isochronous_USB_Issues
I am thinking about getting an RPi5 specifically for the purpose of
driving icE1usb with both E1 interfaces active. The requirement of
having no other USB devices will be easy to satisfy: the whole RPi5
will be just for this purpose and no other. But I would like to
confirm:
a) Does anyone here have actual experience with RPi5 driving both E1
interfaces on an icE1usb?
b) RPi5 has two kinds of USB host ports: some USB2 and some USB3.
Which would be better to use for icE1usb?
TIA for any leads,
M~
Hello fellow retronetworkers,
For those of you who enjoyed my TRAU presentation last week, I got a
very positive update. :) Today I got this TRAU powered up (after
getting the right crimp connector parts from Digi-Key and assembling
the necessary wiring harness for -48 VDC power to the box), and while
I still don't have the additional hw that brings out E1 circuits, the
management interface I got on the RS-232 port shows that this unit has
everything we'll need to have lots of fun once those E1 connections
are made:
* No password lock: the mgmt interface password is the factory default
that's documented in the manual.
* There are 3 DSP fw images installed on the TRCO (the maximum it can
hold per the docs), covering circuit types A, B and F. Circuit type
F (the one it came configured with) is AMR, which is not of much
interest to me (and apparently Nokia never implemented TFO for AMR
in any of their TRAUs), but cfg A is 16 kbit/s FR/EFR/CSD and cfg B
is 8 kbit/s HR - these are the ones I look forward to playing with.
* TFO feature is present, i.e., NOT excluded or blocked by "premium
feature" schemes - yay! Obviously I won't be able to confirm it
actually working until I get A & Ater E1 interfaces brought out and
connected to my test rig, but the option to enable/disable TFO is
present and accessible in the mgmt interface, and when I set it to
enabled, it shows up as such in config readback.
The next step is for me to buy an ET2E module and the ET1TC chassis
that holds it from shields-e (the same people from whom I bought the
parts I already got), and then make my own cable with DIN 41612
connectors to connect the two backplanes - that's how we'll get the
two E1 interfaces (A and Ater) out of this baby.
Until then, if you are curious to see what the management i/f for the
TRAU looks like, here is a log of my RS-232 session talking to the
box, from power-up:
https://www.freecalypso.org/members/falcon/trau/tcsm2-boot.log
and here is the manual that describes this interface:
https://www.freecalypso.org/pub/GSM/Nokia_TCSM/tcsm2-command.pdf
Happy hacking,
Mother Mychaela
Hello retronetworking community,
As Harald already announced, tomorrow (or later today in Eurasian time
zones) I will be giving my first installment in what will be a series
of presentation on my adventures with Nokia TRAU hardware, specifically
TCSM2. In order to make better use of time during the actual
RetroNetCall, I am posting my slides ahead of time:
https://www.freecalypso.org/members/falcon/presentations/trau-pres1.txthttps://www.freecalypso.org/members/falcon/presentations/trau-pres1.pshttps://www.freecalypso.org/members/falcon/presentations/trau-pres1.pdf
(Plain text -> Postscript -> PDF is my generation chain; I write in
plain text, but PDF is needed for upload into BigBlueButton.)
Anyone who is interested in this TRAU topic, I recommend that you read
these slides ahead of time - this way I can spend less time reading
the slides (or pausing for people to read them in real time), and we
can have more time for the fun parts of looking at the hardware (I will
be pointing my webcam at the hw) and discussing the still-outstanding
challenges.
See y'all tomorrow, after my sleep cycle. :)
M~
Dear Osmocom community,
we're happy to announce the next incarnation of RetroNetCall[1],
the retronetworking oriented spin-off of OsmoDevCall[2].
when:
Jun 5, 2024 at 20:00 CEST
where:
https://osmocom.org/RetroNetCall
This time, @falconia will be presenting on
Nokia TCSM2, a bank of TRAUs with E1 interfaces: Part 1, initial examination of the hardware
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)
Hello fellow retronetworkers,
For a long time I've been looking to get my hands on a traditional GSM
TRAU, a hardware converter from 16 kbit/s (or 8 kbit/s in the case of
HR) speech channels going to a traditional T1/E1 BTS to full 64 kbit/s
PCM channels, complete with speech transcoding functions per classic
GSM specs. I started this search about this time last year, but now I
am getting a little closer: I just sent a payment to Shields
Environmental, a surplus telecom equipment dealer recommended to me by
Harald, for a set of old Nokia parts that should be enough to put
together a minimal Nokia TCSM2 system. There will be some more waiting
(they still need to pack and ship my order, and then I will need to
wait for it to arrive), but it looks like I will have a new toy soon!
TCSM stands for Transcoder and Submultiplexer, which is Nokia's term
for the bank of TRAUs that sits between the MSC and the BSC in the
traditional E1-based architecture. Apparently there were 3 generations
of Nokia TCSM, with TCSM2 being the middle one. For each of these 3
generations, a "proper" TCSM installation was a giant cabinet full of
units, which is obviously *not* what I am going for in my lab - instead
I ordered just enough parts to put together the most minimal config
that is possible in TCSM2 architecture: one TC1C chassis (coming in
the present order) and one ET1TC chassis (to be ordered later).
A single "unit" of TCSM2 handles one E1 line on the Ater interface,
the i/f between the transcoding site and the BSC. If this one-E1 Ater
is used to its full capacity, it expands to 4 E1s toward the MSC with
full rate channels, or to 7 E1s with HR channels. In theory the
maximal expansion is one E1 on Ater to 8 E1s on A with HR, but TCSM2
supports a maximum of 7 A-interface E1s for each "unit" handling a
single Ater E1. However, for lab hackers like me who aren't interested
in maximum capacity, the minimal config for TCSM2 is one E1 on Ater,
one E1 on A, two TR16 transcoder cards, and a maximum of 30 simultaneous
call legs.
For this one "unit" of TCSM2, there is one TC1C chassis that hosts one
TRCO card (the main controller), from 2 to 14 TR16 cards (I am getting
the minimal two), and the power supply that takes in -48 VDC. There
is also the ET1TC chassis that holds "exchange terminal" T1/E1 cards;
I will later need to buy this chassis and one 2xE1 card from the same
dealer.
According to the docs I found, the TRCO card (the head of a TCSM2 unit)
has an RS-232 port for local management, and supposedly it is possible
to configure the unit autonomously in this manner. It normally "wants"
to be controlled from the BSC via some LAPD-based proprietary protocol
on an Ater timeslot, but it looks like Nokia also provided for "test"
operation with neither BSC nor MSC present, for which all basic settings
can be configured via that local RS-232 port. This latter mode of
operation is what I seek, as I don't have any T1/E1 MSC or BSC hardware,
nor do I seek to acquire any currently.
My intent is to connect both one-E1 A and one-E1 Ater interfaces to a
"play" machine with a dual E1 interface (either icE1usb or a Digium
card, TBD), and bring individual TRAU channels to life by feeding
TRAU-UL frames of the desired codec type (as if coming from a
freshly-brought-up TCH on a BTS) to sub-timeslots on the Ater interface.
Then see what comes out on the A interface, feed some PCM input to A
and observe Ater DL output, etc.
One big uncertainty is TFO, the in-band bit-stealing protocol inside
64 kbit/s PCM speech channels defined in GSM 08.62, later 3GPP TS 28.062.
I *really* want to play with TFO, and the hope of getting a TFO-capable
one is the main reason I just spent a ton of money on this TRAU gear.
However, it appears that TFO was an "optional" feature on TCSM2, along
with several other "optional" features like AEC and voice AGC - features
that go beyond ETSI- or 3GPP-specified standard functionality for TRAUs.
It appears that "back in the day" customers had to pay a little extra
to Nokia to get these "optional" features, but it is not clear to me
how the restriction was implemented. Did they have different firmware
versions with these features included or excluded? Or was it some kind
of license key entry system? In any case, I *really* hope that the
TRCO and TR16-S cards I just paid a ton of money for will arrive with
TFO-capable firmware in them, such that the actual feature can then be
enabled or disabled with configuration commands on the RS-232 management
port as documented...
To be continued,
Mother Mychaela
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
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~
