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
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
As soon as an OCTOI connection gets into ACTIVE state, send a
ECHO_REQ every 10s and compute the RTT at the time of receiving
the response.
Contrary to the initial idea, the stat item contains the RTT (round trip
time) measured in micro-seconds. Changing this is not a problem as so
far the RTT was always reported as '0', and 0ms == 0us.
Change-Id: Id331319bff1cf6896fee37acc45846a2491ca92d
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
We have to issue the OCTOI_CLNT_EV_REQUEST_SERVICE event to the FSM
only after it has switched back to INIT state.
Change-Id: I1d913a8153adaf87b2c3dadcf98382ff0b9fc2fb
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 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
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
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
Andreas Eversberg
Harald Welte