[Asterisk-Dev] changing codec during call

[Steve Kann]

Race Vanderdecken wrote:

>Detecting the the bandwidth constraint constraint might be possible
>using RTCP. http://www.nwfusion.com/news/tech/2003/1117techupdate.html
>
>I have not looked to see if Asterisk is using RTCP, but that would be
>the correct way to control and detect.
>  
>

IAX2 now supports sending all of the parameters that are described in 
the _extended_ RTCP XR stuff you quote there (the basic RTCP RR does not 
support all of this).

But I still fail to see how you can determine from this information 
alone, whether reducing your bandwidth usage by 5kbps or whatever is 
going to affect the call quality in a positive or negative way.

Certainly, it would be good network policy for us to lower our 
consumption when we see congestion (like TCP does), but it is not 
necessarily going to improve the quality of our call.

-SteveK



>Race "The Tyrant" Vanderdecken
>
>-----Original Message-----
>From: asterisk-dev-bounces at lists.digium.com
>[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Steve Kann
>Sent: Friday, February 25, 2005 12:04 PM
>To: Asterisk Developers Mailing List
>Subject: Re: [Asterisk-Dev] changing codec during call
>
>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
>
>_______________________________________________
>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
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050225/80495a83/attachment.htm