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
Until now, the osmux_out_handle was allocated by the client, and passed
to the API to initialize it. This makes it really hard to improve the
implementation without breaking the ABI.
Let's break the ABI now one last time (hopefully) by allocating the
struct through an API. With only this change, the already built users
(osmo-mgw, openbsc) can still work fine, since there's no change on the
struct osmux_out_handle. However, they will somehow break next time the
struct is changed until they are ported to the same API (easy to do).
Related: OS#5987
Change-Id: Ie8df581f375c9a183a7af60b431561bda82f6e34
The functions that convert between octet-aligned and bandwith-efficient
AMR format have good coverage on the octet-aligned side, but the
bandwith-efficient side has a very little number of sample packets. Lets
add some more sample packets to increase coverage.
Related: SYS#5834
Change-Id: I53bd574e1ce7349419553e3957fff19e81567b93
The check was wrong for format types containing extra bits not aligned
to byte boundaries, such as FT7 (AMR Code 12.20, 244 bits, 31 bytes).
if the source has 1-6 extra bits, they can be fit with one less byte
when shifting 10 bits to the left.
Change-Id: I0552d727585886d25f613e64ca815fb6dcd53f25
The proper order is CMR(4)+F(1)+FT(4)+Q(1).
Hence, FT is 3 least significant bits of first byte and 1 most
significant bit of secont byte.
Change-Id: I66f39d3b9a608f07c202e7a5084a8537e9978a94
These APIs allow for easy re-formatting of received AMR to forward
between regular RTP and IuUP.
Related: OS#1937
Change-Id: Id2bd32d5f2060abe581730996dc4251381bf7d4f
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: Ia4bcf8dc441ad26cffc3aec5b374fbdca4a03841
Related: OS#5034
The for loop in osmo_amr_bwe_to_oa, that converts the body part of the
AMR payload runs one byte too far. This may cause that some of the
padding bits in the end are not set to zero. The loop is designed to
convert n-1 bytes and the nth byte is done separately at the end.
Change-Id: I91e755b83aaac722079879c026d913cc446812d1
arehbein
Pau Espin
Daniel Willmann
Vadim Yanitskiy
Harald Welte
Philipp Maier