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.
