| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Whenever the RIFO buffer fill drifts away from its target, it can be
automatically reset and filled to the initial prefill_frame_count value.
The average fill is measured over several seconds. A given deviation
in percent of the prefill_frame_count is used to trigger that reset.
If the deviation is not set (0), this feature is deactivated.
There are two reasons for this to happen: The GPS clock is missing, so
the receiving interface is not in sync with the transmitting interface.
The delay changes significantly, due to congestion on the path between
both peers. (poor internet connection)
Change-Id: Id7ccbfbdb288990c01f185dec79a1022a68b4748
|
|
Change-Id: I837676cb3905c0113307ebc400974c3d8cf3a3c7
|
|
This new mode (can be enabled per account) will force the E1OIP
protocol to always send all timeslots, i.e. not do any of the
suppression of timeslots that do not exhibit any change to the
previous E1 frame.
Change-Id: I6d17d3829b2c1c62e701a1d8c021d93d93593613
|
|
This adds VTY commands at the 'account' level to configure those
settings. They will only become active on the next [re]connect
of the line.
Change-Id: Ic455ef0ef82867db512e2ffdff24d9dd42d47eeb
|
|
Change-Id: Ia0da9b038312b010bfdf88570733bf1bf004b7a8
|
|
This allows to monitor the traffic utilization of each e1oip line.
Change-Id: Ifde6be0b7d3c5767b684cb8fbbc58bbd5cfb0714
|
|
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
|
|
If we are permanently overflowing the RIFO in IP->E1 direction, the
peer clock is consistently faster than our E1 clock. There's no smart
way to recover from this. Log an error and disconnect.
This is the opposite situation from the high RIFO UNDERFLOW situation
whose logging + disconnect handling was added in
Ie3fffa1c1c20962b40320c8cc088c140b8d64e77
Change-Id: Iecd294b0174c9a0572df3dad612cb4efbd9cde07
|
|
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 situation is the result of the peer clock being continuously
too slow compared to the local clock, leading to RIFO underruns at
[virtually] all of the 8000/s E1 frames. As the current code doesn't
recover from this, we might as well disconnect and re-start for
recovery.
Change-Id: Ie3fffa1c1c20962b40320c8cc088c140b8d64e77
|
|
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
|
|
Change-Id: Ie97c1efecf8b673620ddc097e0184f8a9c92c3f0
|
|
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
|
|
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
|
