Attention is currently required from: pespin. falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email ) Change subject: bring twjit into libosmo-netif ...................................................................... Patch Set 5: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/62e74621_c69d26c… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); I still disagree. To see why, let us consider a scenario in which you (presumably) believe checking M bit would make a difference. This purported scenario would have to have these two properties: * SSRC stays the same, or else twjit would consider it a handover; * All timestamp increments are integral multiples of 160, for the same reason; * Sequence number does not matter at all, as twjit does not look at it except for staff-oriented counters and RTCP-mandated analytics - it does not affect any of twjit's actual decisions. With the above prerequisites established, the next question is: gap or no gap? Consider the no-gap case first: there is a perfectly smooth, uninterrupted flow of RTP packets, but one of them has M bit set. With current code, 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. Your proposal of treating M bit as handover would cause twjit state transition to HANDOVER, which would result either in some packets before the handover event being dropped if the new flow becomes ready (flow start criteria) soon enough, or in a gap (not present in the incoming stream) being fed to the output if the old flow underruns before the new one is ready. How would such behavior be any better than what I have currently? Now consider M bit preceded by a gap: some packets omitted, then an RTP packet with M bit set. Here the question becomes: underrun or no underrun? If the gap is long enough for twjit to experience an underrun before the flow resumes, then it makes no difference whether the flow-resuming packet has M bit set or not: twjit is starting from EMPTY state in this case. Now consider the no-underrun case: the configured buffer depth is high enough, and the gap short enough, to where the flow-resuming packet arrives before the buffer underruns. 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; with your proposed modification, the gap would be unpredictably lengthened or shortened based on how long it takes for the post-handover flow to reach ready state. How is your way any better? In summary, I still fail to see *even one* scenario in which your proposed modification to my core algorithm would make an improvement. -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658 Gerrit-Change-Number: 39280 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 17:58:50 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>