Protocol Action: 'RTP Payload Format for ITU-T Recommendation G.711.1' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:

- 'RTP Payload Format for ITU-T Recommendation G.711.1 '
   <draft-ietf-avt-rtp-g711wb-03.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g711wb-03.txt

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The International Telecommunication Union (ITU-T) Recommendation
G.711.1 is an embedded wideband extension of the Recommendation G.711
audio codec. This document specifies a payload format for
packetization of G.711.1 encoded audio signals into the Real-time
Transport Protocol (RTP).

Working Group Summary
Was there anything in WG process that is worth noting?
For example, was there controversy about particular
points or were there decisions where the consensus was particularly
rough?

This is a reasonably standard RTP payload format. The document has been
reviewed by the AVT working group and all open issues were addressed

Document Quality
Are there existing implementations of the protocol?
Have a significant number of vendors indicated their plan
to implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive
issues? If there was a MIB Doctor, Media Type or other
expert review, what was its course (briefly)? In the case of a Media
Type review, on what date was the request posted?

Media type review was conducted starting May 7th 2008, with no
objections raised. Vendors who contributed to the G.711.1 specification
have indicated their intent to support this payload.

Personnel
Who is the Document Shepherd for this document? Who is
the Responsible Area Director?

Roni Even is the document shepherd.

The responsible area director is Cullen Jennings.


RFC Editor Note

Section 4.1 2nd paragraph

OLD
  The 5 most significant bits are reserved for further extension and
  MUST be set to zero.

NEW
  The 5 most significant bits are reserved for further extension and
  MUST be set to zero and MUST be ignored by receivers.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

---
Section 4.2 1st paragraph

OLD
  After this payload header, the audio frames are packed in order of
  time, that is, oldest first.  All frames MUST be of the same mode,
  indicated by the MI field of the payload header.

NEW
  After this payload header, the consecutive audio frames are packed in
order of
                                 ^^^^^^^^^^^^
  time, that is, oldest first.  All frames MUST be of the same mode,
  indicated by the MI field of the payload header.
---

---
Section 8 last paragraph

OLD
  This payload format and the G.711.1 encoding do not exhibit any
  significant non-uniformity in the receiver-end computational load and
  thus are unlikely to pose a denial-of-service threat due to the
  receipt of pathological datagrams.

NEW
  This payload format and the G.711.1 encoding do not exhibit any
  significant non-uniformity in the receiver-end computational load and
  thus are unlikely to pose a denial-of-service threat due to the
  receipt of pathological datagrams.  In addition, they do not contain any


                                   
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  type of active content such as scripts.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

_______________________________________________

IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux