idnits 2.17.1 draft-ietf-avt-rtp-mpeg2aac-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 33 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 20, 2001) is 8316 days in the past. Is this intentional? 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: '4' is defined on line 439, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1889 (ref. '4') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2327 (ref. '8') (Obsoleted by RFC 4566) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Kretschmer-AT&T/Basso-AT&T 2 INTERNET DRAFT Civanlar-AT&T/Quackenbush-AT&T 3 File:draft-ietf-avt-rtp-mpeg2aac-02.txt Snyder-AT&T 4 July 20, 2001 5 Expires: January 20, 2002 7 RTP Payload Format for MPEG-2 and MPEG-4 AAC Streams 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 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 Abstract 31 This document describes a payload format for transporting 32 MPEG-2/MPEG-4 AAC encoded data using RTP. MPEG-2/MPEG-4 AAC is a 33 recent standard from ISO/IEC [1] [2] [3] for coding multi-channel 34 audio data. This payload format increases the packet loss resilience 35 of AAC coded audio transport above that of 'RTP Payload Format for 36 MPEG1/MPEG2 Video (RFC 2250)' [7] by incorporating AAC properties into 37 the payload format. Supported features comprise fragmentation, 38 interleaving, grouping, repair information and a predictability 39 vector. The MPEG-2/MPEG-4 AAC bitstream format is not backwards 40 compatible with other MPEG-2 audio formats (e.g. MP3). Several 41 services provided by RTP are beneficial for MPEG-2/MPEG-4 AAC encoded 42 data transport over the Internet. Additionally, the use of RTP allows 43 for the synchronization of MPEG-2/MPEG-4 AAC with other real-time 44 streams. 46 In this version of the draft: 48 - The fragmentation section has been revised to allow for the 49 fragmentation of elements (CPE, etc.) to better support 50 transmission over small MTU links 51 1. Introduction 53 The ISO/IEC MPEG-2/MPEG-4 Advanced Audio Coding (AAC) [1] [2] [3] 54 technology delivers CD-like or better multichannel audio quality at 55 rates around 64 kBit/s per channel. It has a flexible bitstream syntax 56 that supports from 1 to 48 audio channels, up to 16 subwoofer channels 57 and up to 16 embedded data channels. AAC supports a wide range of 58 sampling frequencies (from 16 kHz to 96 kHz) and an extremely wide 59 range of bitrates. AAC can support applications ranging from 60 professional or home theater sound systems to Internet music broadcast 61 systems. 63 The syntax of MPEG-2 AAC compressed data streams is identical to that 64 of MPEG-4 AAC main, AAC LC and AAC SSR General Audio compressed data 65 streams, so that MPEG-2 AAC is fully forward compatible with MPEG-4 66 AAC. Both MPEG-2 AAC and MPEG-4 AAC provide the same level of 67 compression performance. However, the semantics of MPEG-4 AAC is 68 different in one small respect, precluding a full backward 69 compatibility of MPEG-4 AAC to MPEG-2 AAC. 71 Benefits of using RTP for MPEG-2/MPEG-4 AAC stream transport include: 73 i. Providing increased packet loss resilience based on application 74 layer framing. 76 ii. The ability to synchronize AAC streams with other RTP payloads 78 iii. Monitoring MPEG-2/MPEG-4 AAC delivery performance through RTCP 80 iv. Combining MPEG-2/MPEG-4 AAC and other real-time data streams 81 received from multiple end-systems into a set of consolidated 82 streams through RTP mixers 84 v. Converting data types, etc. through the use of RTP translators. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [5]. 90 1.1 Overview of MPEG-2/MPEG-4 AAC 92 AAC combines the coding efficiencies of a high resolution filter bank, 93 a powerful model of audio perception, backward-adaptive prediction, 94 joint channel coding, and Huffman coding to achieve high-quality 95 signal compression. In 1998 the MPEG Audio subgroup tested the family 96 of MPEG audio coders (see http://www.tnt.uni-hannover.de/project/mpeg/ 97 audio/public/w2006.pdf). The test results indicate that for a stereo 98 signal, AAC at 96 kBit/s has audio quality comparable to MPEG-2 Layer 3 99 ("mp3") at 128 kBit/s. 101 AAC is a block oriented, variable rate coding algorithm. An AAC 102 encoder takes 1024 samples per channel at a time (a 'block') as input 103 and the compressed representation is variable in size. 105 Rate control can be used at the encoder to generate a constant-rate 106 bitstream. Each block of AAC compressed bits is called a "raw data 107 block", and can be decoded "stand-alone", that is, without information 108 from prior raw data blocks. This feature is particularly useful for 109 the delivery of AAC over lossy packet networks since the loss of a 110 packet does not directly affect the decodability of the adjacent 111 packets. 113 1.2 Bitstream Syntax 115 The syntax of an AAC bitstream is as follows: 117 => 118 => [] 120 where indicates the AAC bitstream, indicates 121 intermediate tokens, indicates terminal tokens and [] 122 indicates one or more occurrence. is a token that indicates the 123 end of a raw_data_block and is a variable length token that 124 forces the total length of a raw_data_block to be an integral number 125 of bytes. In general, intermediate tokens are not an integral number of 126 bytes in length. 128 The tokens are a string of bits of variable length, and they 129 can be any of the following: 131 a single audio channel 132 a stereo presentation (2 channels) 133 a mechanism for multi-channel compression 134 a special effects channel 135 "user data" 136 a mechanism for describing the bitstream 137 content 138 a mechanism to use bits (for constant rate 139 channels) 141 The can occur several times in a single 142 raw_data_block. For example, the raw_data_block for a 5.1 surround 143 sound signal would be: 145 ... 146 148 corresponding to the center, left and right, left surround and right 149 surround and effects channels. Occurances of the 150 are dis-ambiguated by means of a unique 4-bit id inside the 151 . 153 2. Issues covered by this Payload Format 155 2.1 Repair Information to reconstruct lost AAC Frames (Unequal FEC) 157 A smart AAC decoder can mitigate the effects of lost packets using 158 techniques such as interpolation in the spectral domain. However if 159 the raw_data_block in a packet is perceptually significant and also 160 highly unpredictable (e.g. the onset of a cymbal crash) then the 161 sender may choose to add repair information associated with that 162 raw_data_block. This form of unequal FEC allows the encoder/sender to 163 protect a stream depending on known loss characteristics and/or frame 164 predictability. A given repair information block (AAC DATA chunk with 165 TYPE > 0) is typically associated with a raw_data_block (TYPE = 0). 166 The association between the raw_data_block and the repair information 167 is obtained by means of the SEQ field. 169 Repair Information as defined here is a valid AAC raw_data_block. As 170 an example, the Repair Information can be a highly compressed 171 monophonic version of a subset of the signal being transmitted. An AAC 172 stereo signal coded at a sampling rate of 44100 samples/s and a bit 173 rate of 96 kBit/s corresponds to an average raw_data_block size of 279 174 bytes. A RepairData version of that block, compressed to 16 kBit/s 175 would be 46 bytes in length. Given that perceptually critical blocks 176 might occur only once per 100 or more blocks, the average rate 177 increase associated with this type of RepairData can be very 178 low. Generally, the Repair Information for a given AAC frame X SHALL 179 be carried by a different RTP packet then the one that carries 180 X. Generally, the Repair Information MUST be computed at the same 181 sampling rate as the stream being repaired. 183 The usage of the Repair Information is similar to the one proposed 184 in [6]. The OPTIONAL Repair Information MAY be provided for every 185 frame. RepairData can be generated in many ways including using two 186 encoders, decoding followed by coding or processing the original 187 bitstream. 189 2.2 Fragmentation of AAC Frames 191 It is desirable to limit the size of an AAC frame to less than the 192 path-MTU. If this is not possible, the frame can be fragmented across 193 several RTP packets. Fragmentation SHOULD occur at boundaries. 194 If further fragmentation is needed MAY be fragmented, as well. 195 In that case the decoder must be able to handle partial . 197 An RTP packet contains either an integer number of complete AAC frames 198 or fragments of a single AAC frame. Subsequent RTP packets containing 199 subsequent fragments of an AAC frame have a much simpler header that 200 is just two bytes long. They can be identified by the F-bit set to 201 1. The S-bit signals the first or only fragment of an . The 202 same ELEMENT ID is shared by all fragments belonging to the same 203 . ELEMENT ID zero is assigned to the fragments of the first 204 in the frame and is increased by one for each following 205 . FBITS indicates the number of unused bits in the first byte 206 and LBITS the number of unused bits in the last byte. FBITS and/or 207 LBITS must be set to zero if the fragment starts and/or ends at a 208 byte-aligned boundary. The length of a fragment can be determined from 209 the total length of the packet excluding the headers. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |X|X|X|F|S|ELEMNT ID|FBITS|LBITS|AAC FRAGMENT | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 2.3 Predictability of AAC Frames 221 AAC frame predictability allows adaptive handling of packet losses 222 and/or bandwidth constraints by signalling the need for an action a 223 receiver may take when an associated AAC frame is lost. Every AAC frame 224 will be assigned to one of the following three predictability classes: 225 - 0: not predictable 226 - 1: one side predictable (either L-predictable or R-predictable) 227 - 2: two side predictable 228 (- 3: reserved) 230 An AAC frame that belongs to class 0 cannot be easily concealed using 231 any other AAC frame(s) in the bitstream. 233 An AAC frame that belongs to class 1 can be predicted either from 234 previous (R-predictable) or following (L-predictable) AAC frame but 235 not from both. 237 An AAC frame that belongs to class 2 can be predicted from the 238 preceding or following AAC frame or from both. 240 Predictability information is coded for every RTP AAC packet in the 241 Predictability Quantifier (PQ) which is 2 bits in length. For a given 242 RTP packet such PQs are organized in a predictability vector which 243 represents a sliding window of PQs, starting with the current packet's 244 PQ followed by preceding packets' PQs. 246 2.4 Grouping and Interleaving of AAC Frames 248 It is often desirable to group an integer number of AAC frames. The 249 predictability of such an RTP packet is the predictability of the AAC 250 frame in the RTP packet which is least predictable. AAC frames 251 belonging to the same predictability class MAY be grouped into one RTP 252 packet. Note that if frames of different predictabilities are grouped 253 much of the usefulness of the predictability information is lost. The 254 sequence numbers SEQ of the AAC DATA chunks are used to restore the 255 proper order on the receiver side. 257 Grouping AAC frames into a single RTP packet is OPTIONAL. 259 2.5 Example RTP Packet Sequence 261 The example below shows a sequence of AAC frames (a...p) and their 262 assigned predictability classes. 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | 2 | 2 | 2 | 1 | 0 | 1 | 2 | 2 | 2 | 2 | 2 | 1 | 0 | 1 | 2 | 2 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 The AAC frames MAY be grouped according to their predictability. 271 R(x) is the RepairData information sent within the RTP packet: 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |a g j|b h k|c i o| d f | e | l n | m | p | | 275 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 276 | | |R(e) | | |R(m) | | | | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 3. RTP AAC Payload Format 281 The AAC specific RTP payload consists of a 8, 32, 64 or 96 bit header, 282 and a variable number of AAC DATA chunks. The type of those chunks is 283 identified by TYPE field. The LENGTH field specifies the length of a 284 chunk in bytes and SEQ is a sequence number which allows grouping, 285 interleaving and association of Repair Info with the frame it repairs. 287 The header contains a vector of Predictability Quantizers (PQ) which 288 specify the packets' predictability classes, and a set of control 289 bits. 291 The PVS field specifies if the header contains 12, 28 or 44 PQs. At 292 the beginning of a session, if fewer packets have been transmitted/ 293 received than there are PQs in the header then the extra PQs are 294 invalid and MUST be set to 0 (on the sender side) and MUST be ignored 295 (on the receiver side). 297 If a sender provides a predictability vector but does not provide 298 frame predictability information it MUST set all PQs to 0. A client 299 can ignore the information provided by PQs since PQs are not required 300 for decoding AAC frames. PQs can be used to decide when to ask for 301 retransmission of lost packets. PQs can also provide hints which help 302 a PQ-aware decoder to improve the audio quality when concealing lost 303 packets. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |PVS|M|F| MBZ |PRD VECTOR (PVS > 0) | Header 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |PRD VECTOR (PVS > 1) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |PRD VECTOR (PVS > 2) | 313 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 314 |TYPE |SEQ |LENGTH (if M==1) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 316 |AAC DATA 1 | AAC 317 | | Data 318 | | 319 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | |TYPE |SEQ |LENGTH | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 322 | |AAC DATA 2 | 323 |-+-+-+-+-+-+-+-+ | 324 | . | 325 | . | 326 | . | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 328 |TYPE |SEQ |LENGTH | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 330 |AAC DATA N | 331 | | 332 | | 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 PRD VECTOR: Predictability vector. It contains either 12, 28 or 44 337 Predictability Quantifiers (PQ). The size of a PQ element 338 is 2 bits. The first PQ refers to the predictability class of 339 the current packet. The following PQs refer to the most 340 recent previous packets. Thus, the vector looks like this: 341 {PQ(t), PQ(t-1), PQ(t-2)...} 342 The predictability class of a packet is that of the least 343 predictable AAC frame that is contained in the packet. 345 PVS: Predictability Vector Size. Specifies the number of 32bit 346 words used for the Predictability Vector. The first 32bit 347 word contains the flags field. Hence, only the lower 348 significant 24bits belong to the vector. If PVS is set to 349 0 the predictability vector field does not exist, and 350 the TYPE field is contiguous with the MBZ field. 352 M: If M is set, then the payload contains more than one AAC 353 frame. Hence, a LENGTH field for the first frame MUST be 354 present. If M is clear, then only one AAC frame is present, 355 and no LENGTH field is present. 357 F: Fragmented Frame. 359 MBZ: Must be set to 0. 361 TYPE: The type of AAC DATA. This field specifies if the AAC DATA 362 is an original AAC frame or contains some form of Error 363 Correction data. The following types are defined for now: 364 0: Original AAC frame 365 1: Identical to original frame but sent for redundancy 366 2: Same AAC configuration but encoded using less bits 367 (Repair Information) 368 (all three types are valid AAC frames) 370 SEQ: The sequence number enumerates AAC frames at the stream level. 371 It may be used to support interleaving or association of Repair 372 Information with TYPE==0 AAC frames, etc. 374 LENGTH: The length of the AAC Data in bytes. 376 AAC DATA: The actual AAC data chunk. This is either a valid AAC frame 377 (TYPE = 0) or Repair Information belonging to a valid AAC frame 378 (TYPE > 0). 380 3.1 RTP Header Fields Usage: 382 The RTP header fields are used as follows: 384 Payload Type (PT): It is expected that the RTP profile for a 385 particular class of applications will assign a payload type for this 386 encoding, or alternatively a payload type in the dynamic range shall 387 be chosen. 389 Marker (M) bit: Set to one to mark the last fragment (or only 390 fragment) of an AAC frame. 392 Extension (X) bit: Defined by the RTP profile used. 394 Timestamp (TS): 32-bit timestamp representing the sampling time of the 395 first sample of the first AAC frame in the packet. The clock frequency 396 MUST be set to the sample rate of the encoded audio data and is 397 conveyed out-of-band (i.e. through SDP [8]). If N > 1 frames are 398 present in a RTP packet the TS of the frames 2...N can be calculated 399 by computing the sequence number difference between those frames and 400 the first frame since the sample rate and the number of samples per 401 frame are fixed and known. All packets that make up a fragmented AAC 402 frame MUST use the same TS. Timestamps start at a random value to 403 improve security. 405 SSRC: set as described in RFC1889 [2]. 407 CC and CSRC fields are used as described in RFC 1889 [2]. 409 RTCP SHOULD be used as defined in RFC 1889 [2] 411 4. Security Considerations 413 RTP packets using the payload format defined in this specification are 414 subject to the security considerations discussed in the RTP 415 specification [2]. This implies that confidentiality of the media 416 streams is achieved by encryption. Because the data compression used 417 with this payload format is applied end-to-end, encryption may be 418 performed on the compressed data so there is no conflict between the 419 two operations. 421 This payload type does not exhibit any significant non-uniformity in 422 the receiver side computational complexity for packet processing to 423 cause a potential denial-of-service threat. 425 5. Intellectual Property Disclosure 427 A US patent application has been filed on the usage and computation 428 of predictability information for transmission over lossy channels. 430 6. References 432 [1] ISO/IEC 13818-7 Advanced Audio Coding (AAC). 434 [2] ISO/IEC 14496-3:1999 "Information technology - Coding of 435 audio-visual objects - Part 3: Audio," December, 1999. 437 [3] ISO/IEC 14496-3:1999 / AMD1:2000. 439 [4] Schulzrinne, Casner, Frederick, Jacobson RTP: A 440 Transport Protocol for Real Time Applications RFC 1889, 441 Internet Engineering Task Force, January 1996. 443 [5] S. Bradner, Key words for use in RFCs to Indicate 444 Requirement Levels, RFC 2119, March 1997. 446 [6] Perkins C., Kouvelas I., Hodson O., Hardman V., Bolot J.C, 447 Vega-Garcia A., Fosse-Parisis S. "RTP Payload for Redundant Audio Data", 448 RFC 2198, Internet Engineering Task Force, September 1997. 450 [7] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar 451 RTP Payload Format for MPEG1/MPEG2 Video RFC 2250, 452 Internet Engineering Task Force, January 1998. 454 [8] M. Handley, V. Jacobson, SDP: Session Description Protocol 455 RFC 2327, Internet Engineering Task Force, April 1998. 457 7. Authors' Addresses 459 Mathias Kretschmer 460 AT&T Labs - Research 461 180 Park Ave. 462 Florham Park, NJ 07932 463 USA 464 e-mail: mathias@research.att.com 466 Andrea Basso 467 AT&T Labs - Research 468 100 Schultz Drive 469 Red Bank, NJ 07701 470 USA 471 e-mail: basso@research.att.com 473 M. Reha Civanlar 474 AT&T Labs - Research 475 100 Schultz Drive 476 Red Bank, NJ 07701 477 USA 478 e-mail: civanlar@research.att.com 480 Schuyler R. Quackenbush 481 AT&T Labs - Research 482 180 Park Ave. 483 Florham Park, NJ 07932 484 USA 485 e-mail: srq@research.att.com 487 James H. Snyder 488 AT&T Labs - Research 489 180 Park Ave. 490 Florham Park, NJ 07932 491 USA 492 e-mail: jhs@research.att.com