This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Hans Peter Freyther holger at freyther.deOn Fri, Nov 22, 2013 at 09:59:10AM +0100, Jacob Erlbeck wrote: > We can, but then I would like to put all of the above into the rtp_end > structure. sure. > > state->patch is most likely 0 here but we do patch things. > > I don't know what you mean exactly, in the test case allow_patch is > explicitely set. Or do you mean in the wild? Now. this is what I missed then. I git grepped my local tree for allow_patch but didn't look into patch 2. > Currently (with and without the patch) the packet is only patched after > SSRC changes. It was my understanding that the TS issue we were seing also appeared without a change in the SSRC? In case this is something I asked you to do after this patch we can postpone this discussion. > just based on heuristics and may fail theoretically. SCNR: And in theory ip.access should be able to create working software with the capital they received. ;) > > If the SSRC changes when SSRC patching is disabled there is (in theory) > no need to patch timestamps, since the receiver has to reinitialize > timing anyway. true. The reason we patch the SSRC is that the nanoBTS software does not re-initialize the state. > What do you think? I would like to understand if the TS problem only occurs when the TS is changing or if the ts_delta issue is only introduced by the patching I do.