Re: [codec] #17: Feedback and control loop?

"codec issue tracker" <> Sun, 02 May 2010 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F6EE3A68A7 for <>; Sun, 2 May 2010 11:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.169
X-Spam-Status: No, score=-101.169 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9t4XKyBtpMik for <>; Sun, 2 May 2010 11:08:23 -0700 (PDT)
Received: from (unknown [IPv6:2001:1890:1112:1::2a]) by (Postfix) with ESMTP id 815FD3A6B1B for <>; Sun, 2 May 2010 11:08:17 -0700 (PDT)
Received: from localhost ([::1] by with esmtp (Exim 4.69) (envelope-from <>) id 1O8daF-0003nv-CW; Sun, 02 May 2010 11:08:03 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
X-Trac-Project: codec
Date: Sun, 02 May 2010 18:08:03 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 17
In-Reply-To: <>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [codec] #17: Feedback and control loop?
X-Mailman-Version: 2.1.9
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 May 2010 18:08:26 -0000

#17: Feedback and control loop?
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     

Comment(by hoene@…):

 Requirement: Reliable on the Internet

    The ACS must be optimized towards acoustic real-time communications
    over the Internet, and must have the flexibility to adjust to the
    environment it operates in. Based on the quality of the end-to-end
    speech packet transmission, the codec should adapt its quality and
    delay to achieve an optimal benefit for the user.

    As most Internet transport, it should be used with a wide range of
    condition allowing a high reliability regardless the networking
    condition. The reliability of the audio transmission should be high,
    even in cases of low and varying bandwidth. This implies that the
    codec is used on top of a transport protocol that implements a
    congestion control algorithm and that the ACS adapts to changes of
    available bandwidth. For example, if the available transmission
    bandwidth is too low to allow the codec to transmit audio at a high
    quality, the application can lower the sampling, bit or frame rate of
    the stream at the cost of higher algorithmic delay or a degraded
    audio quality.

 Reiability and congestion control :

    The acoustic transmission should be reliable and robust. The ACS
    shall be not only robust against packet losses but also for periods
    of low bandwidth.

    The mean availability of the audio transmissions, calculated over all
    users, might be one of the metrics for assessing the performance of
    an Internet audio codec.

    The ACS should adapt to the current network situation. Also, the
    codecs of ACS themselves must be adaptable, because switching among
    multiple codecs is difficult to negotiate and unlikely to work well
    in situations of inter-operation.

    Responding to congestion is a more complex issue and out of the scope
    of this document. However, it shall be defined on how to use existing
    congestion control protocols like DCCP and TCP. The ACS shall provide
    the mechanisms that congestion control requires from the codec (i.e.
    bitrate/framerate adaptability).

    Because of the interactive nature of the acoustic transmission, the
    bidirectional transmission of audio content can be used for
    transmitting the required feedback and implementing a control loop.

 Side channel

    Congestion control should be must for all Internet applications also
    for the ACS. [RFC3550] suggests in Chapter 10 somewhere that the RTP
    profile should care for rate adaptation. Thus, the ACS should take
    advantage of a feedback loop for variable coding parameter control in
    order to allow a wide range of operation and to adapt to the the
    current available bandwidth and processing power.

    Congestion control per se is outside the review of this group, but
    providing the hooks for a congestion-control mechanism to interact
    with the codec is quite important. For example, running this codec on
    a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be able to
    adjust (via the application) the bitrate of the codec in order to
    implement congestion control and perhaps adjust packetization

    A side channel for adaptation can be added. This would make sense
    because in usage scenarios audio is always transmitted in both
    directions. Adding a control channel would give a real advantage to
    existing codec designs. Alternatively, such as side channel can be
    also added with alternative solutions, such as handling that
    communication in SIP/SDP and in RTP/RTCP.

Ticket URL: <>
codec <>