Attention is currently required from: falconia.

View Change

1 comment:

• File src/twjit.c:

  • Patch Set #2, Line 504: rtph = osmo_rtp_get_hdr(msg);

    this smooth packet flow will be delivered to the fixed timing application perfectly in order, without any disruptions - and I argue that this behavior is the best

    In here you are assuming that with an M bit set and no gap in the timestamp sequence means the data just be placed in sequence, which doesn't need to be necessarily the case. IMHO it makes more sense to apply handover since the newer flow after the M bit is the current one, which should take precedence over the old one. Otherwise it's like keep playing soft noise or music while there's already talk waiting to be played.

    With my current algorithm, the duration of the gap delivered to the fixed timing application will be exactly what the RTP sender indicated in its timestamps

    No, it won't, because iiuc, due to the M bit, the timestamps before and after it are non-related. The fact that they may have some gap or not may be totally circumstantial.

    So to me you are treating the case where the new supposedly randomly taken tiemstamp (due to M bit) is in the 160-sequence different than the other 159 cases.

To view, visit change 39280. To unsubscribe, or for help writing mail filters, visit settings.