-
With this patch, we try to make more explicit the process order between the different types of stun requets, according that only one request is sent per callback timer tick, ie every 20ms, to respect the stun pacing of the spec. We implement the follow priority: * triggered checks * stun retransmissions * ordinary checks In a concrete case, while a stream has stun requests related to triggered checks to be sent, all other stun transactions are delayed to the next timer ticks. The goal of this patch is to make this priority explicit, and more easily swappable if needed. Triggered checks have more probability to succeed than stun retransmissions, this is the reason why they are handled before. Ordinary checks on the contrary can be performed on a lower priority basis, after all other stun requests. The problem that can be sometime observed with a large number of stun transactions is that stun retransmissions may suffer from a delay after they have reached their deadline. This delay should remain small thanks to the design of the initial retransmission timer (RTO), that takes into account the overall number of scheduled stun requests. It allows all stun requests to be sent and resent at a predefined "pacing" frequency without much extra delay. This ordering not perfect, because stun requests of a given type are examinated per-stream, by looking at the first stream before the others, so it introduces a natural priority for the first stream.
90c21bf9
