On 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.