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.