RTP Payload Format for the G.729.1 Audio Codec
Note: This ballot was opened for revision 07 and is now closed.
(Cullen Jennings) (was Discuss, Yes) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Brian Carpenter) (was Discuss) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
Comment (2006-07-17 for -** No value found for 'p.get_dochistory.rev' **)
Section 7., paragraph 1: > Congestion control for RTP SHALL be used in accordance with RFC 3550 >  and any appropriate profile (for example, RFC 3551 ). 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."
(Bill Fenner) No Objection
(Ted Hardie) (was Discuss) No Objection
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 , 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?