Project

General

Profile

Actions

Bug #6169

open

Frame masking against network frame ordering, not frame numbers

Added by manawyrm 6 months ago. Updated 5 months ago.

Status:
New
Priority:
High
Assignee:
Category:
octoi
Target version:
-
Start date:
09/06/2023
Due date:
% Done:

0%

Spec Reference:

Description

The osmo-e1d code includes functionality to save bandwidth by not transmitting timeslots, which haven't changed since the last frame.

https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263

Later in development, the frame_rifo was introduced to combat packet reordering in real-world networks (like DOCSIS).
The code unpacking the timeslots into full E1 frames is currently unpacking against the last frame in the incoming buffer, not the last frame in the RIFO (random in, first out) buffer.
This means that frames will get filled with random data from other frames in the event of a re-ordering.

Unpacking/Unmasking should be done after the RIFO mechanism.

Actions #1

Updated by manawyrm 6 months ago

I have written a preliminary patch, which moves the unmasking logic after the RIFO code:
https://gitea.osmocom.org/Manawyrm/osmo-e1d/commit/63a9f490d75987e396f80aea1b17d5ca560ec230
(currently with broken unit tests and probably unclean?)

In my testing, this seems to behave correctly whenever reordering occurs.

Actions #2

Updated by manawyrm 6 months ago

Random idea: Would it be helpful to send "full" frames every 100ms (or 500 frames) or so? Similar to keyframes in video codecs...
Not sure if that would have any positive impact on devices.

Actions #3

Updated by laforge 5 months ago

  • Assignee set to laforge
  • Priority changed from Normal to High
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)