draft-ietf-avt-rtp-ipmr-03.txt   draft-ietf-avt-rtp-ipmr-04.txt 
Audio/Video Transport Working Group SPIRIT DSP Audio/Video Transport Working Group S. Ikonin
Internet Draft SPIRIT DSP
Intended status: Informational Intended status: Informational May 20, 2009
RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-03.txt RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Copyright (c) 2009 IETF Trust and the persons identified as the document Copyright (c) 2009 IETF Trust and the persons identified as the document
authors. All rights reserved. authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions This document is subject to BCP 78 and the IETF Trust's Legal Provisions
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 14, 2009. This Internet-Draft will expire on November 20, 2009.
Abstract Abstract
This document specifies the payload format for packetization of SPIRIT This document specifies the payload format for packetization of SPIRIT
IP-MR encoded speech signals into the Real-time Transport Protocol IP-MR encoded speech signals into the Real-time Transport Protocol
(RTP). The payload format supports transmission of multiple frames per (RTP). The payload format supports transmission of multiple frames per
payload and introduced redundancy for robustness against packet loss. payload and introduced redundancy for robustness against packet loss.
Table of Contents Table of Contents
1. Introduction......................................................3 1. Introduction......................................................3
2. P-MR Codec Description............................................3 2. IP-MR Codec Description...........................................3
3. Payload Format....................................................4 3. Payload Format....................................................4
3.1. Payload Format Structure.....................................4 3.1. RTP Header Usage.............................................4
3.2. Payload Header...............................................4 3.2. Payload Format Structure.....................................5
3.3. Speech Table of Contents.....................................5 3.3. Payload Header...............................................5
3.4. Speech Data..................................................6 3.4. Speech Table of Contents.....................................6
3.5. Redundancy Header............................................6 3.5. Speech Data..................................................7
3.6. Redundancy Table of Contents.................................7 3.6. Redundancy Header............................................7
3.7. Redundancy Data..............................................7 3.7. Redundancy Table of Contents.................................8
4. Payload Examples..................................................7 3.8. Redundancy Data..............................................9
4.1. Payload Carrying a Single Frame..............................7 4. Payload Examples..................................................9
4.2. Payload Carrying Multiple Frames with Redundancy.............8 4.1. Payload Carrying a Single Frame..............................9
5. Media Type Registration...........................................9 4.2. Payload Carrying Multiple Frames with Redundancy............10
5.1. Registration of media subtype audio/ip-mr_v2.5...............9 5. Media Type Registration..........................................11
5.2. Mapping Media Type Parameters into SDP......................10 5.1. Registration of media subtype audio/ip-mr_v2.5..............11
6. Security Considerations..........................................11 5.2. Mapping Media Type Parameters into SDP......................12
7. IANA Considerations..............................................11 6. Security Considerations..........................................13
8. Normative References.............................................11 7. Congestion Control...............................................13
9. Author's Information ............................................11 8. IANA Considerations..............................................14
10. Disclaimer......................................................12 9. Normative References.............................................15
11. Legal Terms.....................................................12 10. Author(s) Information ..........................................15
11. Disclaimer......................................................15
12. Legal Terms.....................................................16
1. Introduction 1. Introduction
This document specifies the payload format for packetization of SPIRIT This document specifies the payload format for packetization of SPIRIT
IP-MR encoded speech signals into the Real-time Transport Protocol IP-MR encoded speech signals into the Real-time Transport Protocol
(RTP). The payload format supports transmission of multiple frames per (RTP). The payload format supports transmission of multiple frames per
payload and introduced redundancy for robustness against packet loss. payload and introduced redundancy for robustness against packet loss.
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
The codec operates on 20 ms frames at 16 kHz sampling rate and has an The codec operates on 20 ms frames at 16 kHz sampling rate and has an
algorithmic delay of 25ms. algorithmic delay of 25ms.
The IP-MR supports six wide band speech coding modes with respective bit The IP-MR supports six wide band speech coding modes with respective bit
rates ranging from about 7.7 to about 34.2 kbps. The coding mode can be rates ranging from about 7.7 to about 34.2 kbps. The coding mode can be
changed at any 20 ms frame boundary making possible to dynamically changed at any 20 ms frame boundary making possible to dynamically
adjust the speech encoding rate during a session to adapt to the varying adjust the speech encoding rate during a session to adapt to the varying
transmission conditions. transmission conditions.
The coded frame consists of multiple coding layers-base (or core) layer The coded frame consists of multiple coding layers - base (or core)
and several enhancement layers which are coded independently. These layer and several enhancement layers which are coded independently.
enhancement layers can be omitted and remaining base layer can be Onlythe core layer is mandatory to decode understandable speech and
meaningfully decoded without artifacts. This making bit stream scalable upper layers provide quality enhancement. These enhancement layers
and allows reduce bit rate during transmission without re-encoding. may be omitted and remaining base layer can be meaningfully decoded
without artifacts. This making the bit stream scalable and allows
reduce bit rate during transmission without re-encoding.
This memo specifies an optional form of redundancy coding within RTP for This memo specifies an optional form of redundancy coding within RTP
protection against packet loss. It is based on commonly known scheme for protection against packet loss. It is based on commonly known
when previously transmitted frames are aggregated together with new scheme when previously transmitted frames are aggregated together
ones. Each frame is retransmitted once in the following RTP payload with new ones. Each frame is retransmitted once in the following
packet. f(n-2)...f(n+4) denote a sequence of speech frames, and RTP payload packet. f(n-2)...f(n+4) denote a sequence of speech
p(n-1)...p(n+4) a sequence of payload packets: frames, and p(n-1)...p(n+4) a sequence of payload packets:
--+--------+--------+--------+--------+--------+--------+--------+-- --+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+-- --+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ----> <---- p(n-1) ---->
<----- p(n) -----> <----- p(n) ----->
<---- p(n+1) ----> <---- p(n+1) ---->
<---- p(n+2) ----> <---- p(n+2) ---->
<---- p(n+3) ----> <---- p(n+3) ---->
<---- p(n+4) ----> <---- p(n+4) ---->
But because of scalable nature of IP-MR codec there is no need to But because of the scalable nature of IP-MR codec there is no need to
duplicate a whole previous frame - only core layer may be retransmitted. duplicate the whole previous frame - only the core layer may be
This reduces redundancy overhead while keeping efficiency. Moreover, the retransmitted. This reduces redundancy overhead while keeping
speech bits encoded in core layer are divided on six classes (from A to efficiency. Moreover, the speech bits encoded in core layer are divided
F) of perceptual sensitivity to errors. Using these classes as on six classes (from A to F) of perceptual sensitivity to errors. Using
introduced redundancy make possible to adjust trade-off between overhead these classes as introduced redundancy make possible to adjust trade-off
and robustness against packet loss. between overhead and robustness against packet loss.
The mechanism described does not really require signaling at the session The mechanism described does not really require signaling at the session
setup. The sender is responsible for selecting an appropriate amount of setup. The sender is responsible for selecting an appropriate amount of
redundancy based on feedback about the channel conditions. redundancy based on feedback about the channel conditions.
The main codec characteristics can be summarized as follows: The main codec characteristics can be summarized as follows:
o Wideband, 16 kHz, speech codec o Wideband, 16 kHz, speech codec
o Adaptive multi rate with six modes from about 7.7 to about o Adaptive multi rate with six modes from about 7.7 to about
skipping to change at page 4, line 36 skipping to change at page 4, line 36
o Variable bit rate changing in accordance with actual speech o Variable bit rate changing in accordance with actual speech
content content
o Discontinuous Transmission (DTX), silence suppression and o Discontinuous Transmission (DTX), silence suppression and
comfort noise generation comfort noise generation
o In-band redundancy scheme for protection against packet loss o In-band redundancy scheme for protection against packet loss
3. Payload Format 3. Payload Format
3.1. Payload Format Structure The main purpose of the payload design for IP-MR is to maximize the
potential of the codec with as minimal overhead as possible. The payload
format allows changing parameters of the codecs (such as bit rate,
level of scalability, DTX and redundancy mode) without re-negotiation
at any packet boundary. This make possible dynamically adjust streaming
parametersin accordance to changing network conditions. The payload
format also supports aggregation of multiple consecutive frames
(up to 4) in a payload. That allows controlling trade-off between
delay and header overhead.
3.1. RTP Header Usage
The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame-block in the packet. The timestamp
clock frequency SHALL be 16 kHz. The duration of one frame is 20 ms,
corresponding to 320 samples at 16 kHz. Thus the timestamp is increased
by 320 for each consecutive frame. The 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
frame-block carried in the packet is the first frame-block in a
talkspurt (see definition of the talkspurt in Section 4.1 [RFC 3551]).
For all other packets, the marker bit SHALL be set to zero (M=0).
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
currently mandate binding the payload type dynamically for this payload
format. This is basically necessary because the payload type expresses
the configuration of the payload itself, i.e. basic or interleaved mode,
and the number of channels carried.
The remaining RTP header fields are used as specified in [RFC 3550].
3.2. Payload Format Structure
The IP-MR payload format consists of a payload header with general The IP-MR payload format consists of a payload header with general
information about packet, a speech table of contents (TOC), and speech information about packet, a speech table of contents (TOC), and speech
data. An optional redundancy section follows after speech data. The data. An optional redundancy section follows after speech data. The
redundancy section consists of redundancy header, redundancy TOC and redundancy section consists of redundancy header, redundancy TOC and
redundancy data payload. redundancy data payload.
T 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 |
+---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +
3.2. Payload Header 3.3. 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 o T (1 bit): Reserved compatibility with future extensions. SHOULD
be set to 0. be set to 0.
o CR (3 bits): coding rate of frame(s) in this packet, as per the o CR (3 bits): coding rate of frame(s) in this packet, as per the
following table: following table:
+-------+--------------+ +-------+--------------+
| CR | avg. bitrate | | CR | avg. bitrate |
+-------+--------------+ +-------+--------------+
| 0 | 7.7 kbps | | 0 | 7.7 kbps |
| 1 | 9.8 kbps | | 1 | 9.8 kbps |
skipping to change at page 5, line 27 skipping to change at page 6, line 25
| 5 | 34.2 kbps | | 5 | 34.2 kbps |
| 6 | (reserved) | | 6 | (reserved) |
| 7 | NO_DATA | | 7 | NO_DATA |
+-------+--------------+ +-------+--------------+
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 speech TOC accordingly) in the payload. This MAY be used to transmit
redundancy data only. The value 6 is reserved. If receiving this value redundancy data only. The value 6 is reserved. If receiving this value
the packet SHOULD be discarded. 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 using the table for CR. Values in the range 0-5 indicate bitrates
for packet SHOULD be discarded. The base rate is the lowest rate for core layer, same as for packet SHOULD be discarded. The base
for scalability, so speech payload can be scaled down not lower rate is the lowest rate for scalability, so speech payload can
than BR value. If a received packet has BR > CR then during be scaled down not lower than BR value. If a received packet has
decoding it will be assumed that BR = CR. 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. MUST be byte-aligned. This mode speeds up speech data access.
The A=0 value specifies bandwidth-efficient mode with no byte The A=0 value specifies bandwidth-efficient mode with no byte
alignment(including end of header). 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. grouping size is GR + 1, thus maximum grouping supported is 4.
o R (1 bit): redundancy presence bit. If R=1 then the packet o R (1 bit): redundancy presence bit. If R=1 then the packet
contains redundancy information for lost packets recovery. contains redundancy information for lost packets recovery.
In this case after speech data the redundancy section is present. In this case after speech data the redundancy section is present.
3.3. Speech Table of Contents 3.4. Speech Table of Contents
The speech TOC contains entries for each frame in packet (grouping size The speech TOC contains entries for each frame in packet (grouping size
in total). Each entry contains a single field: 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 corresponding frame is absent and the receiver should set
special LOST_FRAME flag for decoder. This can be followed by the special LOST_FRAME flag for decoder. This can be followed by the
lost frame itself or by empty frames generated by the encoder lost frame itself or by empty frames generated by the encoder
during silence intervals in DTX mode. during silence intervals in DTX mode.
Note that if CR flag from payload header is 7 (NO_DATA) then speech TOC Note that if CR flag from payload header is 7 (NO_DATA) then speech TOC
is empty. is empty.
3.4. Speech Data 3.5. Speech Data
Speech data of a payload contains one or more speech frames or comfort Speech data of a payload contains one or more speech frames or comfort
noise frames, as specified in the speech TOC of the payload. 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 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 header.
the codec and can be calculated after decoding. The size of coded speech frame is variable due to the nature of codec.
The Encoder's algorithm decides what size of each frame is and returns
it after encoding. In order to save bandwidth the size is not placed
into payload obviously. Decoder can calculate frame size by its content
and returns it to the top level application. This way a size of each
frame can be obtained. Moreover, there is a special service function
that returns frame size without total decoding which may be used for
this purpose.
3.5. Redundancy Header 3.6. 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:
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
skipping to change at page 7, line 5 skipping to change at page 8, line 21
| 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 6 Each specifier takes 3 bits, thus the total redundancy header size is 6
bits. bits.
3.6. Redundancy Table of Contents 3.7. Redundancy Table of Contents
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkt1 Entries| Pkt2 Entries| | Pkt1 Entries| Pkt2 Entries|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The redundancy TOC contains entries for redundancy frames from preceding The redundancy TOC contains entries for redundancy frames from preceding
and pre-preceding packets. Each entry takes 1 bit like speech TOC entry and pre-preceding packets. Each entry takes 1 bit like speech TOC entry
(3.3): (3.3):
0 0
skipping to change at page 7, line 30 skipping to change at page 9, line 5
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.
o For each preceding and pre-preceding packet the number of entries 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 is equal to the grouping size of the current packet. E.g. maximum
number of entries is 4*2 = 8. number of entries is 4*2 = 8.
o If class specifier in the redundancy header is CL=0 (NO_DATA) o If class specifier in the redundancy header is CL=0 (NO_DATA)
then there is no entries for corresponding packet redundancy. then there is no entries for corresponding packet redundancy.
3.7. Redundancy Data 3.8. Redundancy Data
Redundancy data of a payload contains redundancy information for one or Redundancy data of a payload contains redundancy information for one or
more speech frames or comfort noise frames that may be lost during more speech frames or comfort noise frames that may be lost during
transition, as specified in the redundancy TOC of the payload. Actually transition, as specified in the redundancy TOC of the payload. Actually
redundancy is the most important part of preceding frames representing redundancy is the most important part of preceding frames representing
20 ms of speech. This data MAY be used for partial reconstruction of 20 ms of speech. This data MAY be used for partial reconstruction of
lost frames. The amount of available redundancy is specified by CL flag lost frames. The amount of available redundancy is specified by CL flag
in redundancy header section (3.5). This flag SHOULD be passed to in redundancy header section (3.5). This flag SHOULD be passed to
decoder. The length of redundancy frame is variable and can be 281 decoder. The length of redundancy frame is variable and can be 281
calculated after decoding. calculated after decoding.
skipping to change at page 11, line 7 skipping to change at page 13, line 15
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 upper case. Media subtypes are commonly shown in lower case. These
names are case-insensitive in both places. names are case-insensitive in both places.
6. Security Considerations 6. Security Considerations
RTP packets using the payload format defined in this specification are RTP packets using the payload format defined in this specification
subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC 3550], and any appropriate RTP profile. This implies specification [RFC 3550] and in any applicable RTP profile. The main
that confidentiality of the media streams is achieved by encryption. security considerations for the RTP packet carrying the RTP payload
Encryption may be performed after compression so there is no conflict format defined within this memo are confidentiality, integrity, and
between the two operations. source authenticity. Confidentiality is achieved by encryption of the
RTP payload. Integrity of the RTP packets is achieved through a suitable
cryptographic integrity protection mechanism. Such a cryptographic
system may also allow the authentication of the source of the payload.
A suitable security mechanism for this RTP payload format should
provide confidentiality, integrity protection, and at least source
authenticationcapable of determining if an RTP packet is from a
member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signaling protocol employed.
Therefore, a single mechanism is not sufficient, although if suitable,
usage of the Secure Real-time Transport Protocol (SRTP) [RFC 3711] is
recommended. Other mechanisms that may be used are IPsec [RFC 4301]
and Transport Layer Security (TLS) [RFC 5246] (RTPover TCP); other
alternatives may exist.
This payload format does not exhibit any significant non-uniformity in This payload format does not exhibit any significant non-uniformity in
the receiver side computational complexity for packet processing, and the receiver side computational complexity for packet processing, and
thus is unlikely to pose a denial-of-service threat due to the receipt thus is unlikely to pose a denial-of-service threat due to the receipt
of pathological data. of pathological data.
7. IANA Considerations 7. Congestion Control
The general congestion control considerations for transporting RTP data
apply; see RTP [RFC 3550] and any applicable RTP profile like AVP
[RFC 3551]. However, the multi-rate capability of IP-MR speech coding
provides a mechanism that may help to control congestion, since the
bandwidth demand can be adjusted by selecting a different encoding mode.
The bit rate scalability of IP-MR codec allows reducing voice traffic
by omitting enhancement layers without re-encoding. This provides
additional means for congestion control. Some intermediate network
node MAY modify the IP-MR RTP payload by dropping some of the layers
during transmission to meet the available bandwidth requirements. In
case the payload is forwarded with modified content at least the base
layer MUST be preserved in the payload which is being delivered to
receiving side guarantees meaningful speech decoding without packet
loss concealment procedure.
The number of frames encapsulated in each RTP payload highly
influences the overall bandwidth of the RTP stream due to header
overhead constraints. Packetizing more frames in each RTP payload
can reduce the number of packets sent and hence the overhead from
IP/UDP/RTP headers, at the expense of increased delay.
If in-band redundancy scheme is used to protect against packet loss,
the amount of introduced redundancy will need to be regulated so that
the use of redundancy itself does not cause a congestion problem. In
other words, a sender SHALL NOT increase the total bitrate when adding
redundancy in response to packet loss, and needs instead to adjust it
down in accordance to the congestion control algorithm being run. Thus,
when adding redundancy, the media bitrate will need to be reduced to
provide room for the redundancy.
8. IANA Considerations
One media type has been defined and needs registration in the media One media type has been defined and needs registration in the media
types registry. types registry.
8. Normative References 9. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] 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 [RFC 3550] Schulzrinne, H., Casner, S., Frederick, R., and
V. Jacobson, "RTP: A Transport Protocol for Real-Time V. 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 Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC 4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC 4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
9. Author(s) Information [RFC 3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,
K., "The Secure Real-Time Transport Protocol (SRTP)", RFC
3711, March 2004.
Sergey Ikonin email: ikonin@spiritdsp.com [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
Internet Protocol", RFC 4301, December 2005.
10. Author(s) Information
Sergey Ikonin
email: ikonin@spiritdsp.com
Russia 109004 Russia 109004
Building 27, A. Solgenizyn street Building 27, A. Solgenizyn street
Tel: +7 495 661-2178 Tel: +7 495 661-2178
Fax: +7 495 912-6786 Fax: +7 495 912-6786
10. Disclaimer 11. Disclaimer
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10, Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this material 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 may not have granted the IETF Trust the right to allow modifications of
such material outside the IETF Standards Process. Without obtaining an such material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in such adequate license from the person(s) controlling the copyright in such
materials, this document may not be modified outside the IETF Standards materials, this document may not be modified outside the IETF Standards
Process, and derivative works of it may not be created outside the IETF 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 Standards Process, except to format it for publication as an RFC or to
translate it into languages other than English. translate it into languages other than English.
11. Legal Terms 12. Legal Terms
All IETF Documents and the information contained therein are provided on All IETF Documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 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 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF Trust takes no position regarding the validity or scope of any The IETF Trust takes no position regarding the validity or scope of any
 End of changes. 28 change blocks. 
71 lines changed or deleted 185 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/