RTP Payload Format for the G.729.1 Audio Codec
draft-ietf-avt-rtp-g729-scal-wb-ext-07

Section 7., paragraph 1:

>    Congestion control for RTP SHALL be used in accordance with RFC 3550
>    [3] and any appropriate profile (for example, RFC 3551 [4]).  The
>    embedded and variable bit rates capability of G.729.1 provides a
>    mechanism that may help to control congestion, see Section 3.

  I'd be good if the draft would elaborate on a mechanism for this a bit
  more. May be something along the lines of: "When operating over a
  best-effort network, the codec SHOULD use the embedded and variable
  bit rates capability of G.729.1 in response to monitored packet loss
  events, such that the bandwidth use of a flow is not more than of a
  TCP flow along the same network path under the same network
  conditions."

Cullen will be tracking this issue from now on; here's the text of my original
DISCUSS, so it is easy for him to follow:



I found the draft's discussion of DTX somewhat under-specified.  The draft currently says:

  G.729.1 will be first released without support for DTX.  Anyway, this
  functionality is planned and will be defined in a separate annex
  later.  Thus this specification provides DTX signalling, even if the
  size and content of a SID frame are not yet standardized.

and:

dtx: indicates that discontinuous transmission (DTX) is used or
      preferred.  DTX means voice activity detection and non
      transmission of silent frames.  Permissible values are 0 and 1. 0
      means no DTX. 0 is implied if this parameter is omitted.  The
      first version of G.729.1 will not support DTX, but future annexes
      are expected to add DTX support which can be signalled using this
      parameter.


I assume the future annexes are updates to [1], not to this document, but a direct statement on this would be useful. 

I think I understand how the transition works in offer/answer mode.  If a receiver has and understands g7291 without support for DTX and receives DTX as an optional parameter, its lack of such a parameter in its response deactivates it in both direction.  But how does it work in declarative mode.  The draft says:  

      The "maxbitrate" and "dtx" parameter become declarative and MUST
      NOT be negotiated.  These parameters are fixed, and a participant
      MUST use the configuration that is provided for the session.

Is it just assumed that these will not be used in declarative situations unless support for the DTX mechanism has become general?  Is there some other mechanism at work her to manage the transition?