draft-ietf-avt-rtp-ipmr-15.txt   rfc6262.txt 
Audio/Video Transport Working Group S. Ikonin Internet Engineering Task Force (IETF) S. Ikonin
Internet Draft SPIRIT DSP Request for Comments: 6262 SPIRIT DSP
Intended status: Proposed Standard January 11, 2011 Category: Standards Track August 2011
ISSN: 2070-1721
RTP Payload Format for IP-MR Speech Codec RTP Payload Format for IP-MR Speech Codec
draft-ietf-avt-rtp-ipmr-15.txt
Abstract Abstract
This document specifies the payload format for packetization of This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the real-time transport SPIRIT IP-MR encoded speech signals into the Real-time Transport
protocol (RTP). The payload format supports transmission of multiple Protocol (RTP). The payload format supports transmission of multiple
frames per packet and introduced redundancy for robustness against frames per packet and introduces redundancy for robustness against
packet loss and bit errors. packet loss and bit errors.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 18, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6262.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
described in the Simplified BSD License. described in the Simplified BSD License.
The source codes included in this document are provided under BSD This document may contain material from IETF Documents or IETF
license (http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf). Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. IP-MR Codec Description . . . . . . . . . . . . . . . . . . . . 3 2. IP-MR Codec Description .........................................3
3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Payload Format ..................................................4
3.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 4 3.1. RTP Header Usage ...........................................4
3.2. RTP Payload Structure . . . . . . . . . . . . . . . . . . . 5 3.2. RTP Payload Structure ......................................4
3.3. Speech Payload Header . . . . . . . . . . . . . . . . . . . 5 3.3. Speech Payload Header ......................................5
3.4. Speech Payload Table of Contents . . . . . . . . . . . . . 6 3.4. Speech Payload Table of Contents ...........................6
3.5. Speech Payload Data . . . . . . . . . . . . . . . . . . . . 6 3.5. Speech Payload Data ........................................6
3.6. Redundancy Payload Header . . . . . . . . . . . . . . . . . 7 3.6. Redundancy Payload Header ..................................7
3.7. Redundancy Payload Table of Contents . . . . . . . . . . . 8 3.7. Redundancy Payload Table of Contents .......................8
3.8. Redundancy Payload Data . . . . . . . . . . . . . . . . . . 8 3.8. Redundancy Payload Data ....................................8
4. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Payload Examples ................................................9
4.1. Payload Carrying a Single Frame . . . . . . . . . . . . . . 9 4.1. Payload Carrying a Single Frame ............................9
4.2. Payload Carrying Multiple Frames with Redundancy . . . . 10 4.2. Payload Carrying Multiple Frames with Redundancy ..........10
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 11 5. Congestion Control .............................................11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations ........................................12
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 7. Payload Format Parameters ......................................13
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 13 7.1. Media Type Registration ...................................13
7.2. Mapping Media Type Parameters into SDP . . . . . . . . . 14 7.2. Mapping Media Type Parameters into SDP ....................14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations ............................................14
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 9. Normative References ...........................................15
10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Retrieving Frame Information ..........................16
11. Legal Terms . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. get_frame_info.c ..........................................16
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
APPENDIX A. RETRIEVING FRAME INFORMATION . . . . . . . . . . . . 17
A.1. get_frame_info.c . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document specifies the payload format for packetization of This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the real-time transport SPIRIT IP-MR encoded speech signals into the Real-time Transport
protocol (RTP). The payload format supports transmission of multiple Protocol (RTP). The payload format supports transmission of multiple
frames per packet and introduced redundancy for robustness against frames per packet and introduces redundancy for robustness against
packet loss and bit errors. packet loss and bit errors.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. IP-MR Codec Description 2. IP-MR Codec Description
IP-MR is a wideband speech codec designed by SPIRIT for conferencing IP-MR is a wideband speech codec designed by SPIRIT for conferencing
services over packet-switched networks such as the Internet. services over packet-switched networks such as the Internet.
IP-MR is a scalable codec. It means that not only source has the IP-MR is a scalable codec. This means that the source not only has
ability to change transmission rate on a fly, but the gateway is also the ability to change transmission rate on the fly, but the gateway
able to decrease bandwidth at any time without performance overhead. is also able to decrease bandwidth at any time without performance
There are 6 coding rates from 7.7 to 34.2 kbps available. overhead. There are 6 coding rates from 7.7 to 34.2 kbps available.
Codec operates on a frame-by-frame basis with a frame size of 20 ms The codec operates on a frame-by-frame basis with a frame size of 20
at 16 kHz sampling rate with the total end-to-end delay of 25ms. Each ms at a 16 kHz sampling rate with a total end-to-end delay of 25 ms.
compressed frame represented as a sequence of layers. The first Each compressed frame is represented as a sequence of layers. The
(base) layer is mandatory while the other (enhancement) can be safely first (base) layer is mandatory while the other (enhancement) layers
discarded. Information about particular frame structure is available can be safely discarded. Information about the particular frame
from the payload header. In order to adjust outgoing bandwidth the structure is available from the payload header. In order to adjust
gateway MUST read frame(s) structure from the payload header, define outgoing bandwidth, the gateway MUST read the frame(s) structure from
which enhancement layers to discard and compose new RTP packet the payload header, define which enhancement layers to discard, and
according to this specification. compose a new RTP packet according to this specification.
In fact, not all of bits within a frame are equally tolerant to In fact, not all bits within a frame are equally tolerant to
distortion. IP-MR defines 6 classes ('A'-'F') of sensitivity to bit distortion. IP-MR defines 6 classes ('A'-'F') of sensitivity to bit
errors. Any damage of class 'A' bits cause significant reconstruction errors. Any damage of class 'A' bits causes significant
artifacts while the loss in class 'F' may be even not perceived by reconstruction artifacts while the loss in class 'F' may not even be
the listener. Note, only base layer in a bitstream is represented as perceived by the listener. Note that only the base layer in a
a set of classes. bitstream is represented as a set of classes.
The IP-MR payload format allows frame duplicate through the packets The IP-MR payload format allows frame duplication through the packets
to improve robustness against packet loss (Section 3.6). Base layer to improve robustness against packet loss (Section 3.6). The base
can be retransmitted completely or in several sensitive classes. layer can be retransmitted completely or in several sensitive
Enchantment layers are not retransmittable. classes. Enchantment layers are not retransmittable.
The fine-grained redundancy in conjunction with bitrate scalability The fine-grained redundancy in conjunction with bitrate scalability
allows application adjust the trade-off between overhead and allows applications to adjust the trade-off between overhead and
robustness against packet loss. Note, this approach supported robustness against packet loss. Note that this approach is supported
natively within a packet and requires no out-of-band signals or natively within a packet and requires no out-of-band signals or
session initialization procedures. session-initialization procedures.
Main IP-MR features are as the following: The main IP-MR features are as follows:
o High quality wideband speech codec. o High-quality wideband speech codec.
o Bitrate scalable with 6 average rates from 7.7 to 34.2 kbps. o Bitrate scalable with 6 average rates from 7.7 to 34.2 kbps.
o Built-in discontinuous transmission (DTX) and comfort noise o Built-in discontinuous transmission (DTX) and comfort noise
generation (CNG) support. generation (CNG) support.
o Flexible in-band redundancy control scheme for packet loss o Flexible in-band redundancy control scheme for packet-loss
protection. protection.
3. Payload Format 3. Payload Format
The payload format consists of the RTP header, and IP-MR payload. The payload format consists of the RTP header and the IP-MR payload.
3.1. RTP Header Usage 3.1. RTP Header Usage
The format of the RTP header is specified in RFC 1889. This payload The format of the RTP header is specified in [RFC3550]. This payload
format uses the fields of the header in a manner consistent with that format uses the fields of the header in a manner consistent with that
specification. specification.
The RTP timestamp corresponds to the sampling instant of the first The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame-block in the packet. The timestamp sample encoded for the first frame-block in the packet. The
clock frequency SHALL be 16 kHz. The duration of one frame is 20 ms, timestamp clock frequency SHALL be 16 kHz. The duration of one frame
this corresponding to 320 samples per frame. Thus the timestamp is is 20 ms, which corresponds to 320 samples per frame. Thus, the
increased by 320 for each consecutive frame. The timestamp is also timestamp is increased by 320 for each consecutive frame. The
used to recover the correct decoding order of the frame-blocks. timestamp is also used to recover the correct decoding order of the
frame-blocks.
The RTP header marker bit (M) SHALL be set to 1 whenever the first The RTP header marker bit (M) SHALL be set to 1 whenever the first
frame-block carried in the packet is the first frame-block in a frame-block carried in the packet is the first frame-block in a
talkspurt (see definition of the talkspurt in Section 4.1 talkspurt (see definition of talkspurt in Section 4.1 of [RFC3551]).
[RFC 3551]). For all other packets, the marker bit SHALL be set to For all other packets, the marker bit SHALL be set to zero (M=0).
zero (M=0).
The assignment of an RTP payload type for the format defined in this The assignment of an RTP payload type for the format defined in this
memo is outside the scope of this document. The RTP profiles in use memo is outside the scope of this document. The RTP profiles in use
currently mandate binding the payload type dynamically for this currently mandate binding the payload type dynamically for this
payload format. This is basically necessary because the payload type payload format. This is basically necessary because the payload type
expresses the configuration of the payload itself, i.e. basic or expresses the configuration of the payload itself, i.e., basic or
interleaved mode, and the number of channels carried. interleaved mode, and the number of channels carried.
The remaining RTP header fields are used as specified in [RFC 3550]. The remaining RTP header fields are used as specified in [RFC3550].
3.2. RTP Payload Structure 3.2. RTP Payload Structure
The IP-MR payload composed of two payloads, one for current (speech) The IP-MR payload is composed of two payloads, one for current speech
speech and one for redundancy. Both of payloads are represented in a and one for redundancy. Both payloads are represented in this form:
form of: Header, Table of contents (TOC) and Data. Redundancy payload Header, Table of Contents (TOC), and Data. Redundancy payload
carries data for preceding and pre-preceding packets. carries data for preceding and pre-preceding packets.
+--------+-----+----------------------+- - - - +- - +- - - - - + +--------+-----+----------------------+- - - - +- - +- - - - - +
| Header | TOC | Data | Header | TOC | Data | | Header | TOC | Data | Header | TOC | Data |
+--------+-----+----------------------+- - - - +- - +- - - - - + +--------+-----+----------------------+- - - - +- - +- - - - - +
|<- Speech -------------------------->|<- Redundancy (opt) ---->| |<- Speech -------------------------->|<- Redundancy (opt) ---->|
3.3. Speech Payload Header 3.3. Speech Payload Header
This header carries parameters which are common for all frames in the This header carries parameters that are common for all frames in the
packet: packet:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
|T| CR | BR |D|A|GR |R| |T| CR | BR |D|A|GR |R|
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
o T (1 bit): Reserved. MUST be always set to 0. Receiver MAY o T (1 bit): Reserved. MUST always be set to 0. Receiver MAY
discard packet if 'T' bit is not equal to 0. discard packet if the 'T' bit is not equal to 0.
o CR (3 bits): Coding rate index - top enchantment layer o CR (3 bits): Coding rate index - top enchantment layer available.
available. The CR value 7 (NO_DATA) indicates that there is no The CR value 7 (NO_DATA) indicates that there is no speech data
speech data (and speech TOC accordingly) in the payload. This MAY (and thus no speech TOC) in the payload. This MAY be used to
be used to transmit redundancy data only. transmit redundancy data only.
o BR (3 bits): Base rate index - base layer bitrate. Speech o BR (3 bits): Base rate index - base layer bitrate. Speech payload
payload can be scaled to any rate index between BR and CR. Packets can be scaled to any rate index between BR and CR. Packets with
with BR = 6 or BR > CR MUST be discarded. Redundancy data is also BR = 6 or BR > CR MUST be discarded. Redundancy data is also
considered as having a base rate of BR. considered to have a base rate of BR.
o D (1 bit): Reserved. MUST be always set to 1. Receiver MAY o D (1 bit): Reserved. MUST always be set to 1. Receiver MAY
discard packet if 'D' bit is zero. discard packet if the 'D' bit is zero.
o A (1 bit): Byte-alignment. The value of 1 specifies that padding o A (1 bit): Byte alignment. The value of 1 specifies that padding
bits were added to enable each compressed frame (3.5) starts with bits were added to enable each compressed frame (3.5) to start
the byte (8 bit) boundary. The value of 0 specifies unaligned with the byte (8-bit) boundary. The value of 0 specifies
frames. Note, speech payload is always padded to byte boundary unaligned frames. Note that the speech payload is always padded
independently on 'A' bit value. to the byte boundary independently on an 'A' bit value.
o GR (2 bits): Number of frames in packet (grouping size). Actual o GR (2 bits): Number of frames in packet (grouping size). Actual
grouping size is GR + 1, thus maximum grouping supported is 4. grouping size is GR + 1; thus, the maximum grouping supported is
4.
o R (1 bit): Redundancy presence. Value of 1 indicates redundancy o R (1 bit): Redundancy presence. Value of 1 indicates redundancy
payload presence. payload presence.
Note, the values of 'T' and 'D' bits are fixed, any other values are Note that the values of 'T' and 'D' bits are fixed; any other values
not allowed by specification. padding Padding bits ('P' bits) MUST be are not allowed by specification. Padding bits ('P' bits) MUST
always set to zero. always be set to zero.
The following table defines mapping between rate index and rate The following table defines the mapping between rate index and rate
value: value:
+------------+--------------+ +------------+--------------+
| rate index | avg. bitrate | | rate index | avg. bitrate |
+------------+--------------+ +------------+--------------+
| 0 | 7.7 kbps | | 0 | 7.7 kbps |
| 1 | 9.8 kbps | | 1 | 9.8 kbps |
| 2 | 14.3 kbps | | 2 | 14.3 kbps |
| 3 | 20.8 kbps | | 3 | 20.8 kbps |
| 4 | 27.9 kbps | | 4 | 27.9 kbps |
| 5 | 34.2 kbps | | 5 | 34.2 kbps |
| 6 | (reserved) | | 6 | (reserved) |
| 7 | NO_DATA | | 7 | NO_DATA |
+------------+--------------+ +------------+--------------+
The value of 6 is reserved. If receiving this value the packet MUST The value of 6 is reserved. If receiving this value, the packet MUST
be discarded. be discarded.
3.4. Speech Payload Table of Contents 3.4. Speech Payload Table of Contents
The speech TOC is a bit mask indicating the presence of each frame in The speech TOC is a bitmask indicating the presence of each frame in
the packet. TOC is only available if 'CR' value is not equal to 7 the packet. TOC is only available if the 'CR' value is not equal to
(NO_DATA). 7 (NO_DATA).
0 1 2 3 0 1 2 3
+-+-+-+-+ +-+-+-+-+
|E|E|E|E| |E|E|E|E|
+-+-+-+-+ +-+-+-+-+
|<----->| <-- #(GR+1) |<----->| <-- #(GR+1)
o E (1 bit): Frame existence indicator. The value of 0 indicates o E (1 bit): Frame existence indicator. The value of 0 indicates
speech data does not present for corresponding frame. IP-MR speech data is not present for the corresponding frame. The IP-MR
encoder sets E flag to 0 for the periods of silence in DTX mode. encoder sets the 'E' flag to 0 for the periods of silence in DTX
Application MUST set this bit to 0 if the frame is known to be mode. Applications MUST set this bit to 0 if the frame is known
damaged. to be damaged.
3.5. Speech Payload Data 3.5. Speech Payload Data
Speech data contains (GR+1) compressed IP-MR frames (20ms of data). Speech data contains (GR+1) compressed IP-MR frames (20 ms of data).
Compressed frame have zero length if corresponding TOC flag is zero. A compressed frame has a length of zero if the corresponding TOC flag
is zero.
The beginning of each compressed frame is aligned if 'A' bit is The beginning of each compressed frame is aligned if the 'A' bit is
nonzero, while the end of speech payload is always aligned to a byte nonzero, while the end of the speech payload is always aligned to a
(8 bit) boundary: byte (8-bit) boundary:
+- - -+------------+------------+------------+------------+ +- - -+------------+------------+------------+------------+
| TOC | Frame1 | Frame2 | Frame3 | Frame4 | | TOC | Frame1 | Frame2 | Frame3 | Frame4 |
+- - -+------------+------------+------------+------------+ ALWAYS +- - -+------------+------------+------------+------------+ ALWAYS
|<- aligned |<- aligned |<- aligned |<- aligned |<- ALIGNED |<- aligned |<- aligned |<- aligned |<- aligned |<- ALIGNED
Marked regions MUST be padded only if 'A' bit is set to '1'. Marked regions MUST be padded only if the 'A' bit is set to '1'.
The compressed frame structure is the following: The compressed frame structure is as follows:
|<---- sensitive classes ------>|<----- enchantment layers -------->| |<---- sensitive classes ------>|<----- enchantment layers -------->|
+-------------------------------+----+-----+------+- - - - - +------+ +-------------------------------+----+-----+------+- - - - - +------+
| L1 (Base Layer) | L2 | L3 | L4 | | LN | | L1 (Base Layer) | L2 | L3 | L4 | | LN |
+-------------------------------+----+-----+------+- - - - - +------+ +-------------------------------+----+-----+------+- - - - - +------+
|<- A --->|<- B ->| ... |<- F ->| | |<- A --->|<- B ->| ... |<- F ->| |
|<- BR rate ------------------->| | |<- BR rate ------------------->| |
|<- CR rate ------------------------------------------------------->| |<- CR rate ------------------------------------------------------->|
The Annex A of this document provides helper routine written in "C" Appendix A of this document provides a helper routine written in "C"
which MUST be used to extract sensitivity classes and enchantment that MUST be used to extract sensitivity classes and bounds for the
layers bounds from the compressed frame data. enchantment layers from the compressed frame data.
3.6. Redundancy Payload Header 3.6. Redundancy Payload Header
The redundancy payload presence is signaled by R bit of speech The redundancy payload presence is signaled by the 'R' bit of the
payload header. Redundancy header is composed of two fields of 3 bits speech payload header. The redundancy header is composed of two
each: fields of 3 bits each:
0 1 2 3 4 5 0 1 2 3 4 5
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| CL1 | CL2 | | CL1 | CL2 |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Both of 'CL1' and 'CL2' fields specify the sensitivity classes The 'CL1' and 'CL2' fields both specify the sensitivity classes
available for preceding and pre-preceding packets correspondingly. available for preceding and pre-preceding packets respectively.
+-------+--------------------+ +-------+--------------------+
| CL | Redundancy classes | | CL | Redundancy classes |
| | available | | | available |
+-------+--------------------+ +-------+--------------------+
| 0 | NONE | | 0 | NONE |
| 1 | A | | 1 | A |
| 2 | A-B | | 2 | A-B |
| 3 | A-C | | 3 | A-C |
| 4 | A-D | | 4 | A-D |
| 5 | A-E | | 5 | A-E |
| 6 | A-F | | 6 | A-F |
| 7 | (reserved) | | 7 | (reserved) |
+-------+--------------------+ +-------+--------------------+
Receiver can reconstruct base layer of preceding packets completely A receiver can reconstruct the base layer of preceding packets
(CL=6) or partially (0<CL< 6) based on sensitivity classes delivered. completely (CL=6) or partially (0<CL< 6) based on the sensitivity
Decoder MUST discard redundancy payload if CL is equal to 0 or 7. classes delivered. A decoder MUST discard the redundancy payload if
'CL' is equal to 0 or 7.
Note, the index of the base rate and grouping parameter are not Note that the index of the base rate and grouping parameter is not
transmitted for redundancy payload. Application MUST assume that 'BR' transmitted for the redundancy payload. Applications MUST assume
and 'GR' are the same as for current packet. that 'BR' and 'GR' are the same as for the current packet.
3.7. Redundancy Payload Table of Contents 3.7. Redundancy Payload Table of Contents
The redundancy TOC is a bit mask indicating the presence of each The redundancy TOC is a bitmask indicating the presence of each frame
frame in the redundancy payload. Redundancy TOC is only available if in the redundancy payload. The redundancy TOC is only available if
'CL' value is not equal to 0 or 7. the 'CL' value is not equal to 0 or 7.
0 1 ... 0 1 ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|E|E|E|E|E|E|E| |E|E|E|E|E|E|E|E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |<----->| pre-preceding payload #(GR+1) | |<----->| pre-preceding payload #(GR+1)
|<----->| preceding payload #(GR+1) |<----->| preceding payload #(GR+1)
o E (1 bit): Redundancy frame existence indicator. The value of 0 o E (1 bit): Redundancy frame existence indicator. The value of 0
indicates redundancy data does not present for corresponding frame. indicates redundancy data is not present for corresponding frame.
3.8. Redundancy Payload Data 3.8. Redundancy Payload Data
IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any
damage of class 'A' bits cause significant reconstruction artifacts damage of class 'A' bits causes significant reconstruction artifacts
while the loss in class 'F' may be even not perceived by the while the loss in class 'F' may not even be perceived by the
listener. Note, only base layer in a bitstream is represented as a listener. Note that only the base layer in a bitstream is
set of classes. Together, the set of sensitivity classes approach and represented as a set of classes. Together, the sensitivity classes'
redundancy allows IP-MR duplicate frames through the packets to approach and redundancy allow IP-MR duplicate frames through the
improve robustness against packet loss. packets to improve robustness against packet loss.
Redundancy data carries a number of sensitivity classes for preceding Redundancy data carries a number of sensitivity classes for preceding
and pre-preceding packets as indicated by 'CL1' and 'CL2' fields of and pre-preceding packets as indicated by the 'CL1' and 'CL2' fields
redundancy header. The sensitivity classes data is available of the redundancy header. The sensitivity classes' data is available
individually for each frame only if corresponding 'E' bit of individually for each frame only if the corresponding 'E' bit of the
redundancy TOC is nonzero: redundancy TOC is nonzero:
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+ +---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|A-C|A-B|1000|1001|cl_A1|cl_B1|cl_C1|cl_A1|cl_B1|cl_A4|cl_B4| |A-C|A-B|1000|1001|cl_A1|cl_B1|cl_C1|cl_A1|cl_B1|cl_A4|cl_B4|
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+ +---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|<- CL >|<- TOC ->|<- preceding --->|<- pre-preceding ----->| |<- CL >|<- TOC ->|<- preceding --->|<- pre-preceding ----->|
Redundancy data is only available if the base rates (BRs) and coding
rates (CRs) of preceding and pre-preceding packets are the same as
for the current packet.
Redundancy data only available if base (BR) and coding (CR) rates of A receiver MAY use redundancy data to compensate for packet loss
preceding and pre-preceding packets are the same as for the current (note that in this case, the 'CL' field MUST also be passed to the
packet. decoder). The helper routine provided in Appendix A MUST be used to
extract sensitivity classes' length for each frame. The following
Receiver MAY use redundancy data to compensate packet loss, note in pseudocode describes the sequence of operations:
this case the 'CL' field MUST be also passed to decoder. Helper
routine provided in Annex A MUST be used to extract sensitivity
classes length for each frame. The following pseudo code describes
the sequence of operations:
int sensitivityBits[numOfRedundancyFrames][6]; int sensitivityBits[numOfRedundancyFrames][6];
int redundancyBits [numOfRedundancyFrames]; int redundancyBits [numOfRedundancyFrames];
for(i = 0 ; i < numOfRedundancyFrames; i++) { for(i = 0 ; i < numOfRedundancyFrames; i++) {
GetFrameInfo(CR, BR, pRedundancyPayloadData, dummy, GetFrameInfo(CR, BR, pRedundancyPayloadData, dummy,
sensitivityBits[i], dummy); sensitivityBits[i], dummy);
redundancyBits[i] = 0; redundancyBits[i] = 0;
for(j = 0; j < CL[i]; j++ ) { for(j = 0; j < CL[i]; j++ ) {
redundancyBits[i] += sensitivityBits[i][j]; redundancyBits[i] += sensitivityBits[i][j];
} }
flushBits(pRedundancyPayloadData, redundancyBits[i]); flushBits(pRedundancyPayloadData, redundancyBits[i]);
} }
4. Payload Examples 4. Payload Examples
This section provides detailed examples of IP-MR payload format. This section provides detailed examples of the IP-MR payload format.
4.1. Payload Carrying a Single Frame 4.1. Payload Carrying a Single Frame
The following diagram shows typical IP-MR payload carrying one (GR=0) The following diagram shows a typical IP-MR payload carrying one
non-aligned (A=0) speech frame without redundancy (R=0). The base (GR=0) non-aligned (A=0) speech frame without redundancy (R=0). The
layer is coded at 7.8 kbps (BR=0) while the coding rate is 9.7 kbps base layer is coded at 7.8 kbps (BR=0) while the coding rate is 9.7
(CR=1). The 'E' bit value of 1 signals that compressed frame bits kbps (CR=1). The 'E' bit value of 1 signals that compressed frame
s(0) - s(193) are present. There is a padding bit 'P' to maintain bits s(0) - s(193) are present. There is a padding bit 'P' to
speech payload size alignment. maintain speech payload size alignment.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|CR=1 |BR=0 |1|0|0 0|0|1|s(0) | |0|CR=1 |BR=0 |1|0|0 0|0|1|s(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| s(193)|P| | s(193)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Payload Carrying Multiple Frames with Redundancy 4.2. Payload Carrying Multiple Frames with Redundancy
The following diagram shows a payload carrying 3 (GR=2) aligned (A=1) The following diagram shows a payload carrying 3 (GR=2) aligned (A=1)
speech frames with redundancy (R=1). The TOC value of '101' indicates speech frames with redundancy (R=1). The TOC value of '101'
speech data presents for a first (bits sp1(0)-sp1(92)) and third indicates speech data present for the first (bits sp1(0)-sp1(92)) and
frames (bits sp3(0)-sp3(171)). There is no enchantment layers because third frames (bits sp3(0)-sp3(171)). There are no enchantment layers
of base and coding rates are equal (BR=CR=0). Padding bit 'P' is because the base and coding rates are equal (BR=CR=0). The padding
inserted to maintain necessary alignment. bit 'P' is inserted to maintain necessary alignment.
The redundancy payload presents for both preceding and pre-preceding The redundancy payload present for both preceding and pre-preceding
payloads (CL1 = A-B, CL2=A), but redundancy data only available for a payloads (CL1 = A-B, CL2=A), but redundancy data is only available
5 (TOC='111011') of 6 (2*(GR+1)) frames. There are redundancy data of for 5 (TOC='111011') of 6 (2*(GR+1)) frames. There is redundancy
20, 39 and 35 bits for each three frames of preceding packet and 15 data of 20, 39, and 35 bits for each of the three frames of the
and 19 bits for two frames of pre-preceding packet. preceding packet and 15 and 19 bits for the two frames of the pre-
preceding packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|CR=0 |BR=0 |1|1|1 0|1|1 0 1|P|sp1(0) | |0|CR=0 |BR=0 |1|1|1 0|1|1 0 1|P|sp1(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 37 skipping to change at page 11, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(0) | |red1_2_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(38)|red1_3_AB(0) | |red1_2_AB(38)|red1_3_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_3_AB(34)|red2_2_A(0) red2_2_A(14)|red2_3_A(0) | | red1_3_AB(34)|red2_2_A(0) red2_2_A(14)|red2_3_A(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red2_3_A(18)|P|P|P|P| | red2_3_A(18)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Congestion Control 5. Congestion Control
The general congestion control considerations for transporting RTP The general congestion control considerations for transporting RTP
data applicable to IP-MR speech over RTP (see RTP [RFC 3550] and any data applicable to IP-MR speech over RTP (see RTP [RFC3550] and any
applicable RTP profile like AVP [RFC 3551]). However, the multi-rate applicable RTP profile like the Audio-Visual Profile (AVP)
capability of IP-MR speech coding provides a mechanism that may help [RFC3551]). However, the multi-rate capability of IP-MR speech
to control congestion, since the bandwidth demand can be adjusted by coding provides a mechanism that may help to control congestion,
selecting a different encoding mode. since the bandwidth demand can be adjusted by selecting a different
encoding mode.
The number of frames encapsulated in each RTP payload highly The number of frames encapsulated in each RTP payload highly
influences the overall bandwidth of the RTP stream due to header influences the overall bandwidth of the RTP stream due to header
overhead constraints. Packetizing more frames in each RTP payload can overhead constraints. Packetizing more frames in each RTP payload
reduce the number of packets sent and hence the overhead from can reduce the number of packets sent and thus reduce the overhead
IP/UDP/RTP headers, at the expense of increased delay. from IP/UDP/RTP headers, at the expense of increased delay.
Due to scalability nature of IP_MR codec the transmission rate can be Due to the scalability nature of the IP_MR codec, the transmission
reduced at any transport stage to fit channel bandwidth. The minimal rate can be reduced at any transport stage to fit channel bandwidth.
rate is specified by BR field of payload header and can be is low as The minimal rate is specified by the BR field of the payload header
7.7 kbps. It is up to application to keep balance between coding and can be as low as 7.7 kbps. It is up to the application to keep
quality (high BR) and bitstream scalability (small BR). Because of the balance between coding quality (high BR) and bitstream
coding quality depends rather on coding rate(CR) than base rate (BR), scalability (low BR). Because coding quality depends on coding rate
it is NOT RECOMMENDED to use high BR values for real-time (CR) rather than base rate (BR), it is NOT RECOMMENDED to use high BR
communications. values for real-time communications.
Application MAY utilize bitstream redundancy to combat packet loss. Applications MAY utilize bitstream redundancy to combat packet loss.
But the gateway is free to chose any option to reduce transmission However, the gateway is free to chose any option to reduce the
rate - coding layer or redundancy bits can be dropped. Due to this transmission rate; the coding layer or redundancy bits can be
fact it is NOT RECOMMENDED application to increase total bitrate when dropped. Due to this fact, it is NOT RECOMMENDED for applications to
adding redundancy in a response to packet loss. increase the total bitrate when adding redundancy in response to
packet loss.
6. Security Considerations 6. Security Considerations
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 [RFC 3550] and in any applicable RTP profile. The main specification [RFC3550] and in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity, and format defined within this memo are confidentiality, integrity, and
source authenticity. Confidentiality is achieved by encryption of source authenticity. Confidentiality is achieved by encryption of
the RTP payload. Integrity of the RTP packets is achieved through a the RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity protection mechanism. Such a suitable cryptographic integrity-protection mechanism. Such a
cryptographic system may also allow the authentication of the source cryptographic system may also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at format should provide confidentiality, integrity protection, and
least source authentication capable of determining if an RTP packet source authentication at least capable of determining if an RTP
is from a member of the RTP session. packet is from a member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanisms to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this memo may vary. The security mechanisms are
application, the transport, and the signaling protocol employed. dependent on the application, the transport, and the signaling
Therefore, a single mechanism is not sufficient, although if protocol employed. Therefore, a single mechanism is not sufficient;
suitable, usage of the Secure Real-time Transport Protocol (SRTP) although if suitable, usage of the Secure Real-time Transport
[RFC 3711] is recommended. Other mechanisms that may be used are Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may
IPsec [RFC 4301] and Transport Layer Security (TLS) [RFC 5246] (RTP be used are IPsec [RFC4301] and Transport Layer Security (TLS)
over TCP); other alternatives may exist. [RFC5246] (RTP over TCP); other alternatives may exist.
This payload format does not exhibit any significant non-uniformity This payload format does not exhibit any significant non-uniformity
in the receiver side computational complexity for packet processing in the receiver-side computational complexity for packet processing
and thus is unlikely to pose a denial-of-service threat due to the and thus is unlikely to pose a denial-of-service threat due to the
receipt of pathological data. receipt of pathological data.
7. Payload Format Parameters 7. Payload Format Parameters
This section describes the media types and names associated with this This section describes the media types and names associated with this
payload format. payload format.
The IP-MR media subtype is defined as 'ip-mr_v2.5'. This subtype was The IP-MR media subtype is defined as 'ip-mr_v2.5'. This subtype was
registered to specify internal codec version. Later, this version was registered to specify an internal codec version. Later, this version
accepted as the final, the bitstream was frozen and IP-MR v2.5 was was accepted as final, the bitstream was frozen, and IP-MR v2.5 was
published under the name of IP-MR. Currently 'IP-MR' and 'IP-MR v2.5' published under the name of IP-MR. Currently, the terms 'IP-MR' and
terms are synonyms. The subtype name ip-mr_v2.5 is being uses in 'IP-MR v2.5' are synonyms. The subtype name 'ip-mr_v2.5' is being
implementations. used in implementations.
7.1. Media Type Registration 7.1. Media Type Registration
Media Type name: audio Media Type name: audio
Media Subtype name: ip-mr_v2.5 Media Subtype name: ip-mr_v2.5
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
These parameters apply to RTP transfer only. These parameters apply to RTP transfer only.
ptime: The media packet length in milliseconds. Allowed values ptime: The media packet length in milliseconds. Allowed values
are: 20, 40, 60 and 80. are: 20, 40, 60, and 80.
Encoding considerations: Encoding considerations:
This media type is framed and binary (see RFC 4288, Section 4.8). This media type is framed and binary (see RFC 4288, Section 4.8).
Security considerations: Security considerations:
See section 6 of RFC XXXX (RFC editor please replace with this RFC See Section 6 of RFC 6262.
number).
Interoperability considerations: Interoperability considerations:
none none
Published specification: Published specification:
RFC XXXX (RFC editor please replace with this RFC number) RFC 6262
Applications that use this media type: Applications that use this media type:
Real-time audio applications like voice over IP and Real-time audio applications like voice over IP,
teleconference, and multi-media streaming. teleconference, and multimedia streaming.
Additional information: Additional information:
none none
Person & email address to contact for further information: Person & email address to contact for further information:
Dmitry Yudin <yudin@spiritdsp.com> V. Sviridenko <vladimirs@spiritdsp.com>
Intended usage: Intended usage:
COMMON COMMON
Restrictions on usage: Restrictions on usage:
This media type depends on RTP framing and thus is only defined
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550].
fortransfer via RTP [RFC 3550].
Authors: Authors:
Sergey Ikonin <info@spiritdsp.com> Sergey Ikonin <info@spiritdsp.com>
Dmitry Yudin <yudin@spiritdsp.com> Dmitry Yudin <info@spiritdsp.com>
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group delegated from the IESG.
7.2. Mapping Media Type Parameters into SDP 7.2. Mapping Media Type Parameters into SDP
The information carried in the media type specification has a The information carried 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)
[RFC 4566], 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 IP-MR codec, the mapping is is used to specify sessions employing the IP-MR codec, the mapping is
as follows: as follows:
o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype (payload format name) goes in SDP "a=rtpmap" o The media type ("audio") goes in SDP "m=" as the media name.
as the encoding name. The RTP clock rate in "a=rtpmap" MUST 16000.
o The parameter "ptime" goes in the SDP "a=ptime" attributes. o The media subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name. The RTP clock rate in "a=rtpmap" MUST be
16000.
o The parameter "ptime" goes in the SDP "a=ptime" attribute.
Any remaining parameters go in the SDP "a=fmtp" attribute by copying Any remaining parameters go in the SDP "a=fmtp" attribute by copying
them directly from the media type parameter string as a semicolon- them directly from the media type parameter string as a semicolon-
separated list of parameter=value pairs. separated list of parameter=value pairs.
Note that the payload format (encoding) names are commonly shown in Note that the payload format (encoding) names are commonly shown in
upper case. Media subtypes are commonly shown in lower case. These uppercase. Media subtypes are commonly shown in lowercase. These
names are case-insensitive in both places. names are case-insensitive in both places.
8. IANA Considerations 8. IANA Considerations
One media type has been defined and needs registration in the media One media type (ip-mr_v2.5) has been defined and registered in the
types registry. media types registry.
9. Normative References 9. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 3550] 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.
[RFC 3551] 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.
[RFC 4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Description Protocol", RFC 4566, July 2006. Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC 3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
Norrman, K., "The Secure Real-Time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC 5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC 4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
10. Disclaimer [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
11. Legal Terms
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Process licenses each Contribution that he or she makes as part of (TLS) Protocol Version 1.2", RFC 5246, August 2008.
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
12. Authors' Addresses Appendix A. Retrieving Frame Information
SPIRIT DSP This appendix contains the C code for implementation of the frame-
Building 27, A. Solzhenitsyna street parsing function. This function extracts information about a coded
109004, Moscow, RUSSIA frame, including frame size, number of layers, size of each layer,
and size of perceptual sensitive classes.
Tel: +7 495 661-2178 A.1. get_frame_info.c
Fax: +7 495 912-6786
EMail: yudin@spiritdsp.com
APPENDIX A. RETRIEVING FRAME INFORMATION /*
This appendix contains the c-code for implementation of frame parsing Copyright (c) 2011 IETF Trust and the persons identified as
function. This function extracts information about coded frame authors of the code. All rights reserved.
including frame size, number of layers, size of each layer and size
of perceptual sensitive classes.
A.1. get_frame_info.c Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
/* - Redistributions of source code must retain the above copyright
notice, this list of conditions and
the following disclaimer.
Copyright (c) 2010 - Redistributions in binary form must reproduce the above copyright
IETF Trust and the persons identified as authors of the code. notice, this list of conditions and the following disclaimer in the
All rights reserved. documentation and/or other materials provided with the
distribution.
Redistribution and use in source and binary forms, with or without - Neither the name of Internet Society, IETF or IETF Trust, nor the
modification, are permitted provided that the following conditions names of specific contributors, may be used to endorse or promote
are met: products derived from this software without specific prior written
- Redistributions of source code must retain the above copyright permission.
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor
the names of specific contributors, may be used to endorse or
promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/ */
skipping to change at line 893 skipping to change at page 19, line 29
{ {
// count total frame size // count total frame size
int payloadBitCount = 0; int payloadBitCount = 0;
for (i = 0; i < *nLayers; i++) { for (i = 0; i < *nLayers; i++) {
payloadBitCount += pLayerBits[i]; payloadBitCount += pLayerBits[i];
} }
return payloadBitCount; return payloadBitCount;
} }
} }
Author's Address
Sergey Ikonin
SPIRIT DSP
Building 27, A. Solzhenitsyna Street
109004, Moscow
Russia
Tel: +7 495 661-2178
Fax: +7 495 912-6786
EMail: s.ikonin@gmail.com
 End of changes. 126 change blocks. 
398 lines changed or deleted 329 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/