Notify user about read errors, similar to what is supported in the
earlier ofd cb backend of osmo_stream_cli/srv:
https://osmocom.org/issues/6405#note-15
Related: OS#6405
Fixes: 5fec34a9f2
Fixes: 0245cf5e07
Change-Id: I395c75ff1e9904757ce1d767a9ac2f779593c4c8
- Use tall_test as root context everywhere, don't create any other contexts
- change .*_(cli|srv)_run_client() signature by adding talloc context as parameter
- Open and Close server link inside test_recon()
Related: OS#6222
Change-Id: I9ef02ed113bc049ae430b93d0eb69641e2ee809b
With this commit, IPA segmentation is taken care of by setting the
segmentation callback provided by libosmo-netif.
The ipa-stream-server example needs to prepend IPA headers now because
those are stripped by the segm. cb on both sides.
Depends: libosmocore.git I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
Related: OS#5753, OS#5751
Change-Id: I822abf52c6ae396c90b5c50228a0a39c848d3de6
A previous commit added additional logging information, necessitating changes to
the test code as well as to the output check.
Related:OS#5753
Change-Id: Ib8f01c3651c13814c212328946415094da39d6a8
With this commit, IPA segmentation can be taken care of by setting
the segmentation callback osmo_ipa_segmentation_cb().
Depends: libosmocore.git I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
Related: OS#5753, OS#5751
Change-Id: I6c91ff385cb5f36ab6b6c96d0e44997995d0d24c
Since the local port is logged now in stream_test, it must be set to
a specific value in order to have deterministic log output being
validated.
Change-Id: I17ef699dab72c1b613708070d22e9f040b0fe069
* -I is a preprocessor flag, so it should be in AM_CPPFLAGS
* $(LIBOSMOCORE_LDFLAGS) is not defined here, remove it
Change-Id: Ice892f848e06b601e67b06a4e1e25c11fb7c4128
This allows easily identifying and following state and lifecycle of
CIDs when looking at logs.
Related: SYS#6161
Change-Id: I6a3113dfaef0adbb20162985e3b7d57c46dbc016
Previously, if RTP jumps were detected in the incoming RTP stream and
osmux state for that circuit was to start the next batch, the hole would
not been filled during queueing time and instead the encoder would have
set the M bit in the osmuxhdr to announce a sync point.
For small holes (eg less than the batch factor) it makes sense to start
filling the batch with crafted RTP packets in order to avoid the encoder
later on setting the M bit and hence avoid the peer receiving the Osmux
frame having to start a new syncrhonization point.
Related: SYS#6161
Change-Id: I9596501adf5b7b91983618c92c7b1792ee9461a3
So far only small intra-batch seqnum jumps are filled in with forged RTP
packets when storing the incoming RTP packets.
Under some conditions, holes may still exist in the queue of RTP packets
for a stream:
* Seqnum detected when first incoming RTP in batch is queued (this can
be improved in the future).
* Big seqnum jumps > batch_factor or simply filling out of bounds for currently
enqueued batch.
Specially the second case can come from long network dropouts, or simply
due to a bug in the RTP being feed to osmux layer (be it from local code
or peer). In that case (long jumps) we don't want to generate tons of
packets filling in several entire batches (potentially incredibly big
amount of batches).
Instead, in these scenarios, simply let the osmux peer know there was a
jump by setting the M bit on the next osmux header for that circuit
after the seq jump has been detected.
Related: SYS#6161
Change-Id: I05b1eae400cb60d1f4e927f853619d5ff470163f
osmux_link_add() is renamed to osmux_link_handle_rtp_req(), and the last
part of it is split out and kept as osmux_link_add().
hence osmux_link_handle_rtp_req() does proper input checking (like
duplicates, holes, etc.) while osmux_link_add() expects all that to be
sorted out.
Reuse osmux_link_add() in osmux_replay_lost_packets() to properly update
the link state of the to-be-transmitted packet, circuit state, etc.
Change-Id: I4ea435bfb2490a375ad3e5068ee926e48b53cf5c
This test shows that there's 2 bugs in the osmux_input code:
* It should be transmitting 2 osmux frames instead of 1
* Once it is fixed to transmitt 2 osmux frames, it should set the M bit of the 2nd
generated osmux header after the seqnum jump in order to announce a jump in the
stream to the peer receiving osmux.
The bugs are fixed in follow-up patches.
Related: SYS#6161
Change-Id: I521c2e97a739e8a824b16f06ec2a578333388247
When RTP packet provided by user to osmux layer, it may contain a seq
gap, and osmux will refill the packets to avoid losing that information
on the other side when it receives the batch.
If out of order UDP packets are received, it can happen that we first
detect a gap and later on we receive the previous RTP packet, which we
is then detected as duplicate because it was previously forged to fill
the hole. In that case, let's better keep the incoming packet instead of
the potentially internall forged one which doesn't contain the real AMR
payload.
Related: SYS#6161
Change-Id: I82e11ef3dcd20ffea33c94ed83abcedf0f186871
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: Ied224520b9a09743bd19818ab00cbdf915baef34
Replacing this one with the newer API was missed a few commits ago when
this API was marked as deprectated. Do it now.
Change-Id: Ia0958dfae951d82feafe427eff2112d327d3b0a4
It was not being used anywhere, yet older applications used to set it
(always to 0, which was the default value applied internally).
Let's make use of it and apply it as first seqnum to be used on a
circuit.
This value is applied upon call to osmux_xfrm_input_open_circuit(),
hence it can be set independently for every new circuit.
Change-Id: Ia26fcba5d7364a5744b2d64d0542a2b3880eee34
The wrap around case was not properly considered in the condition
setting the Marker bit. Let's fix it.
Related: SYS#5987
Change-Id: I6e01f29a6239f930c9be2bcb2efe447e5de8fedf
This test shows that there's a bug where the first RTP packet extracted
from the received osmux batch with seqnum=0 has the M bit marked for no
good reason.
Related: SYS#5987
Change-Id: Ida658c681e84878f209ab4965d8aa821a570a580
There's no real use in having a global seqnum. The seqnum, as specified
by the osmux protocol specification, relates to that of the RTP
seq+timestamp, hence it is per circuit.
Having it per circuit allows detecting gaps and lost batches on the
receiver side, applying the Marker bit on the re-assembled RTP packets.
As a resut of the fix, tests/osmux/osmux_test part validating Marker bit
started failing. It failed because it was wrongly written to start with,
since it used only one osmux_out_handle for the 4 CIDs in use, which was
wrong, since each CID must have its own osmux_out_handle as state is
kept there per circuit.
Related: SYS#5987
Change-Id: I562de6a871d8a35475c314ca107c2a12b55d6683
The value of the first RTP packet in the batch was being encoded,
instead of the last one (as documented in the Osmux protocol
specification).
Related: SYS#5987
Change-Id: I06f3d07a05181d938c22bbd0da7172b5dad6659a
That file focuses on testing the osmux_output_* API, ie receiving Osmux
frames and decoding it into batches and later on into rtp packets.
Change-Id: I7e6eda1e2e676673771bc6a7c3682d07ac1d344e
Let's not make the tests more difficult to maintain and extend by
allowing them to run in real clock time, there's no real need for it.
Change-Id: I549a4722d63d700b54b146260131a68e656b843e
According to API doc and implementation, it never returns >1.
Do as done in all other places where this API is used, that this check
for >0.
Change-Id: If23dfecb566f590b7a898356469df6e322f57653
Pau Espin
arehbein
Daniel Willmann
Vadim Yanitskiy
Harald Welte