draft-ietf-payload-rtp-opus-01.txt   draft-ietf-payload-rtp-opus-02.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: February 03, 2014 Skype Technologies S.A. Expires: January 01, 2015 vocTone
JM. Valin JM. Valin
Mozilla Mozilla
August 02, 2013 June 30, 2014
RTP Payload Format for Opus Speech and Audio Codec RTP Payload Format for Opus Speech and Audio Codec
draft-ietf-payload-rtp-opus-01 draft-ietf-payload-rtp-opus-02
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 that format for packetization of Opus encoded speech and audio data that
is essential to integrate the codec in the most compatible way. is essential to integrate the codec in the most compatible way.
Further, media type registrations are described for the RTP payload Further, media type registrations are described 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 February 03, 2014. This Internet-Draft will expire on January 01, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Opus Media Type Registration . . . . . . . . . . . . . . 9 6.1. Opus Media Type Registration . . . . . . . . . . . . . . 9
6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 13 6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 13
6.2.1. Offer-Answer Model Considerations for Opus . . . . . 14 6.2.1. Offer-Answer Model Considerations for Opus . . . . . 15
6.2.2. Declarative SDP Considerations for Opus . . . . . . . 16 6.2.2. Declarative SDP Considerations for Opus . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . 17 9. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 (codec). The codec has a Internet Wideband Audio Codec working group (codec). The codec has a
very low algorithmic delay and it is highly scalable in terms of very low algorithmic delay and it is highly scalable in terms of
audio bandwidth, bitrate, and complexity. Further, it provides audio bandwidth, bitrate, and complexity. Further, it provides
different modes to efficiently encode speech signals as well as music different modes to efficiently encode speech signals as well as music
skipping to change at page 4, line 13 skipping to change at page 4, line 13
medium and higher bitrates. medium and higher bitrates.
The Opus speech and audio codec is highly scalable in terms of audio The Opus speech and audio codec is highly scalable in terms of audio
bandwidth, bitrate, and complexity. Further, Opus allows bandwidth, bitrate, and complexity. Further, Opus allows
transmitting stereo signals. transmitting stereo signals.
3.1. Network Bandwidth 3.1. Network Bandwidth
Opus supports all bitrates from 6 kb/s to 510 kb/s. The bitrate can Opus supports all bitrates from 6 kb/s to 510 kb/s. The bitrate can
be changed dynamically within that range. All other parameters being be changed dynamically within that range. All other parameters being
equal, higher bitrate results in higher quality. equal, a higher bitrate results in higher quality.
3.1.1. Recommended Bitrate 3.1.1. Recommended Bitrate
For a frame size of 20 ms, these are the bitrate "sweet spots" for For a frame size of 20 ms, these are the bitrate "sweet spots" for
Opus in various configurations: Opus in various configurations:
o 8-12 kb/s for NB speech, o 8-12 kb/s for NB speech,
o 16-20 kb/s for WB speech, o 16-20 kb/s for WB speech,
o 28-40 kb/s for FB speech, o 28-40 kb/s for FB speech,
o 48-64 kb/s for FB mono music, and o 48-64 kb/s for FB mono music, and
skipping to change at page 5, line 18 skipping to change at page 5, line 18
signal allows to do so, but the transmission to the receiver itself signal allows to do so, but the transmission to the receiver itself
will never be interrupted. Therefore, the received signal will will never be interrupted. Therefore, the received signal will
maintain the same high level of quality over the full duration of a maintain the same high level of quality over the full duration of a
transmission while minimizing the average bit rate over time. transmission while minimizing the average bit rate over time.
In cases where the bitrate of Opus needs to be reduced even further In cases where the bitrate of Opus needs to be reduced even further
or in cases where only constant bitrate is available, the Opus or in cases where only constant bitrate is available, the Opus
encoder may be set to use discontinuous transmission (DTX), where encoder may be set to use discontinuous transmission (DTX), where
parts of the encoded signal that correspond to periods of silence in parts of the encoded signal that correspond to periods of silence in
the input speech or audio signal are not transmitted to the receiver. the input speech or audio signal are not transmitted to the receiver.
A receiver can distinguish between DTX and packet loss by looking for
gaps in the sequence number, as described by Section 4.1
of [RFC3551].
On the receiving side, the non-transmitted parts will be handled by a On the receiving side, the non-transmitted parts will be handled by a
frame loss concealment unit in the Opus decoder which generates a frame loss concealment unit in the Opus decoder which generates a
comfort noise signal to replace the non transmitted parts of the comfort noise signal to replace the non transmitted parts of the
speech or audio signal. speech or audio signal. Use of [RFC3389] Comfort Noise (CN) with
Opus is discouraged. The transmitter MUST drop whole frames only,
based on the size of the last transmitted frame, to ensure successive
RTP timestamps differ by a multiple of 120 and to allow the receiver
to use whole frames for concealment.
The DTX mode of Opus will have a slightly lower speech or audio The DTX mode of Opus will have a slightly lower speech or audio
quality than the continuous mode. Therefore, it is RECOMMENDED to quality than the continuous mode. Therefore, it is RECOMMENDED to
use Opus in the continuous mode unless restraints on network capacity use Opus in the continuous mode unless restraints on network capacity
are severe. The DTX mode can be engaged for operation in both are severe. The DTX mode can be engaged for operation in both
adaptive or constant bitrate. adaptive or constant bitrate.
3.2. Complexity 3.2. Complexity
Complexity can be scaled to optimize for CPU resources in real-time, Complexity can be scaled to optimize for CPU resources in real-time,
skipping to change at page 6, line 47 skipping to change at page 7, line 5
4.1. RTP Header Usage 4.1. RTP Header Usage
The format of the RTP header is specified in [RFC3550]. The Opus The format of the RTP header is specified in [RFC3550]. The Opus
payload format uses the fields of the RTP header consistent with this payload format uses the fields of the RTP header consistent with this
specification. specification.
The payload length of Opus is a multiple number of octets and The payload length of Opus is a multiple number of octets and
therefore no padding is required. The payload MAY be padded by an therefore no padding is required. The payload MAY be padded by an
integer number of octets according to [RFC3550]. integer number of octets according to [RFC3550].
The marker bit (M) of the RTP header is used in accordance with The timestamp, sequence number, and marker bit (M) of the RTP header
Section 4.1 of [RFC3551]. are used in accordance with Section 4.1 of [RFC3551].
The RTP payload type for Opus has not been assigned statically and is The RTP payload type for Opus has not been assigned statically and is
expected to be assigned dynamically. expected to be assigned dynamically.
The receiving side MUST be prepared to receive duplicates of RTP The receiving side MUST be prepared to receive duplicates of RTP
packets. Only one of those payloads MUST be provided to the Opus packets. Only one of those payloads MUST be provided to the Opus
decoder for decoding and others MUST be discarded. decoder for decoding and others MUST be discarded.
Opus supports 5 different audio bandwidths which may be adjusted Opus supports 5 different audio bandwidths which may be adjusted
during the duration of a call. The RTP timestamp clock frequency is during the duration of a call. The RTP timestamp clock frequency is
skipping to change at page 14, line 28 skipping to change at page 14, line 28
Below are some examples of SDP session descriptions for Opus: Below are some examples of SDP session descriptions for Opus:
Example 1: Standard mono session with 48000 Hz clock rate Example 1: Standard mono session with 48000 Hz clock rate
m=audio 54312 RTP/AVP 101 m=audio 54312 RTP/AVP 101
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
allowed, DTX is not allowed allowed, 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;
maxaveragebitrate=20000; 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
skipping to change at page 17, line 20 skipping to change at page 17, line 26
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
skipping to change at page 18, line 12 skipping to change at page 18, line 23
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, September 2012. Opus Audio Codec", RFC 6716, September 2012.
Authors' Addresses Authors' Addresses
Julian Spittka Julian Spittka
Email: jspittka@gmail.com Email: jspittka@gmail.com
Koen Vos Koen Vos
Skype Technologies S.A. vocTone
3210 Porter Drive
Palo Alto, CA 94304
USA
Email: koenvos74@gmail.com Email: koenvos74@gmail.com
Jean-Marc Valin Jean-Marc Valin
Mozilla Mozilla
650 Castro Street 2 Harrison Street
Mountain View, CA 94041 San Francisco, CA 94105
USA USA
Email: jmvalin@jmvalin.ca Email: jmvalin@jmvalin.ca
 End of changes. 15 change blocks. 
18 lines changed or deleted 25 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/