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.