Bug #3185
closedOsmux: lost osmux frames not reflected in re-generated rtp and generates increasing delay
100%
Description
New unit tests I'm preparing for Osmux show that on the osmux receiveing side, when an osmux packet is lost (ie. we receive osmux seq=N, then seq=N+2) we don't notify/mark the generated RTP stream accordingly.
As a result, from the rtp receiver point of side, it looks like nothing strange happened, but then delay increments constantly in batch_factor*20ms.
+===test_output_frame_lost=== +sys={0.000000}, mono={0.000000}: clock_override_set +sys={0.000000}, mono={0.000000}: first osmux frame +sys={0.000000}, mono={0.000000}: dequeue: seq=50 ts=500 enqueued=5 +sys={0.100000}, mono={0.100000}: clock_override_add +sys={0.100000}, mono={0.100000}: dequeue: seq=51 ts=660 enqueued=4 +sys={0.100000}, mono={0.100000}: dequeue: seq=52 ts=820 enqueued=3 +sys={0.100000}, mono={0.100000}: dequeue: seq=53 ts=980 enqueued=2 +sys={0.100000}, mono={0.100000}: dequeue: seq=54 ts=1140 enqueued=1 +sys={0.100000}, mono={0.100000}: dequeue: seq=55 ts=1300 enqueued=0 +sys={0.100000}, mono={0.100000}: one osmux frame is now lost (seq++) +sys={0.220000}, mono={0.220000}: clock_override_add +sys={0.220000}, mono={0.220000}: 3rd osmux frame arrives +sys={0.220000}, mono={0.220000}: dequeue: seq=56 ts=1460 enqueued=5 +sys={0.320000}, mono={0.320000}: clock_override_add +sys={0.320000}, mono={0.320000}: dequeue: seq=57 ts=1620 enqueued=4 +sys={0.320000}, mono={0.320000}: dequeue: seq=58 ts=1780 enqueued=3 +sys={0.320000}, mono={0.320000}: dequeue: seq=59 ts=1940 enqueued=2 +sys={0.320000}, mono={0.320000}: dequeue: seq=60 ts=2100 enqueued=1 +sys={0.320000}, mono={0.320000}: dequeue: seq=61 ts=2260 enqueued=0
As the batch_factor for the lost packet is unknown, we cannot assume any number of amr payloads lost, and thus we cannot simply increment seq and timestamp for a specific amount. Instead, the only viable solution seems to set the M marker bit in the first rtp packet generated after a non-consecutive osmux frame is received.
This way the RTP receiver can sync on that packet and avoid having a constantly increasing delay over time.
Updated by pespin about 6 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 90
Fixed by https://gerrit.osmocom.org/7871
Updated by pespin almost 6 years ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Merged, closing