Document: draft-ietf-avt-rfc4749-dtx-update-01 Reviewer: Spencer Dawkins Review Date: 22-09-2008 IETF LC End Date: 19-09-2008 IESG Telechat date: (if known) Summary: This document is almost ready for publication as Proposed Standard. I have a small number of questions, marked as "(review)". Comments: 2. Background G.729.1 supports Discontinuous Transmission (DTX), a.k.a. silence suppression. It means that the coder includes a Voice Activity Spencer (clarity): could you put "silence supression" in quotes here? Detection (VAD) algorithm, to determine if an audio frame contains silence or actual audio. During silence periods, the coder may significantly decrease the transmitted bit rate by sending a small frame called Silence Insertion Descriptor (SID), and then stop transmission. The receiver's decoder will generate comfort noise (CNG) according to the parameters contained in the SID. This DTX/CNG scheme is specified in [ITU-G.729.1-C]. 3. RTP Header Usage If DTX is used, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the M Spencer (review): why not MUST here? bit in the RTP data header to one. The M bit in all other packets MUST be set to zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. If DTX is not used, the M bit MUST be set to zero in all packets. 4. Payload Format So the complete payload consists of a payload header of 1 octet (MBS and FT fields), followed by zero or more consecutive audio frames at Spencer (clarity): Could you expand these names, as you expanded "M" as "Marker" previously? the same bit rate, followed by zero or one SID. To be able to transport a SID alone, that is, without actual audio frames, we assign the FT value 14 to SID. The actual SID size (2, 3, or 6 octets) is inferred from the payload size. Spencer (clarity): It would be good to say this more formally, I think (is the size just what's left over after all other fields are parsed?) I can guess what this means, but I'm guessing. 5.2.1. DTX Offer-Answer Model Considerations The offer-answer model considerations of [RFC4749] fully apply. In this section we only define the management of the "dtx" parameter. The "dtx" parameter concerns both sending and receiving, so both sides of a bi-directional session MUST have the same DTX setting. If one party indicates it does not support DTX, DTX must be deactivated both ways. In other words, DTX is actually activated if, and only if, "dtx=1" in the offer and in the answer. A special rule apply for multicast: the "dtx" parameter becomes Spencer (clarity): s/apply/applies/ declarative and MUST NOT be negotiated. This parameter is fixed, and a participant MUST use the configuration that is provided for the session. 7. Security Considerations DTX introduces no new security issue. Spencer (review): This may be obvious, but a sentence on why you think it's true would be appreciated.