Bug #2440

Updated by pespin over 3 years ago

With current implementation, only up to a maximum of 6-7 rtp lost packets can be replayed in best-case scenario. In other scenarios, big gaps can easily occur, for instance if a lot of packets are lost when the current batch is still empty.

If we forget to replay some lost RTP packets, then those are not taken into account in the Osmux stream, which means sequence numbers and timestamps will become different when Osmux re-generates the frames into RTP packets on the other side, and some receivers may not play nice with this jumps in time, eg. audio delays.

This new implementation [1] tries to maintain status on the whole circuit level rather than only on current batch. To simplify things, it clones payload from latest packet to enqueue rather than last previosuly packet enqueued.

After this patchset is merged, issue #2439 should be easy and helpful to implement.


With the current branch I'm facing the following issue:
The call starts correctly and I see both sides sending Osmux, ie A->B:UDP[CID A->B:UDP(CID 0, CID 1] 1) and B->A:UDP[CID B->A:UDP(CID 0, CID 1]. 1). However, sometimes, at some point during the call some legs start falling, in the sense that I cannot see one or more of the CID being sent anymore in one or both direction. Some examples I can end up with so far:

* A->B:UDP[CID 0] A->B:UDP(CID 0) + B->A:UDP[CID B->A:UDP(CID 0, CID 1] 1)
* A->B:UDP[CID 1] A->B:UDP(CID 1)
* A->B:UDP[CID 1] A->B:UDP(CID 1) + B->A:UDP[CID 1] B->A:UDP(CID 1)


Add picture from clipboard (Maximum size: 48.8 MB)