<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Race Vanderdecken wrote:
<blockquote cite="mid019c01c51b5f$c3858e00$6401a8c0@PressonMobile1"
 type="cite">
  <pre wrap="">Detecting the the bandwidth constraint constraint might be possible
using RTCP. <a class="moz-txt-link-freetext" href="http://www.nwfusion.com/news/tech/2003/1117techupdate.html">http://www.nwfusion.com/news/tech/2003/1117techupdate.html</a>

I have not looked to see if Asterisk is using RTCP, but that would be
the correct way to control and detect.
  </pre>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
-SteveK<br>
<br>
<br>
<br>
<blockquote cite="mid019c01c51b5f$c3858e00$6401a8c0@PressonMobile1"
 type="cite">
  <pre wrap="">
Race "The Tyrant" Vanderdecken

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:asterisk-dev-bounces@lists.digium.com">asterisk-dev-bounces@lists.digium.com</a>
[<a class="moz-txt-link-freetext" href="mailto:asterisk-dev-bounces@lists.digium.com">mailto:asterisk-dev-bounces@lists.digium.com</a>] 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:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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
    </pre>
  </blockquote>
  <pre wrap=""><!---->(such
  </pre>
  <blockquote type="cite">
    <pre wrap="">as packet loss, where switching to a packet-loss-friendly codec would
    </pre>
  </blockquote>
  <pre wrap=""><!---->be a
  </pre>
  <blockquote type="cite">
    <pre wrap="">good idea).

-Michael

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:asterisk-dev-bounces@lists.digium.com">asterisk-dev-bounces@lists.digium.com</a>
[<a class="moz-txt-link-freetext" href="mailto:asterisk-dev-bounces@lists.digium.com">mailto:asterisk-dev-bounces@lists.digium.com</a>] On Behalf Of Jesse
    </pre>
  </blockquote>
  <pre wrap=""><!---->Kaijen
  </pre>
  <blockquote type="cite">
    <pre wrap="">Sent: Friday, February 25, 2005 8:40 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:asterisk-dev@lists.digium.com">asterisk-dev@lists.digium.com</a>
Subject: [Asterisk-Dev] changing codec during call

Hello I'm a student and for my bachelor-assignment I'm looking into
    </pre>
  </blockquote>
  <pre wrap=""><!---->VoIP.
  </pre>
  <blockquote type="cite">
    <pre wrap="">I'm researching if the audio perceptive of the end-user will get higher
    </pre>
  </blockquote>
  <pre wrap=""><!---->if
  </pre>
  <blockquote type="cite">
    <pre wrap="">during a call a switch of codec is made.
I was wondering if it's possible to switch codec's during a call with
    </pre>
  </blockquote>
  <pre wrap=""><!---->IAX.
  </pre>
  <blockquote type="cite">
    <pre wrap="">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
    </pre>
  </blockquote>
  <pre wrap=""><!---->instance
  </pre>
  <blockquote type="cite">
    <pre wrap="">may result in a better quality. When the bandwidth is restored change
    </pre>
  </blockquote>
  <pre wrap=""><!---->the
  </pre>
  <blockquote type="cite">
    <pre wrap="">codec back. A monitor must listen after a jitterbuffer and then decide
    </pre>
  </blockquote>
  <pre wrap=""><!---->to
  </pre>
  <blockquote type="cite">
    <pre wrap="">change codec. 

Picture:
                       +----*asterisk*-----+
UA---&gt;----&gt;|----&gt;up----&gt;|--jitbuf---decoder-|--PSTN
UA---jitbuf|&lt;---down&lt;---|-----------encoder-|--PSTN
  ^                    +-------------------+
  |
point where the monitor must listen

My question is (if possible) which command do I have to send during a
    </pre>
  </blockquote>
  <pre wrap=""><!---->call
  </pre>
  <blockquote type="cite">
    <pre wrap="">to switch codecs? And can the current iax-clients handle a codec
    </pre>
  </blockquote>
  <pre wrap=""><!---->change?
  </pre>
  <blockquote type="cite">
    <pre wrap=""> 

    </pre>
  </blockquote>
  <pre wrap=""><!---->
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:

&lt;server&gt; (100mbps ethernet) &lt;router&gt; (T3 or something) &lt;lots of routers 
and hops&gt; (DSL/modem) &lt;client&gt;.

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
<a class="moz-txt-link-abbreviated" href="mailto:Asterisk-Dev@lists.digium.com">Asterisk-Dev@lists.digium.com</a>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>


_______________________________________________
Asterisk-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Asterisk-Dev@lists.digium.com">Asterisk-Dev@lists.digium.com</a>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>

  </pre>
</blockquote>
<br>
</body>
</html>