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?
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf