This adds "e1oip:e1t_ts_active" and "e1oip:e1o_ts_active" to show
which timeslots are active (i.e. which are transmitting data in the
IP protocol).
Change-Id: I6858e0773a348193bb4839c247294cef5ab4df5f
This adds a new [rate] counter "e1oip:connect_accepted" that increments
every time the connection is accepted for both server and client role.
The rate is not really interesting, it's more the total absolute
quantity that's interesting. Plotting the delta will give us spikes
whenever the connection is re-established.
Change-Id: I8baac768289f7e01d943f5205afa824f367a3a61
This typically happens if the remote IP peer is transmitting at a faster
rate than the E1 side is consuming. Let's add a way to monitor it.
Change-Id: Ie0e8bb2f5d2ae4256952f6bf69e514d5c2627a76
This indicates that this is counting an E1-originated overflow of the
OCTOI transmit FIFO, which should never happen unless your system is too
slow to periodically schedule the related timers in the code.
Change-Id: I0af6a2847c8356b011bcff5cc4f5d909c574ea21
A real _underrun_ happens if the RIFO is empty (depth == 0)
and should be counted different from a mere frame substition
due to packet loss.
Change-Id: I5448430b09ec10a16decdfd0a4a40850fe2ed1a6
This was not an issue with the original FIFO code, which dynamically
substituted frames and always created the minimal required backlog.
The RIFO can by principle not operate this way, so we really have to
prime / pre-fill it with a number of TDM frames. That initial fill
level has to be sufficient to cover RTT jitter of the OCTOI link as
well as clock drift between (GPS synced) receiver and transmitter.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3a4b3846d3dbd1c99989e994ad95e609f2757219
For both OCTOI client + server FSM, whenever we enter the ACCEPTED
state (we disconnect), let's reset the RIFO/FIFO state. This makes
sure no left-over frames from some earlier connection are present,
and also ensures our initial frame number expectations are correct.
Change-Id: I9e721b5dbf22728cb2361ed121d12def7016dcc2
Only frames withing a certain window are even accepted for processing
the rest is dropped since it could corrupt our state.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I25b2e150d924aa8c714b766cb92e9e23e67cfa4c
We don't want useless identifiers like 'E1oIP line 5518' but something
that we can understand, like the user account name, or in absence
of that, at least the IP/port.
Change-Id: Ibd98b9606a1d9d5b76d63be83eb3df9e431ab3ad
There use to be a stat_item for the depth of the E1-terminated FIFO, as
in a FIFO this is very easy to determine. When we switched to RIFO, it
was lost. Let's re-introduce it with the approximate depth of the RIFO.
Change-Id: I960cbf196ae930b1b72745b8bfe9c2a21fd53325
frame_rifo_in would previously return -ERANGE when a frame was written
which was at the edge of the wrap-around of the frame number (because
the maximum value was already across the boundary)
Also: fixed some typos
Change-Id: I88abfc77543d5c64b01f40944b2914e03e57d08f
In the past, we used a FIFO structure (first in, first out) - which
obviously cannot deal with packet re-ordering on the IP side.
This patch introduces a new "RIFO" as a replacement for the FIFO.
The RIFO is able to reconstruct E1 frame ordering by using the
reduced frame number from the TDMoIP messages, at least as long
as the related frame number range is within the current RIFO depth.
Change-Id: I22256870114cb85e4e10932554478be7061e086b
This introduces initial support for operation as OCTOI (Osmocom
Community TDMoIP) server and client operation.
Various features are still absent (user authentication, support for
re-ordered packets), but this version is already able to provide
services to clients with dynamic IP addresses as well as servers.
The bulk of the OCTOI / E1oIP code is implemented as a shared library,
to facilitate the development of other servers and clients in the
future, and also to minimize the impact on the existing osmo-e1d code
base.
More information is available at https://osmocom.org/projects/octoi/wiki
Change-Id: I05f5ff697ca8f7dccdcf89660f12089babfcc92e
Harald Welte
Sylvain Munaut
Manawyrm