Hi Thank you for the review. Below some answers. Aurelien > -----Message d'origine----- > De : Spencer Dawkins [mailto:spencer@xxxxxxxxxxxxxxxxx] > Envoyé : lundi 22 septembre 2008 15:19 > À : SOLLAUD Aurelien RD-CORE-LAN > Cc : Cullen Jennings; ietf@xxxxxxxx; General Area Review > Team; Roni Even; Tom Taylor > Objet : Late Last Call Gen-ART review of > draft-ietf-avt-rfc4749-dtx-update-01 > > I have been selected as the General Area Review Team > (Gen-ART) reviewer for this draft (for background on Gen-ART, > please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call > comments you may receive. > > > > 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? > [AS] I can do it. > 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? > [AS] It is the wording from RFC 3551 (4.1). It could be a MUST, but I saw no reason to be stronger than the RTP spec. > 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? > [AS] The previous sentence is "The payload format is the same as in [RFC4749], with the option to add a SID at the end." MBS and FT are defined in RFC 4749, so it is just a recall, to make clear that it is the same payload header. I could expand MBS and FT, but it would make a long sentence, and may not help that much. > 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. > [AS] Yes, it can be more explicit. > > 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/ > [AS] OK. Will fix. > 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. > [AS] OK. I could say that DTX is already expected in RTP spec, so nothing new. > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf