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