idnits 2.17.1 draft-ietf-avt-rtp-mpeg2aac-01.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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 30 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 (November 22, 2000) is 8527 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 435, 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-01.txt Snyder-AT&T 4 November 22, 2000 5 Expires: May 22, 2001 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 MPEG-2/MPEG-4 32 AAC encoded data using RTP. MPEG-2/MPEG-4 AAC is a recent standard from 33 ISO/IEC [1] [2] [3] for coding multi-channel audio data. This payload 34 format increases the packet loss resilience of AAC coded audio 35 transport above that of 'RTP Payload Format for MPEG1/MPEG2 Video (RFC 36 2250)' [7] by incorporating AAC properties into the payload format. 37 Supported features comprise interleaving, grouping, repair information 38 and a predictability vector. The MPEG-2/MPEG-4 AAC bitstream format is 39 not backwards compatible with other MPEG-2 audio formats (e.g. MP3). 40 Several services provided by RTP are beneficial for MPEG-2/MPEG-4 41 AAC encoded data transport over the Internet. Additionally, the use of 42 RTP allows for the synchronization of MPEG-2/MPEG-4 AAC with other 43 real-time streams. 45 In this version of the draft: 46 - MPEG-4 AAC streams are covered in addition to MPEG-2 47 - The format is simplified and made more flexible 48 - RSEQ/SEQ size mismatch fixed 49 - TS clock frequency now equals the payload's sampling rate 50 - Use of the predictability vectors is made optional 52 1. Introduction 54 The ISO/IEC MPEG-2/MPEG-4 Advanced Audio Coding (AAC) [1] [2] [3] 55 technology delivers CD-like or better multichannel audio quality at 56 rates around 64 kBit/s per channel. It has a flexible bitstream syntax 57 that supports from 1 to 48 audio channels, up to 16 subwoofer channels 58 and up to 16 embedded data channels. AAC supports a wide range of 59 sampling frequencies (from 16 kHz to 96 kHz) and an extremely wide 60 range of bitrates. AAC can support applications ranging from 61 professional or home theater sound systems to Internet music broadcast 62 systems. 64 The syntax of MPEG-2 AAC compressed data streams is identical to that 65 of MPEG-4 AAC main, AAC LC and AAC SSR General Audio compressed data 66 streams, so that MPEG-2 AAC is fully forward compatible with MPEG-4 67 AAC. Both MPEG-2 AAC and MPEG-4 AAC provide the same level of 68 compression performance. However, the semantics of MPEG-4 AAC is 69 different in one small respect, precluding a full backward 70 compatibility of MPEG-4 AAC to MPEG-2 AAC. 72 Benefits of using RTP for MPEG-2/MPEG-4 AAC stream transport include: 74 i. Providing increased packet loss resilience based on application 75 layer framing. 77 ii. The ability to synchronize AAC streams with other RTP payloads 79 iii. Monitoring MPEG-2/MPEG-4 AAC delivery performance through RTCP 81 iv. Combining MPEG-2/MPEG-4 AAC and other real-time data streams 82 received from multiple end-systems into a set of consolidated 83 streams through RTP mixers 85 v. Converting data types, etc. through the use of RTP translators. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [5]. 91 1.1 Overview of MPEG-2/MPEG-4 AAC 93 AAC combines the coding efficiencies of a high resolution filter bank, 94 a powerful model of audio perception, backward-adaptive prediction, 95 joint channel coding, and Huffman coding to achieve high-quality 96 signal compression. In 1998 the MPEG Audio subgroup tested the family 97 of MPEG audio coders (see http://www.tnt.uni-hannover.de/project/mpeg/ 98 audio/public/w2006.pdf). The test results indicate that for a stereo 99 signal, AAC at 96 kBit/s has audio quality comparable to MPEG-2 Layer 3 100 ("mp3") at 128 kBit/s. 102 AAC is a block oriented, variable rate coding algorithm. An AAC 103 encoder takes 1024 samples per channel at a time (a 'block') as input 104 and the compressed representation is variable in size. 106 Rate control can be used at the encoder to generate a constant-rate 107 bitstream. Each block of AAC compressed bits is called a "raw data 108 block", and can be decoded "stand-alone", that is, without information 109 from prior raw data blocks. This feature is particularly useful for 110 the delivery of AAC over lossy packet networks since the loss of a 111 packet does not directly affect the decodability of the adjacent 112 packets. 114 1.2 Bitstream Syntax 116 The syntax of an AAC bitstream is as follows: 118 => 119 => [] 121 where indicates the AAC bitstream, indicates 122 intermediate tokens, indicates terminal tokens and [] 123 indicates one or more occurrence. is a token that indicates the 124 end of a raw_data_block and is a variable length token that 125 forces the total length of a raw_data_block to be an integral number 126 of bytes. In general, intermediate tokens are not an integral number of 127 bytes in length. 129 The tokens are a string of bits of variable length, and they 130 can be any of the following: 132 a single audio channel 133 a stereo presentation (2 channels) 134 a mechanism for multi-channel compression 135 a special effects channel 136 "user data" 137 a mechanism for describing the bitstream 138 content 139 a mechanism to use bits (for constant rate 140 channels) 142 The can occur several times in a single 143 raw_data_block. For example, the raw_data_block for a 5.1 surround 144 sound signal would be: 146 ... 147 149 corresponding to the center, left and right, left surround and right 150 surround and effects channels. Occurances of the 151 are dis-ambiguated by means of a unique 4-bit id inside the 152 . 154 2. Issues covered by this Payload Format 156 2.1 Repair Information to reconstruct lost AAC Frames (Unequal FEC) 158 A smart AAC decoder can mitigate the effects of lost packets using 159 techniques such as interpolation in the spectral domain. However if 160 the raw_data_block in a packet is perceptually significant and also 161 highly unpredictable (e.g. the onset of a cymbal crash) then the 162 sender may choose to add repair information associated with that 163 raw_data_block. This form of unequal FEC allows the encoder/sender to 164 protect a stream depending on known loss characteristics and/or frame 165 predictability. A given repair information block (AAC DATA chunk with 166 TYPE > 0) is typically associated with a raw_data_block (TYPE = 0). 167 The association between the raw_data_block and the repair information 168 is obtained by means of the SEQ field. 170 Repair Information as defined here is a valid AAC raw_data_block. As 171 an example, the Repair Information can be a highly compressed 172 monophonic version of a subset of the signal being transmitted. An AAC 173 stereo signal coded at a sampling rate of 44100 samples/s and a bit 174 rate of 96 kBit/s corresponds to an average raw_data_block size of 279 175 bytes. A RepairData version of that block, compressed to 16 kBit/s 176 would be 46 bytes in length. Given that perceptually critical blocks 177 might occur only once per 100 or more blocks, the average rate 178 increase associated with this type of RepairData can be very 179 low. Generally, the Repair Information for a given AAC frame X SHALL 180 be carried by a different RTP packet then the one that carries 181 X. Generally, the Repair Information MUST be computed at the same 182 sampling rate as the stream being repaired. 184 The usage of the Repair Information is similar to the one proposed 185 in [6]. The OPTIONAL Repair Information MAY be provided for every 186 frame. RepairData can be generated in many ways including using two 187 encoders, decoding followed by coding or processing the original 188 bitstream. 190 2.2 Fragmentation of AAC Frames 192 It is desirable to limit the size of the AAC frame to less than the 193 path-MTU. If this is not possible, the frame can be fragmented across 194 several RTP packets. Fragmentation MUST occur at boundaries. 195 An RTP packet contains either an integer number of complete AAC frames 196 or fragments of a single AAC frame. Subsequent packets containing a 197 fragmented AAC frame have a much simpler header that is just one byte 198 long. They can be identified by the F-bit set to 1. In this case UBITS 199 indicates the number of unused bits in the first byte in the case that 200 the fragment is not byte-aligned. The total length of the fragment can 201 be determined from the total length of the packet excluding the RTP 202 header. The R-bit is reserved for future use. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |X|X|X|F|UBITS|R|AAC FRAGMENT | 208 +-+-+-+-+-+-+-+-+ | 209 | | 210 | | 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 2.3 Predictability of AAC Frames 216 AAC frame predictability allows adaptive handling of packet losses 217 and/or bandwidth constraints by signalling the need for an action a 218 receiver may take when an associated AAC frame is lost. Every AAC frame 219 will be assigned to one of the following three predictability classes: 221 - 0: not predictable 222 - 1: one side predictable (either L-predictable or R-predictable) 223 - 2: two side predictable 224 (- 3: reserved) 226 An AAC frame that belongs to class 0 cannot be easily concealed using 227 any other AAC frame(s) in the bitstream. 229 An AAC frame that belongs to class 1 can be predicted either from 230 previous (R-predictable) or following (L-predictable) AAC frame but 231 not from both. 233 An AAC frame that belongs to class 2 can be predicted from the 234 preceding or following AAC frame or from both. 236 Predictability information is coded for every RTP AAC packet in the 237 Predictability Quantifier (PQ) which is 2 bits in length. For a given 238 RTP packet such PQs are organized in a predictability vector which 239 represents a sliding window of PQs, starting with the current packet's 240 PQ followed by preceding packets' PQs. 242 2.4 Grouping and Interleaving of AAC Frames 244 It is often desirable to group an integer number of AAC frames. The 245 predictability of such an RTP packet is the predictability of the AAC 246 frame in the RTP packet which is least predictable. AAC frames 247 belonging to the same predictability class MAY be grouped into one RTP 248 packet. Note that if frames of different predictabilities are grouped 249 much of the usefulness of the predictability information is lost. The 250 sequence numbers SEQ of the AAC DATA chunks are used to restore the 251 proper order on the receiver side. 253 Grouping AAC frames into a single RTP packet is OPTIONAL. 255 2.5 Example RTP Packet Sequence 257 The example below shows a sequence of AAC frames (a...p) and their 258 assigned predictability classes. 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | 2 | 2 | 2 | 1 | 0 | 1 | 2 | 2 | 2 | 2 | 2 | 1 | 0 | 1 | 2 | 2 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 The AAC frames MAY be grouped according to their predictability. 267 R(x) is the RepairData information sent within the RTP packet: 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |a g j|b h k|c i o| d f | e | l n | m | p | | 271 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 272 | | |R(e) | | |R(m) | | | | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 3. RTP AAC Payload Format 277 The AAC specific RTP payload consists of a 8, 32, 64 or 96 bit header, 278 and a variable number of AAC DATA chunks. The type of those chunks is 279 identified by TYPE field. The LENGTH field specifies the length of a 280 chunk in bytes and SEQ is a sequence number which allows grouping, 281 interleaving and association of Repair Info with the frame it repairs. 283 The header contains a vector of Predictability Quantizers (PQ) which 284 specify the packets' predictability classes, and a set of control 285 bits. 287 The PVS field specifies if the header contains 12, 28 or 44 PQs. At 288 the beginning of a session, if fewer packets have been transmitted/ 289 received than there are PQs in the header then the extra PQs are 290 invalid and MUST be set to 0 (on the sender side) and MUST be ignored 291 (on the receiver side). 293 If a sender provides a predictability vector but does not provide 294 frame predictability information it MUST set all PQs to 0. A client 295 can ignore the information provided by PQs since PQs are not required 296 for decoding AAC frames. PQs can be used to decide when to ask for 297 retransmission of lost packets. PQs can also provide hints which help 298 a PQ-aware decoder to improve the audio quality when concealing lost 299 packets. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |PVS|M|F| MBZ |PRD VECTOR (PVS > 0) | Header 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |PRD VECTOR (PVS > 1) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |PRD VECTOR (PVS > 2) | 309 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 310 |TYPE |SEQ |LENGTH (if M==1) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 312 |AAC DATA 1 | AAC 313 | | Data 314 | | 315 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | |TYPE |SEQ |LENGTH | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 318 | |AAC DATA 2 | 319 |-+-+-+-+-+-+-+-+ | 320 | . | 321 | . | 322 | . | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 324 |TYPE |SEQ |LENGTH | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 326 |AAC DATA N | 327 | | 328 | | 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 PRD VECTOR: Predictability vector. It contains either 12, 28 or 44 333 Predictability Quantifiers (PQ). The size of a PQ element 334 is 2 bits. The first PQ refers to the predictability class of 335 the current packet. The following PQs refer to the most 336 recent previous packets. Thus, the vector looks like this: 337 {PQ(t), PQ(t-1), PQ(t-2)...} 338 The predictability class of a packet is that of the least 339 predictable AAC frame that is contained in the packet. 341 PVS: Predictability Vector Size. Specifies the number of 32bit 342 words used for the Predictability Vector. The first 32bit 343 word contains the flags field. Hence, only the lower 344 significant 24bits belong to the vector. If PVS is set to 345 0 the predictability vector field does not exist, and 346 the TYPE field is contiguous with the MBZ field. 348 M: If M is set, then the payload contains more than one AAC 349 frame. Hence, a LENGTH field for the first frame MUST be 350 present. If M is clear, then only one AAC frame is present, 351 and no LENGTH field is present. 353 F: Fragmented Frame. 355 MBZ: Must be set to 0. 357 TYPE: The type of AAC DATA. This field specifies if the AAC DATA 358 is an original AAC frame or contains some form of Error 359 Correction data. The following types are defined for now: 360 0: Original AAC frame 361 1: Identical to original frame but sent for redundancy 362 2: Same AAC configuration but encoded using less bits 363 (Repair Information) 364 (all three types are valid AAC frames) 366 SEQ: The sequence number enumerates AAC frames at the stream level. 367 It may be used to support interleaving or association of Repair 368 Information with TYPE==0 AAC frames, etc. 370 LENGTH: The length of the AAC Data in bytes. 372 AAC DATA: The actual AAC data chunk. This is either a valid AAC frame 373 (TYPE = 0) or Repair Information belonging to a valid AAC frame 374 (TYPE > 0). 376 3.1 RTP Header Fields Usage: 378 The RTP header fields are used as follows: 380 Payload Type (PT): It is expected that the RTP profile for a 381 particular class of applications will assign a payload type for this 382 encoding, or alternatively a payload type in the dynamic range shall 383 be chosen. 385 Marker (M) bit: Set to one to mark the last fragment (or only 386 fragment) of an AAC frame. 388 Extension (X) bit: Defined by the RTP profile used. 390 Timestamp (TS): 32-bit timestamp representing the sampling time of the 391 first sample of the first AAC frame in the packet. The clock frequency 392 MUST be set to the sample rate of the encoded audio data and is 393 conveyed out-of-band (i.e. through SDP [8]). If N > 1 frames are 394 present in a RTP packet the TS of the frames 2...N can be calculated 395 by computing the sequence number difference between those frames and 396 the first frame since the sample rate and the number of samples per 397 frame are fixed and known. All packets that make up a fragmented AAC 398 frame MUST use the same TS. Timestamps start at a random value to 399 improve security. 401 SSRC: set as described in RFC1889 [2]. 403 CC and CSRC fields are used as described in RFC 1889 [2]. 405 RTCP SHOULD be used as defined in RFC 1889 [2] 407 4. Security Considerations 409 RTP packets using the payload format defined in this specification are 410 subject to the security considerations discussed in the RTP 411 specification [2]. This implies that confidentiality of the media 412 streams is achieved by encryption. Because the data compression used 413 with this payload format is applied end-to-end, encryption may be 414 performed on the compressed data so there is no conflict between the 415 two operations. 417 This payload type does not exhibit any significant non-uniformity in 418 the receiver side computational complexity for packet processing to 419 cause a potential denial-of-service threat. 421 5. Intellectual Property Disclosure 423 A US patent application has been filed on the usage and computation 424 of predictability information for transmission over lossy channels. 426 6. References 428 [1] ISO/IEC 13818-7 Advanced Audio Coding (AAC). 430 [2] ISO/IEC 14496-3:1999 "Information technology - Coding of 431 audio-visual objects - Part 3: Audio," December, 1999. 433 [3] ISO/IEC 14496-3:1999 / AMD1:2000. 435 [4] Schulzrinne, Casner, Frederick, Jacobson RTP: A 436 Transport Protocol for Real Time Applications RFC 1889, 437 Internet Engineering Task Force, January 1996. 439 [5] S. Bradner, Key words for use in RFCs to Indicate 440 Requirement Levels, RFC 2119, March 1997. 442 [6] Perkins C., Kouvelas I., Hodson O., Hardman V., Bolot J.C, 443 Vega-Garcia A., Fosse-Parisis S. "RTP Payload for Redundant Audio Data", 444 RFC 2198, Internet Engineering Task Force, September 1997. 446 [7] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar 447 RTP Payload Format for MPEG1/MPEG2 Video RFC 2250, 448 Internet Engineering Task Force, January 1998. 450 [8] M. Handley, V. Jacobson, SDP: Session Description Protocol 451 RFC 2327, Internet Engineering Task Force, April 1998. 453 7. Authors' Addresses 455 Mathias Kretschmer 456 AT&T Labs - Research 457 180 Park Ave. 458 Florham Park, NJ 07932 459 USA 460 e-mail: mathias@research.att.com 462 Andrea Basso 463 AT&T Labs - Research 464 100 Schultz Drive 465 Red Bank, NJ 07701 466 USA 467 e-mail: basso@research.att.com 469 M. Reha Civanlar 470 AT&T Labs - Research 471 100 Schultz Drive 472 Red Bank, NJ 07701 473 USA 474 e-mail: civanlar@research.att.com 476 Schuyler R. Quackenbush 477 AT&T Labs - Research 478 180 Park Ave. 479 Florham Park, NJ 07932 480 USA 481 e-mail: srq@research.att.com 483 James H. Snyder 484 AT&T Labs - Research 485 180 Park Ave. 486 Florham Park, NJ 07932 487 USA 488 e-mail: jhs@research.att.com