[Asterisk-Dev] changing codec during call

[Steve Underwood]

Steve Kann wrote:

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

I fully realise this. That' why I said "clue" rather than something like 
"solid indication" :-) If you could work out that the bandwidh in use is 
too like to flood the local tributary, you could double every packet, or 
send overlapping packets, in a fight with the other users of the main 
channel. Evil, but possibly self-beneficial. :-)

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

I don't this any of that TCP stuff has much meaning for streaming.

Regards,
Steve