draft-ietf-payload-rtp-opus-09.txt   draft-ietf-payload-rtp-opus-10.txt 
Network Working Group J. Spittka Network Working Group J. Spittka
Internet-Draft Internet-Draft
Intended status: Standards Track K. Vos Intended status: Standards Track K. Vos
Expires: October 12, 2015 vocTone Expires: October 12, 2015 vocTone
JM. Valin JM. Valin
Mozilla Mozilla
April 10, 2015 April 10, 2015
RTP Payload Format for the Opus Speech and Audio Codec RTP Payload Format for the Opus Speech and Audio Codec
draft-ietf-payload-rtp-opus-09 draft-ietf-payload-rtp-opus-10
Abstract Abstract
This document defines the Real-time Transport Protocol (RTP) payload This document defines the Real-time Transport Protocol (RTP) payload
format for packetization of Opus encoded speech and audio data format for packetization of Opus encoded speech and audio data
necessary to integrate the codec in the most compatible way. It also necessary to integrate the codec in the most compatible way. It also
provides an applicability statement for the use of Opus over RTP. provides an applicability statement for the use of Opus over RTP.
Further, it describes media type registrations for the RTP payload Further, it describes media type registrations for the RTP payload
format. format.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Opus Media Type Registration . . . . . . . . . . . . . . 8 6.1. Opus Media Type Registration . . . . . . . . . . . . . . 8
7. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. SDP Offer/Answer Considerations . . . . . . . . . . . . . 13 7.1. SDP Offer/Answer Considerations . . . . . . . . . . . . . 13
7.2. Declarative SDP Considerations for Opus . . . . . . . . . 15 7.2. Declarative SDP Considerations for Opus . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Opus [RFC6716] is a speech and audio codec developed within the IETF Opus [RFC6716] is a speech and audio codec developed within the IETF
Internet Wideband Audio Codec working group. The codec has a very Internet Wideband Audio Codec working group. The codec has a very
low algorithmic delay and it is highly scalable in terms of audio low algorithmic delay and it is highly scalable in terms of audio
bandwidth, bitrate, and complexity. Further, it provides different bandwidth, bitrate, and complexity. Further, it provides different
modes to efficiently encode speech signals as well as music signals, modes to efficiently encode speech signals as well as music signals,
thus making it the codec of choice for various applications using the thus making it the codec of choice for various applications using the
Internet or similar networks. Internet or similar networks.
skipping to change at page 15, line 33 skipping to change at page 15, line 33
configuration are recommendations by the decoding side to ensure configuration are recommendations by the decoding side to ensure
the best performance for the decoder. the best performance for the decoder.
o All other parameters of the payload format configuration are o All other parameters of the payload format configuration are
declarative and a participant MUST use the configurations that are declarative and a participant MUST use the configurations that are
provided for the session. More than one configuration can be provided for the session. More than one configuration can be
provided if necessary by declaring multiple RTP payload types; provided if necessary by declaring multiple RTP payload types;
however, the number of types ought to be kept small. however, the number of types ought to be kept small.
8. Security Considerations 8. Security Considerations
All RTP packets using the payload format defined in this
specification are subject to the general security considerations
discussed in the RTP specification [RFC3550] and any profile from,
e.g., [RFC3711] or [RFC3551].
Use of variable bitrate (VBR) is subject to the security Use of variable bitrate (VBR) is subject to the security
considerations in [RFC6562]. considerations in [RFC6562].
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550], and in any applicable RTP profile such as specification [RFC3550], and in any applicable RTP profile such as
RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework:
Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]
discusses it is not an RTP payload formats responsibility to discuss discusses, it is not an RTP payload format's responsibility to
or mandate what solutions are used to meet the basic security goals discuss or mandate what solutions are used to meet the basic security
like confidentiality, integrity and source authenticity for RTP in goals like confidentiality, integrity and source authenticity for RTP
general. This responsibility lays on anyone using RTP in an in general. This responsibility lays on anyone using RTP in an
application. They can find guidance on available security mechanisms application. They can find guidance on available security mechanisms
and important considerations in Options for Securing RTP Sessions [I- and important considerations in Options for Securing RTP Sessions [I-
D.ietf-avtcore-rtp-security-options]. Applications SHOULD use one or D.ietf-avtcore-rtp-security-options]. Applications SHOULD use one or
more appropriate strong security mechanisms. more appropriate strong security mechanisms.
This payload format transports Opus encoded speech or audio data.
Hence, security issues include confidentiality, integrity protection,
and authentication of the speech or audio itself. Opus does not
provide any confidentiality or integrity protection. Any suitable
external mechanisms, such as SRTP [RFC3711], MAY be used.
This payload format and the Opus encoding do not exhibit any This payload format and the Opus encoding do not exhibit any
significant non-uniformity in the receiver-end computational load and significant non-uniformity in the receiver-end computational load and
thus are unlikely to pose a denial-of-service threat due to the thus are unlikely to pose a denial-of-service threat due to the
receipt of pathological datagrams. receipt of pathological datagrams.
9. Acknowledgements 9. Acknowledgements
Many people have made useful comments and suggestions contributing to Many people have made useful comments and suggestions contributing to
this document. In particular, we would like to thank Tina le Grand, this document. In particular, we would like to thank Tina le Grand,
Cullen Jennings, Jonathan Lennox, Gregory Maxwell, Colin Perkins, Jan Cullen Jennings, Jonathan Lennox, Gregory Maxwell, Colin Perkins, Jan
 End of changes. 5 change blocks. 
17 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/