On Thu, 2010-08-26 at 05:11 -0700, Bret McDanel wrote:
On Thu, 2010-08-26 at 13:19 +0200, Achim Stamm wrote:
Mathieu Rene schrieb:
Hi,
Lange nicht gesprochen. What can happen, usually, is network congestion causing a delay buildup over time (FS times its reads at every 20ms and returns a comfort noise frame if it can't get an RTP frame immediately). If frames come in 2-3 ms delayed because of congestion, delay can build up over time. If you are in a C module, you can send a message to the channel so it drops frames (essentially reads until EWOULDBLOCK).
I am unsure if your explanation is correct. If there is a delay of 2-3 ms 1 comfort noise frame should be generated (unless its doing discontinuous media), after that it should have a buffer built up of received frames so another delay of 2-3 ms would not cause an interleaving of CNG and audio (which would degrade call quality).
Have to agree with Bret here - the thing which causes noticeable delays to start to appear on long calls is a mismatch in clocks between two points on the chain. One end sending packets slightly faster than the other processes them will result in an indefinite buildup in delay over time, unless: - the jitter buffering's clever enough to notice this, and chuck packets away; - the sender has silence suppression on (as in send nothing, not send CNG frames), and the party at that end occasionally stops talking (cue mother-in-law joke) at which point things get back in sync; - (possibly) there's a non-zero amount of packet loss, and the receiver doesn't try to fill the gaps by duplicating previous packets. --Dave -- David Knell, Director, 3C Limited T: +44 20 3298 2000 E: dave@3c.co.uk W: http://www.3c.co.uk