[Asterisk-Dev] changing codec during call

[Steve Kann]

Race Vanderdecken wrote:

>The "jitter buffer" is used, and I might be wrong on the details of
>asterisk, to overlap information so that if a sound bite is lost it can
>make up the missing buffer from the extra information in the preceding
>and following buffers.
>  
>
(this is simplified a bit).
OK, presently, in asterisk, there's a jitter buffer on the receive side 
of IAX2, which is used hold frames long enough that it can reorder them 
if they are received out-of-order, and deliver them to the rest of the 
system with consistent timing (i.e. every 20ms).

The new jitterbuffer does this as well (with some improvements), but 
also can detect lost packets. When it receives a lost packet, it notes 
this, and sends this information down further into asterisk.

Further in asterisk, I've added (in patches, not applied), some 
facilities for "Packet Loss concealment", which basically tries to guess 
what the audio in the missing frame should sound like, given what we 
know about the previous frames.

>But that means more bits on the network, and that causes things to slow
>down more and then the buffers have to more work. It is like an
>overheated server that has to run the fan faster to cool the box, but
>running the fan faster uses more transformed power which causes more
>heat which requires the fan to run faster...
>  
>
Umm, I don't quite get your analogy, but there is no _extra_ information 
sent for any of this at the moment. The reconstruction (interpolation) 
of audio for lost frames is based entirely on past history, and 
knowledge of typical speech patterns. Basically, it's really not that 
smart, it just (smoothly) continues the same sound that was happening 
previously.


>Eventually the Laws of Thermodynamics apply to the amount of information
>you can push across the wire. If you are losing packets, then other
>packets have to carry more information to make up for the ones that get
>lost. But in communications theory the longer theh "packet" the greater
>time it is on the network and therefore the greater chance that it will
>be damaged by an event.
>
>If an event that damages packets happens once a second then any packet
>over a second with be damaged and have to be resent, but the smaller the
>packet the less chance it has of being damaged. And if it is damaged
>then less information is lost, so the error correction can be smaller.
>That is why the 1500 byte frames work better then 150,000 byte frames.
>The odds are just better. (yes, the math is simple, but you get the
>idea. Flame only if you have a good math example.)
>  
>

But line errors are generally not the cause for lost packets; congestion 
is a much more likely cause. And the choices that routers make for what 
to do when they see congestion vary, and are complex..

-SteveK