Ever since we set op the OCTOI (Osmocom Community TDM over IP) network, I was hoping that one day we’d not only speak ISDN / Q.931 as signaling protocol, but also proper SS7 with MTP2/MTP3/ISUP protocols.
This has now happened during the last week: We’ve set up ISUP between the EWSD of @jpesak in Brno/CZ and the OCTOI yate co-located in a data centre in Nuernberg/DE.
The underlying E1 link is the “usual” method: icE1usb on the EWSD side where the physical E1 is reuired; osmo-e1d to convert to the OCTOI protocol over UDP; osmo-e1d on the datacenter side (using dahdi-trunkdev) feeding into the yate.
Given that we didn’t have any prior experience of setting this up, it actually went reasonably well. The biggest difficulty was getting the routing right in yate, as somehow there are a number of subtle differences in routing whether a call is arriving via Q931 or ISUP. Subtle things that the overlap variable is set to “yes” in Q931 but to “true” in ISUP… yeah, wtf.
Given that I didn’t manage to get overlap dialing to work, and it’s very hard to debug if you have to have somebody at the other end to manually make voice calls, we decided to use en-block dialing for now. I am planning to write a small ISUP call generator software that I can use to debug this locally. Probably it’s going to be a piece of TTCN-3 code using the existing modules we have for ISUP, and using a SIGTRAN M3UA connection to yate. This way I’d be able to generate as many call attempts in software as I need, just to figure out how to implement overlap dialing for inbould ISUP calls.
In any case, with en-block dialing the interconnect is working. We’re routing +420-5-* to that link, rather than via C*NET. So any calls you make in that direction will use the SS7/ISUP/TDMoIP link.
If you’re a member of OCTOI, you can use the following numbers below the +420-5452 prefix for testing:
- 13000 milliwatt
- 13001 echo test
- 13002 number reading service
- 13005 DTMF test
- 13112 speaking clock (@jpesak voice)
- 14112 speaking clock from EWSD DAS and ZAG500 - for many years it was used
by our incumbent operator SPT Telecom - 13413 test music from EWSD INDAS (ocaneq board)
- 133xx 01-16 - old test Czech music
There’s also a fax at +420-548123509
We discovered one interesting problem though: MTP2 contains a mechanism that declares a link as dead if too many errors occur. This has been observed with packet loss on the TDMoIP link. The result is that the EWSD will stop using it for many minutes before re-trying. We’re currently setting up a second MTP2 link (on TS1, in addition to the primary one on TS16) to see if that helps. I’m not very optimistic, as both links would likely experience the exact same number of errors as their data is contained in the same TDMoIP packets.
@jpesak pointed out there’s something called PCR (Preemptive Cyclic Retransmission) specified as an option in MTP2 (intended for lower quality satellite links). The EWSD apparently supports it, but yate of course doesn’t This switches to a method where every message must be explicitly ACKed by the remote end, with retransmissions happening automatically until that ACK arrives. Now we just have to find somebody who has time and energy to develop this for yate MTP2 