draft-ietf-avt-rtp-ipmr-00.txt   draft-ietf-avt-rtp-ipmr-01.txt 
Audio/Video Transport Working Group Andrey Setsko
Audio/Video Transport Working Group
Internet Draft SPIRIT DSP Internet Draft SPIRIT DSP
Intended status: Informational April 02, 2008 Intended status: Informational February 10, 2009
Expires: September 03, 2008
RTP Payload Format for SPIRIT IP-MR Speech Codec Software RTP Payload Format for SPIRIT IP-MR Speech Codec Software draft-ietf-avt-rtp-ipmr-01.txt
draft-ietf-avt-rtp-ipmr-00.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
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 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
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 document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at 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.
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 03, 2008. 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."
Copyright Notice The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html
Copyright (C) The IETF Trust (2007). The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html
A.Setsko Expires September 03, 2008 [Page 1] This Internet-Draft will expire on August 10, 2009.
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 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.
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 Table of Contents
1. Introduction 2 1. Introduction 2
2. IP-MR RTP Payload Formats 3 2. IP-MR RTP Payload Formats 2
2.1. Standard Payload Format 3 2.1. Standard Payload Format 3
2.1.1. Payload Format Structure 3 2.1.1. Payload Format Structure 3
2.1.2. Payload Header 3 2.1.2. Payload Header 3
2.1.3. Speech Table of Contents 5 2.1.3. Speech Table of Contents 4
2.1.4. Speech Data 5 2.1.4. Speech Data 4
2.1.5. Redundancy Header 5 2.1.5. Redundancy Header 5
2.1.6. Redundancy Table of Contents 6 2.1.6. Redundancy Table of Contents 5
2.1.7. Redundancy Data 6 2.1.7. Redundancy Data 6
2.2. Payload Examples 8 2.2. Payload Examples 6
2.2.1. Standard Payload Carrying a Single Frame 8 2.2.1. Standard Payload Carrying a Single Frame 6
2.2.2. Standard Payload Carrying Multiple Frames with 2.2.2. Standard Payload Carrying Multiple Frames with Redundancy 7
Redundancy 8 2.2.3. Extended Payload Carrying a Single Frame 8
2.2.3. Extended Payload Carrying a Single Frame 10 3. Media Type Registration 8
3. Media Type Registration 10 3.1. Registration of MIME media type audio/ip-mr_v2.5 8
3.1. Registration of MIME media type audio/ip-mr_v2.5 10 3.2. Mapping Media Type Parameters into SDP 9
3.2. Mapping Media Type Parameters into SDP 11 4. Security Considerations 10
4. Security Consideration 12 6. Normative References 10
5. Acknowledgments 12 Author's Addresses 10
6. Normative References 12 Expiration date 10
Author's Addresses 12 Legal Terms 10
Intellectual Property Statement 13
Disclaimer of Validity 13
A.Setsko Expires September 03, 2008 [Page 2]
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 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.
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 2. IP-MR RTP Payload Formats
The payload has two formats: standard optimized for current use-cases 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.
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. Standard Payload Format
2.1.1. Payload Format Structure 2.1.1. Payload Format Structure
The standard payload consists of a payload header with general 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.
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: The following diagram shows the standard payload format layout:
+---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +
| payload | speech | speech | redundancy | redundancy | redundancy | | payload | speech | speech | redundancy | redundancy | redundancy |
| header | TOC | data | header | TOC | data | | header | TOC | data | header | TOC | data |
+---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +
2.1.2. Payload Header 2.1.2. Payload Header
The payload header has the following format: The payload header has the following format:
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 compatibility with future extensions. Should be set o T (1 bit): Reserved compatibility with future extensions. Should be set to 0.
to 0.
A.Setsko Expires September 03, 2008 [Page 3] o CR (3 bits): coding rate of frame(s) in this packet, as per the following table:
o CR (3 bits): coding rate of frame(s) in this packet, as per the
following table:
+-------+--------------+ +-------+--------------+
| CR | avg. bitrate | | CR | 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 |
+-------+--------------+ +-------+--------------+
Table 1 Coding rates of IP-MR codec Table 1 Coding rates of IP-MR codec
The CR value 7 (NO_DATA) indicates that there is no speech data (and 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.
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. 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.
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 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 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).
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 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.
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] 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.
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 2.1.3. Speech Table of Contents
The speech TOC contains entries for each frame in packet (grouping The speech TOC contains entries for each frame in packet (grouping size in total). Each entry contains a single field:
size in total). Each entry contains a single field:
0 0
+-+ +-+
|E| |E|
+-+ +-+
o E (1 bit): frame existence indicator. If set to 0, this indicates 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.
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 Note that if CR field from coding flags is 7 (NO_DATA) then speech TOC is empty.
TOC is empty.
2.1.4. Speech Data 2.1.4. Speech Data
Speech data of a payload contains one or more speech frames or Speech data of a payload contains one or more speech frames or comfort noise frames, as specified in the speech TOC of the payload.
comfort noise frames, as specified in the speech TOC of the payload.
Each speech frame represents 20 ms of speech encoded with the rate 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].
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 2.1.5. Redundancy Header
If a packet contains redundancy (R field of payload header is 1) the If a packet contains redundancy (R field of payload header is 1) the speech data is followed by redundancy header:
speech data is followed by redundancy header:
A.Setsko Expires September 03, 2008 [Page 5]
0 1 2 3 4 5 0 1 2 3 4 5
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| CL1 | CL2 | | CL1 | CL2 |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Redundancy header consists of two fields. Each field contains class 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:
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 | | CL | amount redundancy |
+-------+-------------------+ +-------+-------------------+
| 0 | NONE | | 0 | NONE |
| 1 | CLASS A | | 1 | CLASS A |
| 2 | CLASS B | | 2 | CLASS B |
| 3 | CLASS C | | 3 | CLASS C |
| 4 | CLASS D | | 4 | CLASS D |
| 5 | CLASS E | | 5 | CLASS E |
| 6 | CLASS F | | 6 | CLASS F |
| 7 | (reserved) | | 7 | (reserved) |
+-------+-------------------+ +-------+-------------------+
Each specifier takes 3 bits, thus the total redundancy header size is 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.
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 2.1.6. Redundancy Table of Contents
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkt1 Entries| Pkt2 Entries| | Pkt1 Entries| Pkt2 Entries|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The redundancy TOC contains entries for redundancy frames from 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):
preceding and pre-preceding packets. Each entry takes 1 bit like
speech TOC entry (2.1.3):
0 0
+-+ +-+
|E| |E|
+-+ +-+
o E (1 bit): frame existence indicator. If set to 0, this indicates o E (1 bit): frame existence indicator. If set to 0, this indicates the corresponding frame is absent.
the corresponding frame is absent.
A.Setsko Expires September 03, 2008 [Page 6] 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 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 o If class specifier in the redundancy header is CL=0 (NO_DATA) then there is no entries for corresponding packet redundancy.
there?s no entries for corresponding packet redundancy.
2.1.7. Redundancy Data 2.1.7. Redundancy Data
Redundancy data of a payload contains redundancy information for one 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].
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]
2.2. Payload Examples 2.2. Payload Examples
2.2.1. Standard Payload Carrying a Single Frame 2.2.1. Standard Payload Carrying a Single Frame
The following diagram shows a standard IP-MR payload carrying a The following diagram shows a standard IP-MR payload carrying a
single speech frame without redundancy: single speech frame without redundancy:
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 |0|0|0 0|0|1|sp(0) | |0|CR=1 |BR=0 |0|0|0 0|0|1|sp(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 9, line ? skipping to change at page 6, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp(193)|P| | sp(193)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the payload the speech frame is not damaged at the IP origin 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.
(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 2.2.2. Standard Payload Carrying Multiple Frames with Redundancy
The following diagram shows a payload that contains three frames, one 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).
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 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).
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] 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.
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 Note that all speech frames are padded with zero bits for byte alignment.
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=2 |BR=1 |1|1|1 0|1|1 0 1|P|sp1(0) | |0|CR=2 |BR=1 |1|1|1 0|1|1 0 1|P|sp1(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 7 skipping to change at page 8, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_2(38)|red1_3(0) | | red1_2(38)|red1_3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_3(34)|red2_2(0) red2_2(14)|red2_3(0) | | red1_3(34)|red2_2(0) red2_2(14)|red2_3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red2_3(18)|P|P|P|P| | red2_3(18)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.3. Extended Payload Carrying a Single Frame 2.2.3. Extended Payload Carrying a Single Frame
The following diagram shows an extended IP-MR payload carrying a The following diagram shows an extended IP-MR payload carrying a single speech frame without redundancy:
single speech frame without redundancy:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|CR=1 |BR=0 |0|0|0 0|0|1|P|P|P|0 1 1|0| header extension data | |1|CR=1 |BR=0 |0|0|0 0|0|1|P|P|P|0 1 1|0| header extension data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |sp(0) | | |sp(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 30 skipping to change at page 8, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp(193)| optional payload extenson ... | sp(193)| optional payload extenson ...
+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - +-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - -
The standard header is the same as in example 2.3.1 except for the 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.
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 3. Media Type Registration
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.
3.1. Registration of MIME media type audio/ip-mr_v2.5 3.1. Registration of MIME media type audio/ip-mr_v2.5
Type name: audio Type name: audio
Subtype name: ip-mr_v2.5 Subtype name: ip-mr_v2.5
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
o ptime: Gives the length of time in milliseconds represented by the o ptime: Gives the length of time in milliseconds represented by the media in a packet. Allowed values are: 20, 40, 60 and 80.
media in a packet. Allowed values are: 20, 40, 60 and 80.
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8). This media type is framed binary data (see RFC 4288, Section 4.8).
Security considerations: See RFC 3550 Security considerations: See RFC 3550
Applications that use this media type: Applications that use this media type:
Audio and video streaming and conferencing tools. Audio and video streaming and conferencing tools.
Additional information: none Additional information: none
Person & email address to contact for further information:
Andrey Setsko <Setsko@spiritdsp.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP (RFC 3550).
Author: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).
Andrey Setsko
3.2. Mapping Media Type Parameters into SDP 3.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) [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:
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. * 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 media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST 16000.
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 * The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
"a=maxptime" attributes, respectively.
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- separated list of parameter=value pairs.
them directly from the media type parameter string as a semicolon-
separated list of parameter=value pairs.
4. Security Considerations 4. 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 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.
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. 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.
6. Normative References 6. Normative References
[1] SPIRIT IP-MR v2.5 User Guide, website http://spiritdsp.com [1] SPIRIT IP-MR v2.5 User Guide, website http://spiritdsp.com
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
RFC 3550, July 2003. [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Author's Addresses Author's Addresses
Andrey Setsko
SPIRIT DSP SPIRIT DSP
Russia 109004 B.Kommunisticheskaya st. 27 Russia
109004 B.Kommunisticheskaya st. 27
Email: Setsko@spiritdsp.com Tel: +7 495 661-2178
Fax: +7 495 912-6786
Intellectual Property Statement Email: Elena Berlizova berlizova@spiritdsp.com
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 Expiration date
This document and the information contained herein are provided on an This Internet-Draft will expire on August 09, 2009.
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Legal Terms
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 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 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 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.
Copyright (C) The IETF Trust (2007). 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.
This document is subject to the rights, licenses and restrictions 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.
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment 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.
Funding for the RFC Editor function is currently provided by the For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of 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.
Internet Society.
 End of changes. 75 change blocks. 
275 lines changed or deleted 91 lines changed or added

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