draft-ietf-payload-rtp-opus-05.txt   draft-ietf-payload-rtp-opus-06.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: June 10, 2015 vocTone Expires: July 10, 2015 vocTone
JM. Valin JM. Valin
Mozilla Mozilla
December 7, 2014 January 6, 2015
RTP Payload Format for Opus Speech and Audio Codec RTP Payload Format for Opus Speech and Audio Codec
draft-ietf-payload-rtp-opus-05 draft-ietf-payload-rtp-opus-06
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. necessary to integrate the codec in the most compatible way.
Further, it describes media type registrations for the RTP payload Further, it describes media type registrations for the RTP payload
format. format.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 10, 2015. This Internet-Draft will expire on July 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1.3. Discontinuous Transmission (DTX) . . . . . . . . . . 4 3.1.3. Discontinuous Transmission (DTX) . . . . . . . . . . 4
3.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Forward Error Correction (FEC) . . . . . . . . . . . . . 5 3.3. Forward Error Correction (FEC) . . . . . . . . . . . . . 5
3.4. Stereo Operation . . . . . . . . . . . . . . . . . . . . 6 3.4. Stereo Operation . . . . . . . . . . . . . . . . . . . . 6
4. Opus RTP Payload Format . . . . . . . . . . . . . . . . . . . 6 4. Opus RTP Payload Format . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 6
4.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 7 4.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 7
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Opus Media Type Registration . . . . . . . . . . . . . . 8 6.1. Opus Media Type Registration . . . . . . . . . . . . . . 8
6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 11 6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 12
6.2.1. Offer-Answer Model Considerations for Opus . . . . . 13 6.2.1. Offer-Answer Model Considerations for Opus . . . . . 13
6.2.2. Declarative SDP Considerations for Opus . . . . . . . 14 6.2.2. Declarative SDP Considerations for Opus . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Opus codec is a speech and audio codec developed within the IETF The Opus codec 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
skipping to change at page 9, line 48 skipping to change at page 9, line 48
no value is specified, the default is 120. no value is specified, the default is 120.
ptime: the preferred duration of media represented by a packet ptime: the preferred duration of media represented by a packet
(according to Section 6 of [RFC4566]) that a decoder wants to (according to Section 6 of [RFC4566]) that a decoder wants to
receive, in milliseconds rounded up to the next full integer receive, in milliseconds rounded up to the next full integer
value. Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary value. Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
multiple of an Opus frame size rounded up to the next full integer multiple of an Opus frame size rounded up to the next full integer
value, up to a maximum value of 120, as defined in Section 4. If value, up to a maximum value of 120, as defined in Section 4. If
no value is specified, the default is 20. no value is specified, the default is 20.
maxaveragebitrate: specifies the maximum average receive bitrate of
a session in bits per second (b/s). The actual value of the
bitrate can vary, as it is dependent on the characteristics of the
media in a packet. Note that the maximum average bitrate MAY be
modified dynamically during a session. Any positive integer is
allowed, but values outside the range 6000 to 510000 SHOULD be
ignored. If no value is specified, the maximum value specified in
Section 3.1.1 for the corresponding mode of Opus and corresponding
maxplaybackrate is the default.
stereo: specifies whether the decoder prefers receiving stereo or stereo: specifies whether the decoder prefers receiving stereo or
mono signals. Possible values are 1 and 0 where 1 specifies that mono signals. Possible values are 1 and 0 where 1 specifies that
stereo signals are preferred, and 0 specifies that only mono stereo signals are preferred, and 0 specifies that only mono
signals are preferred. Independent of the stereo parameter every signals are preferred. Independent of the stereo parameter every
receiver MUST be able to receive and decode stereo signals but receiver MUST be able to receive and decode stereo signals but
sending stereo signals to a receiver that signaled a preference sending stereo signals to a receiver that signaled a preference
for mono signals may result in higher than necessary network for mono signals may result in higher than necessary network
utilization and encoding complexity. If no value is specified, utilization and encoding complexity. If no value is specified,
the default is 0 (mono). the default is 0 (mono).
skipping to change at page 12, line 4 skipping to change at page 12, line 16
6.2. Mapping to SDP Parameters 6.2. Mapping to SDP Parameters
The information described in the media type specification has a The information described in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[RFC4566], which is commonly used to describe RTP sessions. When SDP [RFC4566], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the Opus codec, the mapping is is used to specify sessions employing the Opus codec, the mapping is
as follows: as follows:
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding o The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding
name. The RTP clock rate in "a=rtpmap" MUST be 48000 and the name. The RTP clock rate in "a=rtpmap" MUST be 48000 and the
number of channels MUST be 2. number of channels MUST be 2.
o The OPTIONAL media type parameters "ptime" and "maxptime" are o The OPTIONAL media type parameters "ptime" and "maxptime" are
mapped to "a=ptime" and "a=maxptime" attributes, respectively, in mapped to "a=ptime" and "a=maxptime" attributes, respectively, in
the SDP. the SDP.
o The OPTIONAL media type parameters "maxplaybackrate", "stereo", o The OPTIONAL media type parameters "maxaveragebitrate",
"cbr", "useinbandfec", and "usedtx", when present, MUST be "maxplaybackrate", "stereo", "cbr", "useinbandfec", and "usedtx",
included in the "a=fmtp" attribute in the SDP, expressed as a when present, MUST be included in the "a=fmtp" attribute in the
media type string in the form of a semicolon-separated list of SDP, expressed as a media type string in the form of a semicolon-
parameter=value pairs (e.g., maxplaybackrate=48000). They MUST separated list of parameter=value pairs (e.g.,
NOT be specified in an SSRC-specific "fmtp" source-level attribute maxplaybackrate=48000). They MUST NOT be specified in an SSRC-
(as defined in Section 6.3 of [RFC5576]). specific "fmtp" source-level attribute (as defined in Section 6.3
of [RFC5576]).
o The OPTIONAL media type parameters "sprop-maxcapturerate", and o The OPTIONAL media type parameters "sprop-maxcapturerate", and
"sprop-stereo" MAY be mapped to the "a=fmtp" SDP attribute by "sprop-stereo" MAY be mapped to the "a=fmtp" SDP attribute by
copying them directly from the media type parameter string as part copying them directly from the media type parameter string as part
of the semicolon-separated list of parameter=value pairs (e.g., of the semicolon-separated list of parameter=value pairs (e.g.,
sprop-stereo=1). These same OPTIONAL media type parameters MAY sprop-stereo=1). These same OPTIONAL media type parameters MAY
also be specified using an SSRC-specific "fmtp" source-level also be specified using an SSRC-specific "fmtp" source-level
attribute as described in Section 6.3 of [RFC5576]. They MAY be attribute as described in Section 6.3 of [RFC5576]. They MAY be
specified in both places, in which case the parameter in the specified in both places, in which case the parameter in the
source-level attribute overrides the one found on the "a=fmtp" source-level attribute overrides the one found on the "a=fmtp"
line. The value of any parameter which is not specified in a line. The value of any parameter which is not specified in a
skipping to change at page 12, line 46 skipping to change at page 13, line 13
a=rtpmap:101 opus/48000/2 a=rtpmap:101 opus/48000/2
Example 2: 16000 Hz clock rate, maximum packet size of 40 ms, Example 2: 16000 Hz clock rate, maximum packet size of 40 ms,
recommended packet size of 40 ms, maximum average bitrate of 20000 recommended packet size of 40 ms, maximum average bitrate of 20000
bps, prefers to receive stereo but only plans to send mono, FEC is bps, prefers to receive stereo but only plans to send mono, FEC is
desired, DTX is not desired desired, DTX is not desired
m=audio 54312 RTP/AVP 101 m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000/2 a=rtpmap:101 opus/48000/2
a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000; a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000;
b=AS:20; stereo=1; useinbandfec=1; usedtx=0 maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0
a=ptime:40 a=ptime:40
a=maxptime:40 a=maxptime:40
Example 3: Two-way full-band stereo preferred Example 3: Two-way full-band stereo preferred
m=audio 54312 RTP/AVP 101 m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000/2 a=rtpmap:101 opus/48000/2
a=fmtp:101 stereo=1; sprop-stereo=1 a=fmtp:101 stereo=1; sprop-stereo=1
6.2.1. Offer-Answer Model Considerations for Opus 6.2.1. Offer-Answer Model Considerations for Opus
skipping to change at page 13, line 45 skipping to change at page 14, line 13
bandwidth higher than necessary to make full use of audio sampled bandwidth higher than necessary to make full use of audio sampled
at a sampling rate of "maxplaybackrate". Gateways or senders that at a sampling rate of "maxplaybackrate". Gateways or senders that
are sending the same encoded audio to multiple destinations SHOULD are sending the same encoded audio to multiple destinations SHOULD
NOT use an audio bandwidth higher than necessary to represent NOT use an audio bandwidth higher than necessary to represent
audio sampled at "maxplaybackrate", as this would lead to audio sampled at "maxplaybackrate", as this would lead to
inefficient use of network resources. The "maxplaybackrate" inefficient use of network resources. The "maxplaybackrate"
parameter does not affect interoperability. Also, this parameter parameter does not affect interoperability. Also, this parameter
SHOULD NOT be used to adjust the audio bandwidth as a function of SHOULD NOT be used to adjust the audio bandwidth as a function of
the bitrate, as this is the responsibility of the Opus encoder the bitrate, as this is the responsibility of the Opus encoder
implementation. implementation.
o The "maxaveragebitrate" parameter is a unidirectional receive-only
parameter that reflects limitations of the local receiver. The
sender of the other side MUST NOT send with an average bitrate
higher than "maxaveragebitrate" as it might overload the network
and/or receiver. The "maxaveragebitrate" parameter typically will
not compromise interoperability; however, some values might cause
application performance to suffer, and ought to be set with care.
o The "sprop-maxcapturerate" and "sprop-stereo" parameters are o The "sprop-maxcapturerate" and "sprop-stereo" parameters are
unidirectional sender-only parameters that reflect limitations of unidirectional sender-only parameters that reflect limitations of
the sender side. They allow the receiver to set up a reduced- the sender side. They allow the receiver to set up a reduced-
complexity audio processing pipeline if the sender is not planning complexity audio processing pipeline if the sender is not planning
to use the full range of Opus's capabilities. Neither "sprop- to use the full range of Opus's capabilities. Neither "sprop-
maxcapturerate" nor "sprop-stereo" affect interoperability and the maxcapturerate" nor "sprop-stereo" affect interoperability and the
receiver MUST be capable of receiving any signal. receiver MUST be capable of receiving any signal.
o The "stereo" parameter is a unidirectional receive-only parameter. o The "stereo" parameter is a unidirectional receive-only parameter.
When sending to a single destination, a sender MUST NOT use stereo When sending to a single destination, a sender MUST NOT use stereo
when "stereo" is 0. Gateways or senders that are sending the same when "stereo" is 0. Gateways or senders that are sending the same
skipping to change at page 14, line 26 skipping to change at page 14, line 47
o The "usedtx" parameter is a unidirectional receive-only parameter. o The "usedtx" parameter is a unidirectional receive-only parameter.
o Any unknown parameter in an offer MUST be ignored by the receiver o Any unknown parameter in an offer MUST be ignored by the receiver
and MUST be removed from the answer. and MUST be removed from the answer.
6.2.2. Declarative SDP Considerations for Opus 6.2.2. Declarative SDP Considerations for Opus
For declarative use of SDP such as in Session Announcement Protocol For declarative use of SDP such as in Session Announcement Protocol
(SAP), [RFC2974], and RTSP, [RFC2326], for Opus, the following needs (SAP), [RFC2974], and RTSP, [RFC2326], for Opus, the following needs
to be considered: to be considered:
o The values for "maxptime", "ptime", "maxplaybackrate", and ought o The values for "maxptime", "ptime", "maxplaybackrate", and
to be selected carefully to ensure that a reasonable performance "maxaveragebitrate" ought to be selected carefully to ensure that
can be achieved for the participants of a session. a reasonable performance can be achieved for the participants of a
session.
o The values for "maxptime", "ptime", and of the payload format o The values for "maxptime", "ptime", and of the payload format
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.
7. Security Considerations 7. Security Considerations
 End of changes. 13 change blocks. 
19 lines changed or deleted 38 lines changed or added

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