[Asterisk-Dev] changing codec during call

[Jesse Kaijen]

Just had my dinner and look at all the reactions! :P
Thanks!

> Steve Underwood wrote:
>
>> Steve Kann wrote:
>>
>>> 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.
>>
>>
>> High packet loss rate, or even high jitter, might give us a clue that 
>> a lower bit rate would be beneficial. 
>
> If you read my previous message on the topic, depending on the location 
> of the congestion, it might just make things worse.
>
> If the congestion is a very low bandwidth last-hop, it might help.  But 
> if the congestion is on a high-bandwidth link (and caused by other 
> applications, or even line errors), it will just make things sound 
> worse.   For example, imagine that the loss is on some 45mbps link in 
> the middle of the internet, being caused by some network-unfriendly 
> application.  If we lower our bandwidth consumption, it's unlikely to 
> make any difference at all in the loss rate.  However, it will probably 
> make the loss _more_ noticable to the user, and not less noticable.  
> (i.e. going from 20ms uLaw frames, to 60ms highly-compressed frames will 
> probably end up causing the same loss percentage to be much more 
> noticable, and more difficult to conceal).
>
Well here's the deeper problem I'm going to investigate. And try to solve.
If I can't solve the problem or a monitor makes it worse than that research
is also of great value. Guessing what is better won't solve the discussion.
Some lab-tests already gave as result that changing codec to often (6 times
in 8 sec) lowers the MOS-value. And the user hears some clicking (DUH!). 
Having a adaptive jitterbuffer is certainly better for the MOS than changing
codec. But that's not what I want. I want to combine these solutions to get
an even higher result.
The reason I like to use the IAX-protocol is that the new jitterbuffer is
based on the E-MOS algorithm (PLEASE CORRECT ME IF I'M WRONG). **see_below**
Also the JB_reports are getting send which are quite handy for monitoring.

So far the only problem I have is changing codec during a call. I hope the
option of opening a second call isn't the solution. Because making the call
to the PSTN doesn't give you the option to 'open' a new call and close the
other.

If I have that problem solved and let a call change codec in a neat way, I
will work on the monitor and ask your opinion on that one quite often I'm
sure of that.

>> I have no idea how to meaningfully determine that a higher bit rate 
>> would be harmless. Probing with the higher rate every time the loss 
>> and jitter are low is quite likely to cause far too much juggling of 
>> rates.
>
> 
> There's a lot of research on this kind of stuff out there for TCP 
> behavior and algorithms.   If we wanted to make our protocol 
> network-friendly, we would definately slow down our rates when we saw 
> loss, to do congestion-avoidance like TCP does.  But I'm not sure we 
> want our VoIP streams to be as nice as TCP is, because in general, the 
> VoIP streams are going to be considered a higher priority in the 
> network.  (And surely, those RTP streams that fight against IAX sure 
> aren't going to slow down!).
>
> -SteveK

**see_below**
Adaptive Playout Buffer Algorithm for Enhancing Perceived Quality of
Streaming Applications.