[Asterisk-Dev] changing codec during call

[Steve Kann]

Michael Giagnocavo wrote:

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

I've thought about this a bit already.

1) I'm pretty sure the iaxclients could handle the change, although it's 
not really tested. By design, it should be OK.

2) If bandwidth is constrained, a more useful way to lower bandwidth 
consumption is often to just use larger frames; i.e. instead of sending 
20ms frames (with like 13kbps overhead), send 60ms frames with (13/3 =) 
4.1kbps overhead. Especially if you're already using a good codec, like 
Speex ABR, you really can't go much lower..

3) The issue is detecting the bandwidth constraint. I don't think it's 
trivial to discover (unless you use trial and error, I guess), that the 
cause of packet loss is a bandwidth constraint that this change will 
have any effect on. For example, your packets might take this route from 
server to client:

<server> (100mbps ethernet) <router> (T3 or something) <lots of routers 
and hops> (DSL/modem) <client>.

If you see loss, it could be from the last hop (the DSL or modem), where 
changing codecs might help. But it _could_ be from the T3 (45Mbps) being 
congested, in which case changing your codec won't make a bit of 
difference for your call, and, will probably make things worse. In that 
case, you probably want to actually send _more_ bits, by using FEC or 
some other means of redundancy to improve the effective loss ratio..

-SteveK