idnits 2.17.1 draft-ietf-avt-rtp-ilbc-03.txt: -(437): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(438): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 488, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 504, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Alan Duric 3 Soren Vang Andersen 4 Internet Draft 5 draft-ietf-avt-rtp-ilbc-03.txt Global IP Sound 6 October 25th, 2003 7 Expires: April 25th, 2004 9 RTP Payload Format for iLBC Speech 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes the RTP payload format for the internet Low 38 Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound 39 (GIPS). Also, within the document there are included necessary 40 details for the use of iLBC with MIME and SDP. 42 Table of Contents 44 Status of this Memo................................................1 45 Abstract...........................................................1 46 Table of Contents..................................................1 47 1. INTRODUCTION....................................................2 48 2. BACKGROUND......................................................2 49 3. RTP PAYLOAD FORMAT..............................................3 50 3.1 Bitstream definition...........................................3 51 3.2 Multiple iLBC frames in a RTP packet...........................6 52 4. IANA CONSIDERATIONS.............................................6 53 4.1 Storage Mode...................................................6 54 4.2 MIME registration of iLBC......................................7 55 5. MAPPING TO SDP PARAMETERS.......................................9 56 6. SECURITY CONSIDERATIONS........................................10 57 7. REFERENCES.....................................................11 58 7.1 Normative references..........................................11 59 7.2 Informative references........................................11 60 8. ACKNOWLEDGEMENTS...............................................12 61 9. AUTHOR'S ADDRESSES.............................................12 63 1. INTRODUCTION 65 This document describes how compressed iLBC speech as produced by 66 the iLBC codec [1] may be formatted for use as an RTP payload type. 67 Methods are provided to packetize the codec data frames into RTP 68 packets. The sender may send one or more codec data frames per 69 packet, depending on the application scenario or based on the 70 transport network condition, bandwidth restriction, delay 71 requirements and packet-loss tolerance. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 75 this document are to be interpreted as described in RFC 2119 [2]. 77 2. BACKGROUND 79 Global IP Sound (GIPS) has developed and defines a freeware speech 80 compression algorithm for use in IP based communications [1]. The 81 iLBC codec enables graceful speech quality degradation in the case 82 of lost frames, which occurs in connection with lost or delayed IP 83 packets. 85 Some of the applications for which this coder is suitable are: real 86 time communications such as telephony and videoconferencing, 87 streaming audio, archival and messaging. 89 The iLBC codec [1] is an algorithm that compresses each basic frame 90 (20 ms or 30 ms) of 8000 Hz, 16-bit sampled input speech, into 91 output frames with rate of 400 bits for 30 ms basic frame size and 92 304 bits for 20 ms basic frame size. 94 The codec has support for two basic frame lengths: 30 ms at 13.33 95 kbit/s and 20 ms at 15.2 kbit/s, using a block independent linear- 96 predictive coding (LPC) algorithm. When the codec operates at block 97 lengths of 20 ms, it produces 304 bits per block which SHOULD be 98 packetized in 38 bytes. Similarly, for block lengths of 30 ms it 99 produces 400 bits per block which SHOULD be packetized in 50 bytes. 100 The described algorithm results in a speech coding system with a 101 controlled response to packet losses similar to what is known from 102 pulse code modulation (PCM) with a packet loss concealment (PLC), 103 such as ITU-T G711 standard [11], which operates at a fixed bit rate 104 of 64 kbit/s. At the same time, the described algorithm enables 105 fixed bit rate coding with a quality-versus-bit rate tradeoff close 106 to what is known from code-excited linear prediction (CELP). 108 Cable Television Laboratories (CableLabs(R)) intends to adapt iLBC 109 as a PacketCable(TM) audio codec standard for VoIP over Cable 110 applications [10]. 112 3. RTP PAYLOAD FORMAT 114 The iLBC codec uses 20 or 30 ms frames and a sampling rate clock of 115 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. 116 The RTP payload for iLBC has the format shown in the figure bellow. 117 No addition header specific to this payload format is required. 119 This format is intended for the situations where the sender and the 120 receiver send one or more codec data frames per packet. The RTP 121 packet looks as follows: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | RTP Header [4] | 127 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 128 | | 129 + one or more frames of iLBC [1] | 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 The RTP header of the packetized encoded iLBC speech has the 134 expected values as described in [4]. The usage of M bit SHOULD be as 135 specified in the applicable RTP profile, for example, RFC 3551 [5], 136 where [5] specifies that if the sender does not suppress silence 137 (i.e., sends a frame on every frame interval), the M bit will always 138 be zero. When more then one codec data frame is present in a single 139 RTP packet, the timestamp is, as always, that of the oldest data 140 frame represented in the RTP packet. 142 The assignment of an RTP payload type for this new packet format is 143 outside the scope of this document, and will not be specified here. 144 It is expected that the RTP profile for a particular class of 145 applications will assign a payload type for this encoding, or if 146 that is not done, then a payload type in the dynamic range shall be 147 chosen by the sender. 149 3.1 Bitstream definition 151 The total number of bits used to describe one frame of 20 ms speech 152 is 304, which fits in 38 bytes and results in a bit rate of 15.20 153 kbit/s. For the case with a frame length of 30 ms speech the total 154 number of bits used is 400, which fits in 50 bytes and results in a 155 bit rate of 13.33 kbit/s. In the bitstream definition, the bits are 156 distributed into three classes according to their bit error or loss 157 sensitivity. The most sensitive bits (class 1) are placed first in 158 the bitstream for each frame. The less sensitive bits (class 2) are 159 placed after the class 1 bits. The least sensitive bits (class 3) 160 are placed at the end of the bitstream for each frame. 162 Looking at the 20/30 ms frame length cases for each class: The class 163 1 bits occupy a total of 6/8 bytes (48/64 bits), the class 2 bits 164 occupy 8/12 bytes (64/96 bits), and the class 3 bits occupy 24/30 165 bytes (191/239 bits). This distribution of the bits enables the use 166 of uneven level protection (ULP). The detailed bit allocation is 167 shown in the table below. When a quantization index is distributed 168 between more classes the more significant bits belong to the lowest 169 class. 171 Bitstream structure: 173 ------------------------------------------------------------------+ 174 Parameter | Bits Class <1,2,3> | 175 | 20 ms frame | 30 ms frame | 176 ----------------------------------+---------------+---------------+ 177 Split 1 | 6 <6,0,0> | 6 <6,0,0> | 178 LSF 1 Split 2 | 7 <7,0,0> | 7 <7,0,0> | 179 LSF Split 3 | 7 <7,0,0> | 7 <7,0,0> | 180 ------------------+---------------+---------------+ 181 Split 1 | NA (Not Appl.)| 6 <6,0,0> | 182 LSF 2 Split 2 | NA | 7 <7,0,0> | 183 Split 3 | NA | 7 <7,0,0> | 184 ------------------+---------------+---------------+ 185 Sum | 20 <20,0,0> | 40 <40,0,0> | 186 ----------------------------------+---------------+---------------+ 187 Block Class. | 2 <2,0,0> | 3 <3,0,0> | 188 ----------------------------------+---------------+---------------+ 189 Position 22 sample segment | 1 <1,0,0> | 1 <1,0,0> | 190 ----------------------------------+---------------+---------------+ 191 Scale Factor State Coder | 6 <6,0,0> | 6 <6,0,0> | 192 ----------------------------------+---------------+---------------+ 193 Sample 0 | 3 <0,1,2> | 3 <0,1,2> | 194 Quantized Sample 1 | 3 <0,1,2> | 3 <0,1,2> | 195 Residual : | : : | : : | 196 State : | : : | : : | 197 Samples : | : : | : : | 198 Sample 56 | 3 <0,1,2> | 3 <0,1,2> | 199 Sample 57 | NA | 3 <0,1,2> | 200 ------------------+---------------+---------------+ 201 Sum | 171 <0,57,114>| 174 <0,58,116>| 202 ----------------------------------+---------------+---------------+ 203 Stage 1 | 7 <6,0,1> | 7 <4,2,1> | 204 CB for 22/23 Stage 2 | 7 <0,0,7> | 7 <0,0,7> | 205 sample block Stage 3 | 7 <0,0,7> | 7 <0,0,7> | 206 ------------------+---------------+---------------+ 207 Sum | 21 <6,0,15> | 21 <4,2,15> | 208 ----------------------------------+---------------+---------------+ 209 Stage 1 | 5 <2,0,3> | 5 <1,1,3> | 210 Gain for 22/23 Stage 2 | 4 <1,1,2> | 4 <1,1,2> | 211 sample block Stage 3 | 3 <0,0,3> | 3 <0,0,3> | 212 ------------------+---------------+---------------+ 213 Sum | 12 <3,1,8> | 12 <2,2,8> | 214 ----------------------------------+---------------+---------------+ 215 Stage 1 | 8 <7,0,1> | 8 <6,1,1> | 216 sub-block 1 Stage 2 | 7 <0,0,7> | 7 <0,0,7> | 217 Stage 3 | 7 <0,0,7> | 7 <0,0,7> | 218 ------------------+---------------+---------------+ 219 Stage 1 | 8 <0,0,8> | 8 <0,7,1> | 220 sub-block 2 Stage 2 | 8 <0,0,8> | 8 <0,0,8> | 221 Indices Stage 3 | 8 <0,0,8> | 8 <0,0,8> | 222 for CB ------------------+---------------+---------------+ 223 sub-blocks Stage 1 | NA | 8 <0,7,1> | 224 sub-block 3 Stage 2 | NA | 8 <0,0,8> | 225 Stage 3 | NA | 8 <0,0,8> | 226 ------------------+---------------+---------------+ 227 Stage 1 | NA | 8 <0,7,1> | 228 sub-block 4 Stage 2 | NA | 8 <0,0,8> | 229 Stage 3 | NA | 8 <0,0,8> | 230 ------------------+---------------+---------------+ 231 Sum | 46 <7,0,39> | 94 <6,22,66> | 232 ----------------------------------+---------------+---------------+ 233 Stage 1 | 5 <1,2,2> | 5 <1,2,2> | 234 sub-block 1 Stage 2 | 4 <1,1,2> | 4 <1,2,1> | 235 Stage 3 | 3 <0,0,3> | 3 <0,0,3> | 236 ------------------+---------------+---------------+ 237 Stage 1 | 5 <1,1,3> | 5 <0,2,3> | 238 sub-block 2 Stage 2 | 4 <0,2,2> | 4 <0,2,2> | 239 Stage 3 | 3 <0,0,3> | 3 <0,0,3> | 240 Gains for ------------------+---------------+---------------+ 241 sub-blocks Stage 1 | NA | 5 <0,1,4> | 242 sub-block 3 Stage 2 | NA | 4 <0,1,3> | 243 Stage 3 | NA | 3 <0,0,3> | 244 ------------------+---------------+---------------+ 245 Stage 1 | NA | 5 <0,1,4> | 246 sub-block 4 Stage 2 | NA | 4 <0,1,3> | 247 Stage 3 | NA | 3 <0,0,3> | 248 ------------------+---------------+---------------+ 249 Sum | 24 <3,6,15> | 48 <2,12,34> | 250 ------------------------------------------------------------------- 251 Empty frame indicator | 1 <0,0,1> | 1 <0,0,1> | 252 ------------------------------------------------------------------- 253 SUM 304 <48,64,192> 400 <64,96,240> 254 Table 3.1 The bitstream definition for iLBC. 256 When packetized into the payload the bits MUST be sorted as: All the 257 class 1 bits in the order (from top and down) as they were specified 258 in the table, all the class 2 bits (from top and down) and finally 259 all the class 3 bits in the same sequential order. 261 3.2 Multiple iLBC frames in a RTP packet 263 More than one iLBC frame may be included in a single RTP packet by a 264 sender. 266 It is important to observe that senders have the following 267 additional restrictions: 269 SHOULD NOT include more iLBC frames in a single RTP packet than will 270 fit in the MTU of the RTP transport protocol. 272 Frames MUST NOT be split between RTP packets. 274 Frames of the different modes (20 ms and 30 ms) MUST NOT be included 275 within the same packet. 277 It is RECOMMENDED that the number of frames contained within an RTP 278 packet is consistent with the application. For example, in a 279 telephony and other real time applications where delay is important, 280 then the fewer frames per packet the lower the delay, whereas for a 281 bandwidth constrained links or delay insensitive streaming messaging 282 application, more then one or many frames per packet would be 283 acceptable. 285 Information describing the number of frames contained in an RTP 286 packet is not transmitted as part of the RTP payload. The way to 287 determine the number of iLBC frames is to count the total number of 288 octets within the RTP packet, and divide the octet count by the 289 number of expected octets per frame (32/50 per frame). 291 4. IANA CONSIDERATIONS 293 One new MIME sub-type as described in this section is to be 294 registered. 296 4.1 Storage Mode 298 The storage mode is used for storing speech frames (e.g. as a file 299 or e-mail attachment). 301 +------------------+ 302 | Header | 303 +------------------+ 304 | Speech frame 1 | 305 +------------------+ 306 : : 307 +------------------+ 308 | Speech frame n | 309 +------------------+ 311 The file begins with a header that includes only a magic number to 312 identify that it is an iLBC file. 314 The magic number for iLBC file MUST correspond to the ASCII 315 character string: 317 o for 30 ms frame size mode:"#!iLBC30\n", or "0x23 0x21 0x69 318 0x4C 0x42 0x43 0x33 0x30 0x0A" in hexadecimal form, 320 o for 20 ms frame size mode:"#!iLBC20\n", or "0x23 0x21 0x69 321 0x4C 0x42 0x43 0x32 0x30 0x0A" in hexadecimal form. 323 After the header, follow the speech frames in consecutive order. 325 Speech frames lost in transmission SHOULD be stored as �empty 326 frames�, as defined in [1]. 328 4.2 MIME registration of iLBC 330 MIME media type name: audio 332 MIME subtype: iLBC 334 Optional parameters: 336 This parameter applies to RTP transfer only. 338 maxptime:The maximum amount of media which can be 339 encapsulated in each packet, expressed 340 as time in milliseconds. The time SHALL be 341 calculated as the sum of the time the media 342 present in the packet represents. The time SHOULD be 343 a multiple of the frame size. This attribute is 344 probably only meaningful for audio data, but may be 345 used with other media types if it makes sense. It is 346 a media attribute, and is not dependent on charset. 347 Note that this attribute was introduced after RFC 348 2327, and non updated implementations will ignore 349 this attribute. 351 mode: The iLBC operating frame mode (20 or 30 ms) that will 352 be encapsulated in each packet. Values can be 0 and 353 20 (where 0 is reserved and 20 stands for preferred 354 20 ms frame size 356 ptime: Defined as usual for RTP audio (see [7]). 358 Encoding considerations: 359 This type is defined for transfer via both RTP (RFC 360 3550) and stored-file methods as described in Section 361 4.1, of RFC XXXX. Audio data is binary data, and must 362 be encoded for non-binary transport; the Base64 363 encoding is suitable for Email. 365 Security considerations: 366 See Section 6 of RFC XXXX. 368 Public specification: 369 Please refer to RFC XXXX [1]. 371 Additional information: 372 The following applies to stored-file transfer 373 methods: 375 Magic number: 376 ASCII character string for: 377 o 30 ms frame size mode "#!iLBC30\n" (or 0x23 0x21 378 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A in hexadecimal) 379 o 20 ms frame size mode "#!iLBC20\n" (or 0x23 0x21 380 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A in hexadecimal) 382 File extensions: lbc, LBC 383 Macintosh file type code: none 384 Object identifier or OID: none 386 Person & email address to contact for further information: 387 alan.duric@globalipsound.com 389 Intended usage: COMMON. 390 It is expected that many VoIP applications will use 391 this type. 393 Author/Change controller: 394 alan.duric@globalipsound.com 395 IETF Audio/Video transport working group 396 5. MAPPING TO SDP PARAMETERS 398 The information carried in the MIME media type specification has a 399 specific mapping to fields in the Session Description Protocol (SDP) 400 [7], which is commonly used to describe RTP sessions. When SDP is 401 used to specify sessions employing the iLBC codec, the mapping is as 402 follows: 404 o The MIME type ("audio") goes in SDP "m=" as the media name. 406 o The MIME subtype (payload format name) goes in SDP 407 "a=rtpmap" as the encoding name. 409 o The parameters "ptime" and "maxptime" go in the SDP 410 "a=ptime" and "a=maxptime" attributes, respectively. 412 o The parameter "mode" goes in the SDP "a=fmtp" attribute by 413 copying it directly from the MIME media type string as 414 "mode=value". 416 When conveying information by SDP, the encoding name SHALL be "iLBC" 417 (the same as the MIME subtype). 419 An example of the media representation in SDP for describing iLBC 420 might be: 422 m=audio 49120 RTP/AVP 97 423 a=rtpmap:97 iLBC/8000 425 If 20 ms frame size mode is used, remote iLBC encoder SHALL receive 426 "mode" parameter in the SDP "a=fmtp" attribute by copying them 427 directly from the MIME media type string as a semicolon separated 428 with parameter=value, where parameter is "mode", and values can be 0 429 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame 430 size). An example of the media representation in SDP for describing 431 iLBC when 20 ms frame size mode is used might be: 433 m=audio 49120 RTP/AVP 97 434 a=rtpmap:97 iLBC/8000 435 a=fmtp:97 mode=20 437 It is important to emphasize bi-directional character of the �mode� 438 parameter, where �mode� would imply that 20 ms frame size mode MUST 439 be used in both of the directions if negotiated. This is important 440 for the cases when certain end point will be behind bandwidth 441 constrained link (e.g. modem 28.8 or bellow), where only 30 ms mode 442 would be possible to function. 444 Parameter ptime can not be used for the purpose of specifying iLBC 445 operating mode, due to fact that for the certain values it will be 446 impossible to distinguish which mode is about to be used (e.g. when 447 ptime=60, it would be impossible to distinguish if packet is 448 carrying 2 frames of 30 ms or 3 frames of 20 ms etc.). 450 Note that the payload format (encoding) names are commonly shown in 451 upper case. MIME subtypes are commonly shown in lower case. These 452 names are case-insensitive in both places. Similarly, parameter 453 names are case-insensitive both in MIME types and in the default 454 mapping to the SDP a=fmtp attribute 456 6. SECURITY CONSIDERATIONS 458 RTP packets using the payload format defined in this specification 459 are subject to the general security considerations discussed in [4] 460 and any appropriate profile (e.g. [5]). 462 As this format transports encoded speech, the main security issues 463 include confidentiality and authentication of the speech itself. The 464 payload format itself does not have any built-in security 465 mechanisms. Confidentiality of the media streams is achieved by 466 encryption, therefore external mechanisms, such as SRTP [9], MAY be 467 used for that purpose. The data compression used with this payload 468 format is applied end-to-end; hence encryption may be performed 469 after compression with no conflict between the two operations. 471 A potential denial-of-service threat exists for data encoding using 472 compression techniques that have non-uniform receiver-end 473 computational load. The attacker can inject pathological datagrams 474 into the stream which are complex to decode and cause the receiver 475 to become overloaded. However, the encodings covered in this 476 document do not exhibit any significant non-uniformity. 478 7. REFERENCES 480 7.1 Normative references 482 [1] Andersen, et al., �Internet Low Bit Rate Codec (iLBC)", IETF 483 Draft, October 2003. 485 [2] S. Bradner, "Key words for use in RFCs to Indicate requirement 486 Levels", BCP 14, RFC 2119, March 1997. 488 [3] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 489 9, RFC 2026, October 1996 491 [4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 492 A Transport Protocol for Real-Time Applications", IETF RFC 3550, 493 July 2003. 495 [5] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video 496 Conferences with Minimal Control" IETF RFC 3551, July 2003. 498 [6] Handley & Perkins, "Guidelines for Writers of RTP Payload 499 Formats", BCP 36, RFC 2736, December 1999. 501 [7] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 502 IETF RFC 2327, April 1998 504 [8] N. Freed and N. Borenstein, "Multipurpose Internet Mail 505 Extensions (MIME) Part One: Format of Internet Message Bodies", 506 IETF RFC 2045, November 1996. 508 [9] Baugher, et al., "The Secure Real Time Transport Protocol", IETF 509 Draft, July 2003. 511 [10] PacketCable(TM) Audio/Video Codecs Specification, Cable 512 Television Laboratories, Inc. 514 7.2 Informative references 516 [11] ITU-T Recommendation G.711, available online from the ITU 517 bookstore at http://www.itu.int. 519 8. ACKNOWLEDGEMENTS 521 The authors wish to thank Henry Sinnreich, Patrik Faltstrom and Alan 522 Johnston for great support of the iLBC initiative and for their 523 valuable feedback and comments. 525 9. AUTHOR'S ADDRESSES 527 Alan Duric 528 Global IP Sound AB 529 Rosenlundsgatan 54 530 Stockholm, S-11863 531 Sweden 532 Phone: +46 8 54553040 533 Email: alan.duric@globalipsound.com 535 Soren Vang Andersen 536 Department of Communication Technology 537 Aalborg University 538 Fredrik Bajers Vej 7A 539 9200 Aalborg 540 Denmark 541 Phone: ++45 9 6358627 542 Email: sva@kom.auc.dk