idnits 2.17.1 draft-ietf-avt-rtp-ipmr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.3 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. ** The document has an RFC 3978 Section 5.3 Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 389 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 02, 2008) is 5866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC4566' on line 438 -- Looks like a reference, but probably isn't: 'RFC3550' on line 458 == Unused Reference: '2' is defined on line 475, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 480, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (ref. '4') (Obsoleted by RFC 8866) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport Working Group Andrey Setsko 2 Internet Draft SPIRIT DSP 3 Intended status: Informational April 02, 2008 4 Expires: September 03, 2008 6 RTP Payload Format for SPIRIT IP-MR Speech Codec Software 7 draft-ietf-avt-rtp-ipmr-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 This document may only be posted in an Internet-Draft. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on September 03, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 A.Setsko Expires September 03, 2008 [Page 1] 46 Abstract 48 This document specifies the payload format for packetization of 49 SPIRIT IP-MR encoded speech signals into the Real-time Transport 50 Protocol (RTP). The payload format supports transmission of multiple 51 frames per payload, introduced redundancy for robustness against 52 packet loss, and payload format extension for future versions 53 compatibility. 55 Table of Contents 57 1. Introduction 2 58 2. IP-MR RTP Payload Formats 3 59 2.1. Standard Payload Format 3 60 2.1.1. Payload Format Structure 3 61 2.1.2. Payload Header 3 62 2.1.3. Speech Table of Contents 5 63 2.1.4. Speech Data 5 64 2.1.5. Redundancy Header 5 65 2.1.6. Redundancy Table of Contents 6 66 2.1.7. Redundancy Data 6 67 2.2. Payload Examples 8 68 2.2.1. Standard Payload Carrying a Single Frame 8 69 2.2.2. Standard Payload Carrying Multiple Frames with 70 Redundancy 8 71 2.2.3. Extended Payload Carrying a Single Frame 10 72 3. Media Type Registration 10 73 3.1. Registration of MIME media type audio/ip-mr_v2.5 10 74 3.2. Mapping Media Type Parameters into SDP 11 75 4. Security Consideration 12 76 5. Acknowledgments 12 77 6. Normative References 12 78 Author's Addresses 12 79 Intellectual Property Statement 13 80 Disclaimer of Validity 13 82 A.Setsko Expires September 03, 2008 [Page 2] 83 1. Introduction 84 This document specifies the payload format for packetization of 85 SPIRIT IP-MR encoded speech signals into the Real-time Transport 86 Protocol (RTP). The payload format supports transmission of multiple 87 frames per payload, introduced redundancy for robustness against 88 packet loss, and payload format extension for future versions 89 compatibility. 91 2. IP-MR RTP Payload Formats 92 The payload has two formats: standard optimized for current use-cases 93 and extended for future versions compatibility. The payload format is 94 defined by first bit of header. Both of these formats will be 95 described bellow. 97 2.1. Standard Payload Format 99 2.1.1. Payload Format Structure 101 The standard payload consists of a payload header with general 102 information about packet, a speech table of contents (TOC), and 103 speech data. An optional redundancy section follows after speech 104 data. The redundancy section consists of redundancy header, 105 redundancy TOC and redundancy data payload. 106 The following diagram shows the standard payload format layout: 107 +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + 108 | payload | speech | speech | redundancy | redundancy | redundancy | 109 | header | TOC | data | header | TOC | data | 110 +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + 112 2.1.2. Payload Header 114 The payload header has the following format: 115 0 1 116 0 1 2 3 4 5 6 7 8 9 0 1 117 +-+-+-+-+-+-+-+-+-+-+-+-+ 118 |T| CR | BR |D|A|GR |R| 119 +-+-+-+-+-+-+-+-+-+-+-+-+ 121 o T (1 bit): Reserved compatibility with future extensions. Should be set 122 to 0. 124 A.Setsko Expires September 03, 2008 [Page 3] 125 o CR (3 bits): coding rate of frame(s) in this packet, as per the 126 following table: 127 +-------+--------------+ 128 | CR | avg. bitrate | 129 +-------+--------------+ 130 | 0 | 7.7 kbps | 131 | 1 | 9.8 kbps | 132 | 2 | 14.3 kbps | 133 | 3 | 20.8 kbps | 134 | 4 | 27.9 kbps | 135 | 5 | 34.2 kbps | 136 | 6 | (reserved) | 137 | 7 | NO_DATA | 138 +-------+--------------+ 139 Table 1 Coding rates of IP-MR codec 141 The CR value 7 (NO_DATA) indicates that there is no speech data (and 142 speech TOC accordingly) in the payload. This MAY be used to transmit 143 redundancy data only. The value 6 is reserved. If receiving this 144 value the packet SHOULD be discarded. 146 o BR (3 bits): base rate for core layer of frame(s) in this packet. 147 Values in the range 0-5 indicate bitrates for core layer, same as 148 for CR. Values 6 and 7 are reserved. If one of these values is 149 received the packet SHOULD be discarded. The base rate is the 150 lowest rate for scalability, so speech payload can be scaled down 151 not lower than BR value. If a received packet has BR > CR then 152 during decoding it will be assumed that BR = CR. 154 o D (1 bit): indicates if the DTX mode is allowed or not. 156 o A (1 bit): byte-aligned payload. If A=1 then all speech frames 157 MUST be byte-aligned. This mode speeds up speech data access. The 158 A=0 value specifies bandwidth-efficient mode with no byte 159 alignment (including end of header). 161 o GR (2 bits): number of frames in packet (grouping size). Actual 162 grouping size is GR + 1, thus maximum grouping supported is 4. If 163 greater grouping size is required the extended payload format 164 (sec. 2.2) MAY be used. 166 A.Setsko Expires September 03, 2008 [Page 4] 167 o R (1 bit): redundancy presence bit. If R=1 then the packet 168 contains redundancy information for lost packets recovery. In this 169 case after speech TOC redundancy flags and TOC sections are 170 present. If R=0 then speech TOC is the last section of payload 171 header. 173 2.1.3. Speech Table of Contents 175 The speech TOC contains entries for each frame in packet (grouping 176 size in total). Each entry contains a single field: 178 0 179 +-+ 180 |E| 181 +-+ 183 o E (1 bit): frame existence indicator. If set to 0, this indicates 184 the corresponding frame is absent and the receiver should set the 185 teRxFrType to LOST_FRAME. This can be followed by the lost frame 186 itself or by empty frames generated by the encoder during silence 187 intervals in DTX mode. 189 Note that if CR field from coding flags is 7 (NO_DATA) then speech 190 TOC is empty. 192 2.1.4. Speech Data 194 Speech data of a payload contains one or more speech frames or 195 comfort noise frames, as specified in the speech TOC of the payload. 197 Each speech frame represents 20 ms of speech encoded with the rate 198 indicated in the CR and base rate indicated in BR field of the 199 payload header. The length of the speech frame is variable due to the 200 nature of the codec and can be calculated after decoding or by using 201 GetFrameInfo function detailed in [1]. 203 2.1.5. Redundancy Header 205 If a packet contains redundancy (R field of payload header is 1) the 206 speech data is followed by redundancy header: 208 A.Setsko Expires September 03, 2008 [Page 5] 209 0 1 2 3 4 5 210 +-+-+-+-+-+-+ 211 | CL1 | CL2 | 212 +-+-+-+-+-+-+ 214 Redundancy header consists of two fields. Each field contains class 215 specifier for redundancy partly taken from the preceding packet (CL1) 216 and pre-preceding packet (CL2), e.g. distant from the current packet 217 by 1 and 2 packets accordingly. The values are listed in the table 218 below: 219 +-------+-------------------+ 220 | CL | amount redundancy | 221 +-------+-------------------+ 222 | 0 | NONE | 223 | 1 | CLASS A | 224 | 2 | CLASS B | 225 | 3 | CLASS C | 226 | 4 | CLASS D | 227 | 5 | CLASS E | 228 | 6 | CLASS F | 229 | 7 | (reserved) | 230 +-------+-------------------+ 232 Each specifier takes 3 bits, thus the total redundancy header size is 233 6 bits. In case of redundancy usage followed by preceding (or pre- 234 preceding) packet loss the receiver sets the special flag for decoder 235 with CL class specifier. 237 2.1.6. Redundancy Table of Contents 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Pkt1 Entries| Pkt2 Entries| 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 The redundancy TOC contains entries for redundancy frames from 244 preceding and pre-preceding packets. Each entry takes 1 bit like 245 speech TOC entry (2.1.3): 246 0 247 +-+ 248 |E| 249 +-+ 251 o E (1 bit): frame existence indicator. If set to 0, this indicates 252 the corresponding frame is absent. 254 A.Setsko Expires September 03, 2008 [Page 6] 255 o For each preceding and pre-preceding packet the number of entries 256 is equal to the grouping size of the current packet. E.g. maximum 257 number of entries is 4*2 = 8. 259 o If class specifier in the redundancy header is CL=0 (NO_DATA) then 260 there?s no entries for corresponding packet redundancy. 262 2.1.7. Redundancy Data 264 Redundancy data of a payload contains redundancy information for one 265 or more speech frames or comfort noise frames that may be lost during 266 transition, as specified in the redundancy TOC of the payload. 267 Actually redundancy is the most important part of preceding frames 268 representing 20 ms of speech. The length of redundancy frame is 269 variable and can be calculated after decoding or by using 270 GetFrameInfo function detailed in [1]. 272 A.Setsko Expires September 03, 2008 [Page 7] 273 2.2. Payload Examples 275 2.2.1. Standard Payload Carrying a Single Frame 277 The following diagram shows a standard IP-MR payload carrying a 278 single speech frame without redundancy: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |0|CR=1 |BR=0 |0|0|0 0|0|1|sp(0) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | sp(193)|P| 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 In the payload the speech frame is not damaged at the IP origin 298 (E=1), the coding rate is 9.7 kbps (CR=1), the base rate is 7.8 kbps 299 (BR=0), and the DTX mode is off. There is no byte alignment (A=0) and 300 no redundancy (R=0). The encoded speech bits - s(0) to s(193) - are 301 placed immediately after TOC. Finally, one zero bit is added at the 302 end as padding to make the payload byte aligned. 304 2.2.2. Standard Payload Carrying Multiple Frames with Redundancy 306 The following diagram shows a payload that contains three frames, one 307 of them with no speech data. The coding rate is 7.7 kbps (CR=0), the 308 base rate is 7.7 kbps (BR=0), and the DTX mode is on. The speech 309 frames are byte aligned (A=1), so 1 zero bit is added at the end of 310 the header. Besides the speech frames the payload contains six 311 redundancy frames (three per each delayed packet). 313 The first speech frame consists of bits sp1(0) to sp1(92). After that 314 3 bits are added for byte alignment. The second frame does not 315 contain any speech information that is represented in the payload by 316 its TOC entry. The third frame consists of bits sp3(0) to sp3(171). 318 A.Setsko Expires September 03, 2008 [Page 8] 319 The redundancy header follows after speech data. The one-packet- 320 delayed redundancy contains class A+B bits (CL1=2), and two-packet- 321 delayed redundancy contains class A bits (Cl2=1). The one-packet- 322 delayed redundancy contains three frames with 20, 39 and 35 bits 323 respectively. The first frame of two-packet-delayed redundancy is 324 absent, it is represented in its TOC entry, and two other frames have 325 sizes 15 and 19 bits. 327 Note that all speech frames are padded with zero bits for byte 328 alignment. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |0|CR=2 |BR=1 |1|1|1 0|1|1 0 1|P|sp1(0) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | sp1(92)|P|P|P| 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |sp3(0) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | sp3(171)|P|P|P|P| 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |CL1=2|CL2=1|1 1 1|0 1 1|red1_1(0) red1_1(19)| 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |red1_2(0) 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | red1_2(38)|red1_3(0) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | red1_3(34)|red2_2(0) red2_2(14)|red2_3(0) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | red2_3(18)|P|P|P|P| 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 2.2.3. Extended Payload Carrying a Single Frame 364 The following diagram shows an extended IP-MR payload carrying a 365 single speech frame without redundancy: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |1|CR=1 |BR=0 |0|0|0 0|0|1|P|P|P|0 1 1|0| header extension data | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | |sp(0) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | sp(193)| optional payload extenson ... 385 +-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - 387 The standard header is the same as in example 2.3.1 except for the 388 first bit that is set to 1 to reflect extended payload type. The 389 standard header is padded with zeros to achieve byte alignment. After 390 that the size of header extension follows (HESZ=3). Then the header 391 extension data is placed. In 3 bytes (HESZ) from header extension 392 beginning, the standard speech payload starts. After that, the 393 optional payload extension MAY be added. 395 3. Media Type Registration 397 This section describes the media types and names associated with this 398 payload format. 400 3.1. Registration of MIME media type audio/ip-mr_v2.5 402 Type name: audio 404 Subtype name: ip-mr_v2.5 405 Required parameters: none 407 Optional parameters: 409 o ptime: Gives the length of time in milliseconds represented by the 410 media in a packet. Allowed values are: 20, 40, 60 and 80. 412 Encoding considerations: 413 This media type is framed binary data (see RFC 4288, Section 4.8). 415 Security considerations: See RFC 3550 417 Applications that use this media type: 418 Audio and video streaming and conferencing tools. 420 Additional information: none 422 Person & email address to contact for further information: 423 Andrey Setsko 425 Intended usage: COMMON 427 Restrictions on usage: 428 This media type depends on RTP framing, and hence is only 429 defined for transfer via RTP (RFC 3550). 431 Author: 432 Andrey Setsko 434 3.2. Mapping Media Type Parameters into SDP 436 The information carried in the media type specification has a 437 specific mapping to fields in the Session Description Protocol (SDP) 438 [RFC4566], which is commonly used to describe RTP sessions. When SDP 439 is used to specify sessions employing the IP-MR codec, the mapping is 440 as follows: 442 o The media type ("audio") goes in SDP "m=" as the media name. 444 o The media subtype (payload format name) goes in SDP "a=rtpmap" as 445 the encoding name. The RTP clock rate in "a=rtpmap" MUST 16000. 447 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 448 "a=maxptime" attributes, respectively. 450 Any remaining parameters go in the SDP "a=fmtp" attribute by copying 451 them directly from the media type parameter string as a semicolon- 452 separated list of parameter=value pairs. 454 4. Security Considerations 456 RTP packets using the payload format defined in this specification 457 are subject to the security considerations discussed in the RTP 458 specification [RFC3550], and any appropriate RTP profile. This 459 implies that confidentiality of the media streams is achieved by 460 encryption. Encryption may be performed after compression so there 461 is no conflict between the two operations. 463 This payload format does not exhibit any significant non-uniformity 464 in the receiver side computational complexity for packet processing, 465 and thus is unlikely to pose a denial-of-service threat due to the 466 receipt of pathological data. 468 5. Acknowledgments 470 This document was prepared using 2-Word-v2.0.template.dot. 472 6. Normative References 474 [1] SPIRIT IP-MR v2.5 User Guide, website http://spiritdsp.com 475 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 476 Levels", BCP 14, RFC 2119, March 1997. 477 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 478 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 479 RFC 3550, July 2003. 480 [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 481 Description Protocol", RFC 4566, July 2006. 483 Author's Addresses 485 Andrey Setsko 486 SPIRIT DSP 487 Russia 109004 B.Kommunisticheskaya st. 27 489 Email: Setsko@spiritdsp.com 491 Intellectual Property Statement 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Disclaimer of Validity 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 520 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 521 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 522 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Copyright Statement 527 Copyright (C) The IETF Trust (2007). 529 This document is subject to the rights, licenses and restrictions 530 contained in BCP 78, and except as set forth therein, the authors 531 retain all their rights. 533 Acknowledgment 535 Funding for the RFC Editor function is currently provided by the 536 Internet Society.