[Asterisk-Dev] changing codec during call

Race Vanderdecken asterisk at vanderdecken.com
Fri Feb 25 10:27:52 MST 2005


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.

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...

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.)

Also, asterisk is a bad example of a RTP conversation protocol users. A
human conversation is silence 1/3 of the time, and half duplex
communication the other 2/3's.  I talk, silence, you talk, silence, I,
silence, then you and so one. So in a real system the bandwidth is
mostly empty. Most of the time. During a full duplex conversation the
path from me to you is silence 2/3rds of the time, and with compression,
the actual audio data of value is probably on sucking up about 1/6 of
the bandwidth at a time. That is why compression works, most of the
audio is just dead air where you can squeeze in another conversation.
The 80K rule is when both of you are playing background music and
talking without listening to each to each other. Voice is not data, even
when it is converted to digital. (Please being you ranting now.)

Race "The Tyrant" Vandedecken


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Michael
Giagnocavo
Sent: Friday, February 25, 2005 11:12 AM
To: 'Asterisk Developers Mailing List'
Subject: RE: [Asterisk-Dev] changing codec during call

Not knowing much about this at all, I ask why wouldn't the jitterbuffer
handle this monitoring, as it has the most details of what's going on
(such
as packet loss, where switching to a packet-loss-friendly codec would be
a
good idea).

-Michael

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Jesse Kaijen
Sent: Friday, February 25, 2005 8:40 AM
To: asterisk-dev at lists.digium.com
Subject: [Asterisk-Dev] changing codec during call

Hello I'm a student and for my bachelor-assignment I'm looking into
VoIP.
I'm researching if the audio perceptive of the end-user will get higher
if
during a call a switch of codec is made.
I was wondering if it's possible to switch codec's during a call with
IAX.
Can someone help me on that?

This is the idea:
During a call with ulaw (64kb) the available bandwidth drops from 80kb
(sufficient) to 40kb for a longer period. The losses are great and the
call-quality is horrible. At that point changing codec to GSM for
instance
may result in a better quality. When the bandwidth is restored change
the
codec back. A monitor must listen after a jitterbuffer and then decide
to
change codec. 

Picture:
                        +----*asterisk*-----+
UA--->---->|---->up---->|--jitbuf---decoder-|--PSTN
UA---jitbuf|<---down<---|-----------encoder-|--PSTN
   ^                    +-------------------+
   |
 point where the monitor must listen

My question is (if possible) which command do I have to send during a
call
to switch codecs? And can the current iax-clients handle a codec change?

Greetings

Jesse Kaijen
jesse at kayen.nl


_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev





More information about the asterisk-dev mailing list