Audio/Video Transport Working Group Andrey Setsko
Internet Draft SPIRIT DSP
Intended status: Informational April 02, 2008
Expires: September 03, 2008
RTP Payload Format for SPIRIT IP-MR Speech Codec Software
draft-ietf-avt-rtp-ipmr-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
This document may only be posted in an Internet-Draft.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 03, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
A.Setsko Expires September 03, 2008 [Page 1]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
Abstract
This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the Real-time Transport
Protocol (RTP). The payload format supports transmission of multiple
frames per payload, introduced redundancy for robustness against
packet loss, and payload format extension for future versions
compatibility.
Table of Contents
1. Introduction 2
2. IP-MR RTP Payload Formats 3
2.1. Standard Payload Format 3
2.1.1. Payload Format Structure 3
2.1.2. Payload Header 3
2.1.3. Speech Table of Contents 5
2.1.4. Speech Data 5
2.1.5. Redundancy Header 5
2.1.6. Redundancy Table of Contents 6
2.1.7. Redundancy Data 6
2.2. Payload Examples 8
2.2.1. Standard Payload Carrying a Single Frame 8
2.2.2. Standard Payload Carrying Multiple Frames with
Redundancy 8
2.2.3. Extended Payload Carrying a Single Frame 10
3. Media Type Registration 10
3.1. Registration of MIME media type audio/ip-mr_v2.5 10
3.2. Mapping Media Type Parameters into SDP 11
4. Security Consideration 12
5. Acknowledgments 12
6. Normative References 12
Author's Addresses 12
Intellectual Property Statement 13
Disclaimer of Validity 13
A.Setsko Expires September 03, 2008 [Page 2]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
1. Introduction
This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the Real-time Transport
Protocol (RTP). The payload format supports transmission of multiple
frames per payload, introduced redundancy for robustness against
packet loss, and payload format extension for future versions
compatibility.
2. IP-MR RTP Payload Formats
The payload has two formats: standard optimized for current use-cases
and extended for future versions compatibility. The payload format is
defined by first bit of header. Both of these formats will be
described bellow.
2.1. Standard Payload Format
2.1.1. Payload Format Structure
The standard payload consists of a payload header with general
information about packet, a speech table of contents (TOC), and
speech data. An optional redundancy section follows after speech
data. The redundancy section consists of redundancy header,
redundancy TOC and redundancy data payload.
The following diagram shows the standard payload format layout:
+---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +
| payload | speech | speech | redundancy | redundancy | redundancy |
| header | TOC | data | header | TOC | data |
+---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +
2.1.2. Payload Header
The payload header has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+
|T| CR | BR |D|A|GR |R|
+-+-+-+-+-+-+-+-+-+-+-+-+
o T (1 bit): Reserved compatibility with future extensions. Should be set
to 0.
A.Setsko Expires September 03, 2008 [Page 3]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
o CR (3 bits): coding rate of frame(s) in this packet, as per the
following table:
+-------+--------------+
| CR | avg. bitrate |
+-------+--------------+
| 0 | 7.7 kbps |
| 1 | 9.8 kbps |
| 2 | 14.3 kbps |
| 3 | 20.8 kbps |
| 4 | 27.9 kbps |
| 5 | 34.2 kbps |
| 6 | (reserved) |
| 7 | NO_DATA |
+-------+--------------+
Table 1 Coding rates of IP-MR codec
The CR value 7 (NO_DATA) indicates that there is no speech data (and
speech TOC accordingly) in the payload. This MAY be used to transmit
redundancy data only. The value 6 is reserved. If receiving this
value the packet SHOULD be discarded.
o BR (3 bits): base rate for core layer of frame(s) in this packet.
Values in the range 0-5 indicate bitrates for core layer, same as
for CR. Values 6 and 7 are reserved. If one of these values is
received the packet SHOULD be discarded. The base rate is the
lowest rate for scalability, so speech payload can be scaled down
not lower than BR value. If a received packet has BR > CR then
during decoding it will be assumed that BR = CR.
o D (1 bit): indicates if the DTX mode is allowed or not.
o A (1 bit): byte-aligned payload. If A=1 then all speech frames
MUST be byte-aligned. This mode speeds up speech data access. The
A=0 value specifies bandwidth-efficient mode with no byte
alignment (including end of header).
o GR (2 bits): number of frames in packet (grouping size). Actual
grouping size is GR + 1, thus maximum grouping supported is 4. If
greater grouping size is required the extended payload format
(sec. 2.2) MAY be used.
A.Setsko Expires September 03, 2008 [Page 4]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
o R (1 bit): redundancy presence bit. If R=1 then the packet
contains redundancy information for lost packets recovery. In this
case after speech TOC redundancy flags and TOC sections are
present. If R=0 then speech TOC is the last section of payload
header.
2.1.3. Speech Table of Contents
The speech TOC contains entries for each frame in packet (grouping
size in total). Each entry contains a single field:
0
+-+
|E|
+-+
o E (1 bit): frame existence indicator. If set to 0, this indicates
the corresponding frame is absent and the receiver should set the
teRxFrType to LOST_FRAME. This can be followed by the lost frame
itself or by empty frames generated by the encoder during silence
intervals in DTX mode.
Note that if CR field from coding flags is 7 (NO_DATA) then speech
TOC is empty.
2.1.4. Speech Data
Speech data of a payload contains one or more speech frames or
comfort noise frames, as specified in the speech TOC of the payload.
Each speech frame represents 20 ms of speech encoded with the rate
indicated in the CR and base rate indicated in BR field of the
payload header. The length of the speech frame is variable due to the
nature of the codec and can be calculated after decoding or by using
GetFrameInfo function detailed in [1].
2.1.5. Redundancy Header
If a packet contains redundancy (R field of payload header is 1) the
speech data is followed by redundancy header:
A.Setsko Expires September 03, 2008 [Page 5]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
0 1 2 3 4 5
+-+-+-+-+-+-+
| CL1 | CL2 |
+-+-+-+-+-+-+
Redundancy header consists of two fields. Each field contains class
specifier for redundancy partly taken from the preceding packet (CL1)
and pre-preceding packet (CL2), e.g. distant from the current packet
by 1 and 2 packets accordingly. The values are listed in the table
below:
+-------+-------------------+
| CL | amount redundancy |
+-------+-------------------+
| 0 | NONE |
| 1 | CLASS A |
| 2 | CLASS B |
| 3 | CLASS C |
| 4 | CLASS D |
| 5 | CLASS E |
| 6 | CLASS F |
| 7 | (reserved) |
+-------+-------------------+
Each specifier takes 3 bits, thus the total redundancy header size is
6 bits. In case of redundancy usage followed by preceding (or pre-
preceding) packet loss the receiver sets the special flag for decoder
with CL class specifier.
2.1.6. Redundancy Table of Contents
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkt1 Entries| Pkt2 Entries|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The redundancy TOC contains entries for redundancy frames from
preceding and pre-preceding packets. Each entry takes 1 bit like
speech TOC entry (2.1.3):
0
+-+
|E|
+-+
o E (1 bit): frame existence indicator. If set to 0, this indicates
the corresponding frame is absent.
A.Setsko Expires September 03, 2008 [Page 6]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
o For each preceding and pre-preceding packet the number of entries
is equal to the grouping size of the current packet. E.g. maximum
number of entries is 4*2 = 8.
o If class specifier in the redundancy header is CL=0 (NO_DATA) then
there?s no entries for corresponding packet redundancy.
2.1.7. Redundancy Data
Redundancy data of a payload contains redundancy information for one
or more speech frames or comfort noise frames that may be lost during
transition, as specified in the redundancy TOC of the payload.
Actually redundancy is the most important part of preceding frames
representing 20 ms of speech. The length of redundancy frame is
variable and can be calculated after decoding or by using
GetFrameInfo function detailed in [1].
A.Setsko Expires September 03, 2008 [Page 7]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
2.2. Payload Examples
2.2.1. Standard Payload Carrying a Single Frame
The following diagram shows a standard IP-MR payload carrying a
single speech frame without redundancy:
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|CR=1 |BR=0 |0|0|0 0|0|1|sp(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp(193)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the payload the speech frame is not damaged at the IP origin
(E=1), the coding rate is 9.7 kbps (CR=1), the base rate is 7.8 kbps
(BR=0), and the DTX mode is off. There is no byte alignment (A=0) and
no redundancy (R=0). The encoded speech bits - s(0) to s(193) - are
placed immediately after TOC. Finally, one zero bit is added at the
end as padding to make the payload byte aligned.
2.2.2. Standard Payload Carrying Multiple Frames with Redundancy
The following diagram shows a payload that contains three frames, one
of them with no speech data. The coding rate is 7.7 kbps (CR=0), the
base rate is 7.7 kbps (BR=0), and the DTX mode is on. The speech
frames are byte aligned (A=1), so 1 zero bit is added at the end of
the header. Besides the speech frames the payload contains six
redundancy frames (three per each delayed packet).
The first speech frame consists of bits sp1(0) to sp1(92). After that
3 bits are added for byte alignment. The second frame does not
contain any speech information that is represented in the payload by
its TOC entry. The third frame consists of bits sp3(0) to sp3(171).
A.Setsko Expires September 03, 2008 [Page 8]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
The redundancy header follows after speech data. The one-packet-
delayed redundancy contains class A+B bits (CL1=2), and two-packet-
delayed redundancy contains class A bits (Cl2=1). The one-packet-
delayed redundancy contains three frames with 20, 39 and 35 bits
respectively. The first frame of two-packet-delayed redundancy is
absent, it is represented in its TOC entry, and two other frames have
sizes 15 and 19 bits.
Note that all speech frames are padded with zero bits for byte
alignment.
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|CR=2 |BR=1 |1|1|1 0|1|1 0 1|P|sp1(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp1(92)|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sp3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp3(171)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CL1=2|CL2=1|1 1 1|0 1 1|red1_1(0) red1_1(19)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2(0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_2(38)|red1_3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_3(34)|red2_2(0) red2_2(14)|red2_3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red2_3(18)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.Setsko Expires September 03, 2008 [Page 9]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
2.2.3. Extended Payload Carrying a Single Frame
The following diagram shows an extended IP-MR payload carrying a
single speech frame without redundancy:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|CR=1 |BR=0 |0|0|0 0|0|1|P|P|P|0 1 1|0| header extension data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |sp(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp(193)| optional payload extenson ...
+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - -
The standard header is the same as in example 2.3.1 except for the
first bit that is set to 1 to reflect extended payload type. The
standard header is padded with zeros to achieve byte alignment. After
that the size of header extension follows (HESZ=3). Then the header
extension data is placed. In 3 bytes (HESZ) from header extension
beginning, the standard speech payload starts. After that, the
optional payload extension MAY be added.
3. Media Type Registration
This section describes the media types and names associated with this
payload format.
3.1. Registration of MIME media type audio/ip-mr_v2.5
Type name: audio
Subtype name: ip-mr_v2.5
A.Setsko Expires September 03, 2008 [Page 10]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
Required parameters: none
Optional parameters:
o ptime: Gives the length of time in milliseconds represented by the
media in a packet. Allowed values are: 20, 40, 60 and 80.
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8).
Security considerations: See RFC 3550
Applications that use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
Person & email address to contact for further information:
Andrey Setsko <Setsko@spiritdsp.com>
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP (RFC 3550).
Author:
Andrey Setsko
3.2. Mapping Media Type Parameters into SDP
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (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
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" as
the encoding name. The RTP clock rate in "a=rtpmap" MUST 16000.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
A.Setsko Expires September 03, 2008 [Page 11]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
Any remaining parameters go in the SDP "a=fmtp" attribute by copying
them directly from the media type parameter string as a semicolon-
separated list of parameter=value pairs.
4. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [RFC3550], and any appropriate RTP profile. This
implies that confidentiality of the media streams is achieved by
encryption. Encryption may be performed after compression so there
is no conflict between the two operations.
This payload format does not exhibit any significant non-uniformity
in the receiver side computational complexity for packet processing,
and thus is unlikely to pose a denial-of-service threat due to the
receipt of pathological data.
5. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
6. Normative References
[1] SPIRIT IP-MR v2.5 User Guide, website http://spiritdsp.com
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Author's Addresses
Andrey Setsko
SPIRIT DSP
Russia 109004 B.Kommunisticheskaya st. 27
Email: Setsko@spiritdsp.com
A.Setsko Expires September 03, 2008 [Page 12]
Internet-Draft RTP Payload Format for SPIRIT IP-MR November 2007
Intellectual Property Statement
The IETF 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
this 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. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR 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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
A.Setsko Expires September 03, 2008 [Page 13]
