one long-standing issue with OCTOI is random bit errors.
Somewhere along the (rather complex) chain of osmo-e1d, icE1usb, Digium TE820, yate, DAHDI and maybe the Auerswald PBXes, bit errors get introduced.
This was first noticed when using OCTOI for modem calls, which would randomly get interrupted.
At CCCamp23, OCTOI was used for interconnecting V5 access multiplexers along the field.
The connection there also wasn’t 100% reliable (despite the local and very high quality network).
One issue was identified by @laforge at Camp already:
OCTOI “compresses” the frames by not transmitting timeslots which haven’t changed since the last frame. This saves a lot of bandwidth (E1 is 2 MBit/s after all, which is still a lot even for modern connections), which would otherwise be wasted in idle/flag octets.
This masking/compression mechanism can now be disabled by using the
force-send-all-ts option. This has improved reliability at Camp dramatically (but not completely).
Late in the OCTOI development, a RIFO (random-in, first-out) buffer was introduced to re-order incoming frames from the network into linear order again. We noticed that DOCSIS (cable internet) lines in particular often receive packets out-of-order.
Apparently the RIFO mechanism was introduced after the frame unmasking. This leads to frames being unmasked against random, other frames which are in the buffer (instead of the last frame by frame number).
A quick & dirty patch written by me seems to improve the situation considerably, but there’s still bit errors occurring.
There’s 3 ways of doing BERT checks:
- BERT hotline in DIVF yate
- BERT hotline in local yate
- 2-channel BERT (tester calling itself on the second B channel)
Both the DIVF yate and my personal yate installation have a special number, which just plays a carefully crafted .wav file. This wave file contains a very long (4 hour+) PRBS11 sequence.
A ISDN tester (like the Argus) can then call this number and will receive that PRBS11 sequence and compare it to a locally generated version.
The ISDN tester can also call itself on the other B-channel and then generate it’s own test sequence and listen to it again. This is ideal for testing both directions of a link and will also avoid any problems in the DIY BERT .wav mechanism.
3 tests can be done this way:
- calling itself locally on the S0 bus (through the Auerswald only) - 2161 - works fine, no bit errors
- calling itself through the yate (via TE820, DAHDI, yate) - 02161 - already results in bit errors!
- calling itself through OCTOI (via TE820, DAHDI, my yate, DAHDI again, trunkdev, trunkdev, DAHDI again, DIVF yate and all the way back) - 003065022161 - results in even more bit errors.
So even without any osmo-e1d/OCTOI involvement, there’s already issues occurring.
I will replace the TE820 with a icE1usb temporarily to try and investigate if this behaves better.
After that, I might try to replace yate with asterisk (or similar) to try and check if yate or DAHDI is at fault.