RTP Payload Format for the G.729.1 Audio Codec
draft-ietf-avt-rtp-g729-scal-wb-ext-07

[Ballot comment]
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 [1], 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?

[Ballot discuss]
I think I understand Ted's discuss - so I will take that one over.

DTX is 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 [1], 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?

IANA Evaluation Comment:

Upon approval of this document, the IANA will make the following assignments
in the  registry located at
http://www.iana.org/assignments/media-types/audio/


Value Description
----- ----------------
G7291 [RFC-tobe-avt-rtp-g729-scal-wb-ext]

[Ballot discuss]
Based on Gen-ART review by Sharon Chisholm and reply from Colin Perkins:

> 4. In section 3, second paragraph, is it suggesting that this  feature is
> helpful when sharing a fixed bandwidth or suggesting that people  should
> share a fixed bandwidth? It reads like the latter.

The intent is to say that, if you have a fixed bandwidth link, the  ability to adjust the bandwidth may help.

BC: It would be clearer to say exactly that.

> 6. In section 4, second paragraph, "The RTP timestamp clock  frequency is
> the same as the default sampling frequency, that is 16 kHz" implies a
> significant relationship between the RTP timestamp and the default
> sampling frequency, but isn't it just a coincidence they have the same
> value?

No. They are defined to have the same value, to ensure accurate media  playout.

BC: It would be clearer to insert "to ensure accurate media  playout."

> 10. In section 5.1, first paragraph, it indicates that the header is
> "generally followed by audio data representing one or more consecutive
> frames at the same bit rate." My initial read of this was that
> occasionally it doesn't contain audio data, but after reading the  entire
> document and briefly thinking perhaps it also could carry video (see
> section 6.1, "Applications which use this media type"), I then  ending up
> on audio-only in section 8, second paragraph. So, this means that  either
> the 'generally' is incorrect or the variable in this sentence is
> actually the "one or more consecutive frames at the same bit rate"?


The diagram in section 5.1 explains that there may be zero or more  frames following the header. The "generally followed" text is  correct, since a packet containing zero frames (i.e. no audio data)  is legal.

BC: As written it can lead to the confusion Sharon noted. Why not be
pedantic and write: "followed by zero or
more consecutive audio frames at the same bit rate". ?

> 11. In section 5.2, fifth paragraph we learn that we need to ignore
> invalid values in an MBS but at this point have no idea what an  invalid
> value is or how one might learn more. Later in the document, we did
> learn that an MBS can't exceed the maxbitrate field, but I think  for the
> offer-answer model, there may have been other restrictions. I may have
> missed some. When to ignore a field seems important so it would be
> better if this was clearer in the document.


Values 12-14 are reserved, and hence invalid. This should probably be  clarified.

> 12. In section 5.3, final paragraph, I have a similar comment  around the
> FT. It appears later on in the document that this also can't imply a
> rate greater then the maxbitrate, but are there other invalid values?


As above.

> 13. In section 5.4, if FT=15, then there will be no audio frame in the
> payload. Then what will there be? Is this an extension of my confusion
> in point 10 or is this a case of sending only header information  and no
> payload?

It is header information only, no payload, as explained in my answer  to your point 10.

BC: I would clarify by adding "i.e., no payload frames are transmitted."

> 14. In section 6, second paragraph, it mentions a mapping for SDP and
> what to do if it isn't SDP or MIME, but what happens if it is MIME?

BC: I suggest clarifying the paragraph thus:

  For MIME, the parameters are defined below as part of the media subtype
  registration for the G.729.1 codec.  A mapping of the parameters into
  the Session Description Protocol (SDP) [5] is also provided below for those
  applications that use SDP.  In control protocols that do not use MIME
  or SDP, the media type parameters must be mapped to the appropriate
  format used with that control protocol.

[Ballot discuss]
Based on Gen-ART review by Sharon Chisholm and reply from Colin Perkins:

> 4. In section 3, second paragraph, is it suggesting that this  feature is
> helpful when sharing a fixed bandwidth or suggesting that people  should
> share a fixed bandwidth? It reads like the latter.

The intent is to say that, if you have a fixed bandwidth link, the  ability to adjust the bandwidth may help.

BC: It would be clearer to say exactly that.

> 6. In section 4, second paragraph, "The RTP timestamp clock  frequency is
> the same as the default sampling frequency, that is 16 kHz" implies a
> significant relationship between the RTP timestamp and the default
> sampling frequency, but isn't it just a coincidence they have the same
> value?

No. They are defined to have the same value, to ensure accurate media  playout.

BC: It would be clearer to insert "to ensure accurate media  playout."

> 10. In section 5.1, first paragraph, it indicates that the header is
> "generally followed by audio data representing one or more consecutive
> frames at the same bit rate." My initial read of this was that
> occasionally it doesn't contain audio data, but after reading the  entire
> document and briefly thinking perhaps it also could carry video (see
> section 6.1, "Applications which use this media type"), I then  ending up
> on audio-only in section 8, second paragraph. So, this means that  either
> the 'generally' is incorrect or the variable in this sentence is
> actually the "one or more consecutive frames at the same bit rate"?


The diagram in section 5.1 explains that there may be zero or more  frames following the header. The "generally followed" text is  correct, since a packet containing zero frames (i.e. no audio data)  is legal.

BC: As written it can lead to the confusion Sharon noted. Why not be
pedantic and write: "followed by zero or
more consecutive audio frames at the same bit rate". ?

> 11. In section 5.2, fifth paragraph we learn that we need to ignore
> invalid values in an MBS but at this point have no idea what an  invalid
> value is or how one might learn more. Later in the document, we did
> learn that an MBS can't exceed the maxbitrate field, but I think  for the
> offer-answer model, there may have been other restrictions. I may have
> missed some. When to ignore a field seems important so it would be
> better if this was clearer in the document.


Values 12-14 are reserved, and hence invalid. This should probably be  clarified.

> 12. In section 5.3, final paragraph, I have a similar comment  around the
> FT. It appears later on in the document that this also can't imply a
> rate greater then the maxbitrate, but are there other invalid values?


As above.

> 13. In section 5.4, if FT=15, then there will be no audio frame in the
> payload. Then what will there be? Is this an extension of my confusion
> in point 10 or is this a case of sending only header information  and no
> payload?

It is header information only, no payload, as explained in my answer  to your point 10.

BC: I would clarify by adding "i.e., only the header is transmitted."

> 14. In section 6, second paragraph, it mentions a mapping for SDP and
> what to do if it isn't SDP or MIME, but what happens if it is MIME?

BC: I suggest clarifying the paragraph thus:

  For MIME, the parameters are defined below as part of the media subtype
  registration for the G.729.1 codec.  A mapping of the parameters into
  the Session Description Protocol (SDP) [5] is also provided below for those
  applications that use SDP.  In control protocols that do not use MIME
  or SDP, the media type parameters must be mapped to the appropriate
  format used with that control protocol.

[Ballot discuss]
Based on Gen-ART review by Sharon Chisholm and reply from Colin Perkins:

> 4. In section 3, second paragraph, is it suggesting that this  feature is
> helpful when sharing a fixed bandwidth or suggesting that people  should
> share a fixed bandwidth? It reads like the latter.

The intent is to say that, if you have a fixed bandwidth link, the  ability to adjust the bandwidth may help.

BC: It would be clearer to say exactly that.

> 6. In section 4, second paragraph, "The RTP timestamp clock  frequency is
> the same as the default sampling frequency, that is 16 kHz" implies a
> significant relationship between the RTP timestamp and the default
> sampling frequency, but isn't it just a coincidence they have the same
> value?

No. They are defined to have the same value, to ensure accurate media  playout.

BC: It would be clearer to insert "to ensure accurate media  playout."

> 10. In section 5.1, first paragraph, it indicates that the header is
> "generally followed by audio data representing one or more consecutive
> frames at the same bit rate." My initial read of this was that
> occasionally it doesn't contain audio data, but after reading the  entire
> document and briefly thinking perhaps it also could carry video (see
> section 6.1, "Applications which use this media type"), I then  ending up
> on audio-only in section 8, second paragraph. So, this means that  either
> the 'generally' is incorrect or the variable in this sentence is
> actually the "one or more consecutive frames at the same bit rate"?


The diagram in section 5.1 explains that there may be zero or more  frames following the header. The "generally followed" text is  correct, since a packet containing zero frames (i.e. no audio data)  is legal.

BC: As written it can lead to the confusion Sharon noted. Why not be
pedantic and write: "followed by audio data representing one or more consecutive
frames at the same bit rate, unless the audio payload is empty" ?

> 11. In section 5.2, fifth paragraph we learn that we need to ignore
> invalid values in an MBS but at this point have no idea what an  invalid
> value is or how one might learn more. Later in the document, we did
> learn that an MBS can't exceed the maxbitrate field, but I think  for the
> offer-answer model, there may have been other restrictions. I may have
> missed some. When to ignore a field seems important so it would be
> better if this was clearer in the document.


Values 12-14 are reserved, and hence invalid. This should probably be  clarified.

> 12. In section 5.3, final paragraph, I have a similar comment  around the
> FT. It appears later on in the document that this also can't imply a
> rate greater then the maxbitrate, but are there other invalid values?


As above.

> 13. In section 5.4, if FT=15, then there will be no audio frame in the
> payload. Then what will there be? Is this an extension of my confusion
> in point 10 or is this a case of sending only header information  and no
> payload?

It is header information only, no payload, as explained in my answer  to your point 10.

BC: I would clarify by adding "i.e., only the header is transmitted."

> 14. In section 6, second paragraph, it mentions a mapping for SDP and
> what to do if it isn't SDP or MIME, but what happens if it is MIME?

If it is MIME, standard MIME mechanisms are used, as defined in  section 6.1.

BC: please say so.

[Ballot comment]
Section 7., paragraph 1:

>    Congestion control for RTP SHALL be used in accordance with RFC 3550
>    [3] and any appropriate profile (for example, RFC 3551 [4]).  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."

[Ballot discuss]
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 [1], 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?

Note from author:

The next step on the ITU side is the description of the RTP format and parameters neotiation for use with H.323. A contribution will be posted for the next plenary meeting, November 14th. This document will need to reference the RFC for the payload format and the media parameters, corresponding to draft-ietf-avt-rtp-g729-scal-wb-ext (now in state Publication Requested).

Thus it would be good to have the RFC published by ~ October 20th, to be able to reference it in the ITU contribution of November.
It is ~4 monthes from now. Do you think it is realistic?

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has had adequate review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes. (idnits 1.100 complains about RFC 2119 boilerplate, but that
appears to be a bug in idnits).

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where
the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. The only normative reference to an I-D is
to sdp-new.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This document specifies a real-time transport protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) G.729.1 audio codec. A media type registration is included
for the payload format.

* Working Group Summary

This is a straight-forward RTP payload format.

* Protocol Quality

The draft was not controversial, and followed standard RTP
payload format design principles. Kang Tae-Gyu and Magnus Westerlund provided
working group last call comments, raising only minor issues. The PROTO
review was done by Colin Perkins. The draft had an ietf-types review in May
2006, no issues were raised.