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/.
Jacob Erlbeck jerlbeck at sysmocom.deOn 11/21/2013 08:40 PM, Holger Hans Peter Freyther wrote: > On Thu, Nov 21, 2013 at 07:05:45PM +0100, Jacob Erlbeck wrote: >> +/* Assume audio frame length of 20ms */ >> +#define RTP_AUDIO_FRAME_DUR_NUM 20 >> +#define RTP_AUDIO_FRAME_DUR_DEN 1000 >> +#define RTP_AUDIO_DEFAULT_RATE 8000 > > can't we initialize the rate in mgcp_rtp_end_init or such? This way > we know that this is either default or (read from the SDP file). We can, but then I would like to put all of the above into the rtp_end structure. > > >> state->patch = endp->allow_patch; >> -TS: 2040, dTS: 160, TS Errs: in 5, out 6 >> +TS: 1880, dTS: 160, TS Errs: in 5, out 5 > > 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 we might > want to fix the tsdelta in all cases but then I think we should rename > state->patch to state->patch_ssrc (or state->patch_stream_change)? > > what do you think? > Currently (with and without the patch) the packet is only patched after SSRC changes. Do you mean, that you would like to add a feature to always patch timestamps, even when the is no SSRC change? I'm not shure about the audio profiles that are to be expected, but rfc4867 allows for a lot of inconviniences w.r.t. packet durations (e.g. multiple frames per packet for a single channel). Even changing the offset after SSRC changes is just based on heuristics and may fail theoretically. 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. So I conclude we have four options concerning patching: 1. Do nothing (offset is always 0) 2. Update the offset on SSRC changes and fix the SSRC 3. Check timestamps and fix them unless the SSRC changes (which is not fixed) 4. Fix SSRC and update the offset on all (detected) timestamp errors This can be divided into 2 orthogonal aspects: A. When the SSRC changes: Fix or don't fix the SSRC (including updating the offset on SSRC changes) B. When the SSRC does not change: Monitor the stream (per SSRC) for (suspected) timestamp errors and update the offset if an error is detected If the receiver was able to handle SSRC changes, we could also do the reverse to fix broken timimngs: change the SSRC on each detected timing problem. Anyway, in case B if there is a single packet in the stream which contains a different number of frames, the timing will be broken after that. So we can either a. forbid that and count packet size changes, b. disable offset updates when the packet size changes, or c. use everything we get from SDP, parse into AMR or whatever audio codec is used to determine the packet duration and use that for verification. What do you think? Jacob