Subject: [Gen-art] Late Last Call Gen-ART review of draft-ietf-avt-rfc4749-dtx-update-01

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Sep 2008 08:18:52 -0500

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. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 23 Sep 2008 04:44:50 -0500

Hi, Aurelien,

I think we're good on almost everything in your response.

On the SHOULD/MUST below, it could very well be OK to have this as SHOULD, 
but we've been asking for some indication of reasons why SHOULDs might not 
be implemented - which could be as simple as "there is a lot of deployed 
code that didn't implement this, because it was a SHOULD in RFC 3551".

If you leave this as SHOULD, you might want to say something about the 
effect on receivers, since conformant sender implementations aren't doing 
something that the spec assumed they would be doing. In this case, you're 
saying that the receiver can't look at the M-bit to identify the beginning 
of a talkspurt, right?

If you get any other feedback about SHOULD/MUST here, please take that into 
account, of course...

Thanks,

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 23, 2008 4:20 AM
Subject: RE: Late Last Call Gen-ART review of 
draft-ietf-avt-rfc4749-dtx-update-01

Hi

Thank you for the review.
Below some answers.

Aurelien

> 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.

---

From: <[email-masked]>
Date: Tue, 23 Sep 2008 11:20:39 +0200

Hi

Aurelien 

> -----Message d'origine-----
> De : Spencer Dawkins [mailto:[email-masked]] 
> Envoyé : lundi 22 septembre 2008 15:19
> À : SOLLAUD Aurelien RD-CORE-LAN
> Cc : Cullen Jennings; [email-masked]; General Area Review 
> Team; Roni Even; Tom Taylor
> Objet : Late Last Call Gen-ART review of 
> 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.
> 
> 
> 

[AS] I can do it.

> 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.

> 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.

> Spencer (clarity): s/apply/applies/

[AS] OK. Will fix.

> 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.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 23 Sep 2008 13:45:39 +0300

Hi,
This text is just relevant to G.729.1 and not to other codecs, so if you
want to add a reason for the SHOULD it should be based on RFC4749
implementations that would not send M=1. Maybe the text should say that if
DTX is offered the sender must set the M bit according to RFC 3551.
Roni

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2008 12:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Late Last Call Gen-ART review of
draft-ietf-avt-rfc4749-dtx-update-01

Hi, Aurelien,

Thanks,

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 

Hi

Aurelien

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Sep 2008 20:10:53 -0600

Let's follow Roni's advice on this. Please revise the draft for the  
other changes and whatever text gets agreed to for this one then  
resubmit the draft and send me an email and I will put it on the agenda.

Cullen

---

From: <[email-masked]>
Date: Fri, 26 Sep 2008 14:05:54 +0200

Hi

The current text in section 3 of my draft is mostly a copy/paste from RFC 3551. Are you suggesting to replace the whole block by a reference to RFC3551 section 4.1?

With you comment that it is specific to G.729.1, I see no reason for an implementation to not set M=1 as expected. So I'm also OK to replace the SHOULD by a MUST in the current text.

What option seems the best?

Aurelien

> De : Roni Even [mailto:[email-masked]] 
> Envoyé : mardi 23 septembre 2008 12:46
> À : 'Spencer Dawkins'; SOLLAUD Aurelien RD-CORE-LAN
> Cc : [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Objet : RE: Late Last Call Gen-ART review of 
> This text is just relevant to G.729.1 and not to other 
> codecs, so if you want to add a reason for the SHOULD it 
> should be based on RFC4749 implementations that would not 
> send M=1. Maybe the text should say that if DTX is offered 
> the sender must set the M bit according to RFC 3551.
> Roni
> 
> On the SHOULD/MUST below, it could very well be OK to have 
> this as SHOULD, but we've been asking for some indication of 
> reasons why SHOULDs might not be implemented - which could be 
> as simple as "there is a lot of deployed code that didn't 
> implement this, because it was a SHOULD in RFC 3551".
> 
> If you leave this as SHOULD, you might want to say something 
> about the effect on receivers, since conformant sender 
> implementations aren't doing something that the spec assumed 
> they would be doing. In this case, you're saying that the 
> receiver can't look at the M-bit to identify the beginning of 
> a talkspurt, right?
> 
> If you get any other feedback about SHOULD/MUST here, please 
> take that into account, of course...
> 
> Thanks,
> 
> Spencer
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Sep 2008 15:16:12 +0300

Aurelien,
My suggestion was to have a MUST for the G.729.1 when DTX is offered. There
is no reason for this case to have a should. RFC 3551 is the general case,
for example if you look at G.729.1 it is fixed value.
So change the text based on my comment.
Roni

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, September 26, 2008 3:06 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Late Last Call Gen-ART review of
draft-ietf-avt-rfc4749-dtx-update-01

Hi

The current text in section 3 of my draft is mostly a copy/paste from RFC
3551. Are you suggesting to replace the whole block by a reference to
RFC3551 section 4.1?

With you comment that it is specific to G.729.1, I see no reason for an
implementation to not set M=1 as expected. So I'm also OK to replace the
SHOULD by a MUST in the current text.

Aurelien

---

From: <[email-masked]>
Date: Fri, 26 Sep 2008 17:41:25 +0200

Hi

-02 version is posted. It reflects the resolution of the last call comments.

Thank you
Aurelien

> De : Cullen Jennings [mailto:[email-masked]] 
> Envoyé : vendredi 26 septembre 2008 04:11
> À : Roni Even
> Cc : Spencer Dawkins; SOLLAUD Aurelien RD-CORE-LAN; Gen Art; 
> Tom Taylor
> Objet : Re: Late Last Call Gen-ART review of 
> Let's follow Roni's advice on this. Please revise the draft 
> for the other changes and whatever text gets agreed to for 
> this one then resubmit the draft and send me an email and I 
> will put it on the agenda.
> 
> Cullen
> 
> codecs, so if 
> > you want to add a reason for the SHOULD it should be based 
> on RFC4749 
> > implementations that would not send M=1. Maybe the text should say 
> > that if DTX is offered the sender must set the M bit 
> according to RFC 
> > 3551.
> > Roni
> >
> > On the SHOULD/MUST below, it could very well be OK to have this as 
> > SHOULD, but we've been asking for some indication of reasons why 
> > SHOULDs might not be implemented - which could be as simple 
> as "there 
> > is a lot of deployed code that didn't implement this, 
> because it was a 
> > SHOULD in RFC 3551".
> >
> > effect on receivers, since conformant sender implementations aren't 
> > doing something that the spec assumed they would be doing. In this 
> > case, you're saying that the receiver can't look at the M-bit to 
> > identify the beginning of a talkspurt, right?
> >
> > If you get any other feedback about SHOULD/MUST here, 
> please take that 
> > into account, of course...
> >
> > Thanks,
> >
> > Spencer
> >