FreeCalypso > hg > themwi-rtp-lib
comparison src/twjit.c @ 41:bda6b24385f7
twjit config: revisit default settings
The only actual change here is bumping the high water mark setting
from 2 to 3; the rest of this patch is comment changes.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Fri, 20 Dec 2024 22:13:01 +0000 |
| parents | 1485211d4492 |
| children | 334d883b96ba |
comparison
equal
deleted
inserted
replaced
| 40:d73b6ec27ae6 | 41:bda6b24385f7 |
|---|---|
| 14 #include <themwi/rtp/twjit.h> | 14 #include <themwi/rtp/twjit.h> |
| 15 | 15 |
| 16 void twrtp_jibuf_init_defaults(struct twrtp_jibuf_config *config) | 16 void twrtp_jibuf_init_defaults(struct twrtp_jibuf_config *config) |
| 17 { | 17 { |
| 18 memset(config, 0, sizeof(struct twrtp_jibuf_config)); | 18 memset(config, 0, sizeof(struct twrtp_jibuf_config)); |
| 19 config->bd_start = 2; /* smallest allowed */ | 19 |
| 20 config->bd_hiwat = 3; /* Nstart+1 is practically-useful minimum */ | 20 /* While the theoretical minimum starting fill level is 1, the |
| 21 config->thinning_int = 17; /* prime number, usually 340 ms */ | 21 * practically useful minimum (achieving lowest latency, but not |
| 22 config->max_future_sec = 10; /* 10 s is a long time for voice */ | 22 * incurring underruns in normal healthy operation) is 2 for typical |
| 23 * network configurations that combine elements with "perfect" 20 ms | |
| 24 * timing (T1/E1 interfaces, external IP-PSTN links, software | |
| 25 * transcoders timed by system clock etc) and GSM-to-IP OsmoBTS | |
| 26 * whose 20 ms timing contains the small inherent jitter of TDMA. */ | |
| 27 config->bd_start = 2; | |
| 28 | |
| 29 /* The high water mark setting determines when the standing queue | |
| 30 * thinning mechanism kicks in. A standing queue that is longer | |
| 31 * than the starting fill level will occur when the flow starts | |
| 32 * during a network latency spike, but then the network latency | |
| 33 * goes down. If this setting is too high, deep standing queues | |
| 34 * will persist, adding needless latency to speech or CSD. | |
| 35 * If this setting is too low, the thinning mechanism will be | |
| 36 * too invasive, needlessly and perhaps frequently deleting a quantum | |
| 37 * of speech or data from the stream and incurring a phase shift. | |
| 38 * Starting fill level plus 2 seems like a good default. */ | |
| 39 config->bd_hiwat = 4; | |
| 40 | |
| 41 /* When the standing queue thinning mechanism does kick in, | |
| 42 * it drops every Nth packet, where N is the thinning interval. | |
| 43 * Given that this mechanism forcibly deletes a quantum of speech | |
| 44 * or data from the stream, these induced disruptions should be | |
| 45 * spaced out, and the managing operator should also keep in mind | |
| 46 * that the incurred phase shift may be a problem for some | |
| 47 * applications, particularly CSD. Our current default is | |
| 48 * a prime number, reducing the probability that the thinning | |
| 49 * mechanism will interfere badly with intrinsic features of the | |
| 50 * stream being thinned. 17 quantum units at 20 ms per quantum | |
| 51 * is 340 ms, which should be sufficiently long spacing to make | |
| 52 * speech quantum deletions tolerable. */ | |
| 53 config->thinning_int = 17; | |
| 54 | |
| 55 /* With RTP timestamps being 32 bits and with the usual RTP | |
| 56 * clock rate of 8000 timestamp units per second, a packet may | |
| 57 * arrive that claims to be as far as 3 days into the future. | |
| 58 * Such aberrant RTP packets are jocularly referred to as | |
| 59 * time travelers. Assuming that actual time travel either | |
| 60 * does not exist at all or at least does not happen in the | |
| 61 * present context, we reason that when such "time traveler" RTP | |
| 62 * packets do arrive, we must be dealing with the effect of a | |
| 63 * software bug or misdesign or misconfiguration in whatever | |
| 64 * foreign network element is sending us RTP. In any case, | |
| 65 * irrespective of the cause, we must be prepared for the | |
| 66 * possibility of seeming "time travel" in the incoming RTP stream. | |
| 67 * We implement an arbitrary threshold: if the received RTP ts | |
| 68 * is too far into the future, we treat that packet as the | |
| 69 * beginning of a new stream, same as SSRC change or non-quantum | |
| 70 * ts increment. This threshold has 1 s granularity, which is | |
| 71 * sufficient for its intended purpose of catching gross errors. | |
| 72 * The minimum setting of this threshold is 1 s, but let's | |
| 73 * default to 10 s, being generous to networks with really bad | |
| 74 * latency. */ | |
| 75 config->max_future_sec = 10; | |
| 23 } | 76 } |
| 24 | 77 |
| 25 /* create and destroy functions */ | 78 /* create and destroy functions */ |
| 26 | 79 |
| 27 struct twrtp_jibuf_inst * | 80 struct twrtp_jibuf_inst * |
