[payload] Protocol Action: 'RTP Payload Format for G.711.0' to Proposed Standard (draft-ietf-payload-g7110-06.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'RTP Payload Format for G.711.0'
  (draft-ietf-payload-g7110-06.txt) as Proposed Standard

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

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-g7110/




Technical Summary

The document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0.  ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks.  This document also defines a storage mode format for G.711.0 and a media type registration for the  G.711.0 RTP payload format.

Working Group Summary

The initial individual draft had a section about G.711.0 "in the middle" this was removed before the document became a WG document. There were no other concerns or objections to the document.

Document Quality

There is an existing implementation. The request for a media type review was posted on March 4th, 2014.

Personnel

Document Shepherd is Roni Even and the responsible AD is Richard Barnes.

RFC Editor Note

  Please change the first two paragraphs in section 10 to match the boilerplate in draft-ietf-payload-rtp-howto-14:

OLD:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550], and in any appropriate RTP profile (for
   example RFC 3551 [RFC3551] or [RFC4585]).  This implies that
   confidentiality of the media streams is achieved by encryption; for
   example, through the application of SRTP [RFC3711].  Because the data
   compression used with this payload format is applied end-to-end, any
   encryption needs to be performed after compression.

   Note that the appropriate mechanism to ensure confidentiality and
   integrity of RTP packets and their payloads is very dependent on the
   application and on the transport and signaling protocols employed.
   Thus, although SRTP is given as an example above, other possible
   choices exist.

NEW:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]
   discusses, it is not an RTP payload format's responsibility to
   discuss or mandate what solutions are used to meet the basic security
   goals like confidentiality, integrity and source authenticity for RTP
   in general.  This responsibility lays on anyone using RTP in an
   application.  They can find guidance on available security mechanisms
   and important considerations in Options for Securing RTP Sessions
   [RFC7201].  Applications SHOULD use one or more appropriate strong
   security mechanisms.  The rest of this security consideration section
   discusses the security impacting properties of the payload format
   itself.

   Because the data compression used with this payload format is applied end-to-end, any
   encryption needs to be performed after compression.