idnits 2.17.1 draft-ietf-avt-redundancy-revised-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 59 lines 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 38 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 113 has weird spacing: '...ur byte bound...' == Line 403 has weird spacing: '...mestamp of pr...' -- 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 (3 August 1998) is 9398 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) -- Looks like a reference, but probably isn't: '4-6' on line 67 == Unused Reference: '4' is defined on line 468, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 472, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 475, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 August 1998 4 Colin Perkins 5 Isidor Kouvelas 6 Orion Hodson 7 Vicky Hardman 8 University College London 10 Mark Handley 11 ISI 13 Jean-Chrysostome Bolot 14 Andres Vega-Garcia 15 Sacha Fosse-Parisis 16 INRIA Sophia Antipolis 18 RTP Payload for Redundant Audio Data 19 draft-ietf-avt-redundancy-revised-00.txt 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working documents 24 of the Internet Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months and 29 may be updated, replaced, or obsoleted by other documents at any time. It 30 is inappropriate to use Internet-Drafts as reference material or to cite 31 them other than as ``work in progress.'' 33 To view the entire list of current Internet-Drafts, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 36 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 37 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 39 Distribution of this document is unlimited. 41 Comments are solicited and should be addressed to the authors and/or the 42 AVT working group's mailing list at rem-conf@es.net. 44 Abstract 46 This document describes a payload format for use with the 47 real-time transport protocol (RTP), version 2, for encoding 48 redundant audio data. The primary motivation for the scheme 49 described herein is the development of audio conferencing 50 tools for use with lossy packet networks such as the Internet 51 Mbone, although this scheme is not limited to such applications. 53 1 Introduction 55 If multimedia conferencing is to become widely used by the Internet Mbone 56 community, users must perceive the quality to be sufficiently good for most 57 applications. We have identified a number of problems which impair the 58 quality of conferences, the most significant of which is packet loss. This 59 is a persistent problem, particularly given the increasing popularity, and 60 therefore increasing load, of the Internet. The disruption of speech 61 intelligibility even at low loss rates which is currently experienced may 62 convince a whole generation of users that multimedia conferencing over the 63 Internet is not viable. The addition of redundancy to the data stream is 64 offered as a solution [1]. If a packet is lost then the missing 65 information may be reconstructed at the receiver from the redundant data 66 that arrives in the following packet(s), provided that the average number 67 of consecutively lost packets is small. Recent work [4-6] shows that 68 packet loss patterns in the Internet are such that this scheme typically 69 functions well. 71 This document describes an RTP payload format for the transmission of audio 72 data encoded in such a redundant fashion. Section 2 presents the 73 requirements and motivation leading to the definition of this payload 74 format, and does not form part of the payload format definition. Sections 75 3 onwards define the RTP payload format for redundant audio data. 77 2 Requirements/Motivation 79 The requirements for a redundant encoding scheme under RTP are as 80 follows: 82 o Packets have to carry a primary encoding and one or more redundant 83 encodings. 85 o As a multitude of encodings may be used for redundant information, 86 each block of redundant encoding has to have an encoding type 87 identifier. 89 o As the use of variable size encodings is desirable, each encoded 90 block in the packet has to have a length indicator. 92 o The RTP header provides a timestamp field that corresponds to 93 the time of creation of the encoded data. When redundant encodings 94 are used this timestamp field can refer to the time of creation 95 of the primary encoding data. Redundant blocks of data will 96 correspond to different time intervals than the primary data, 97 and hence each block of redundant encoding will require its own 98 timestamp. To reduce the number of bytes needed to carry the 99 timestamp, it can be encoded as the difference of the timestamp 100 for the redundant encoding and the timestamp of the primary. 102 There are two essential means by which redundant audio may be added 103 to the standard RTP specification: a header extension may hold the 104 redundancy, or one, or more, additional payload types may be defined. 106 Including all the redundancy information for a packet in a header 107 extension would make it easy for applications that do not implement 108 redundancy to discard it and just process the primary encoding data. 109 There are, however, a number of disadvantages with this scheme: 111 o There is a large overhead from the number of bytes needed for 112 the extension header (4) and the possible padding that is needed 113 at the end of the extension to round up to a four byte boundary 114 (up to 3 bytes). For many applications this overhead is unacceptable. 116 o Use of the header extension limits applications to a single redundant 117 encoding, unless further structure is introduced into the extension. 118 This would result in further overhead. 120 For these reasons, the use of RTP header extension to hold redundant 121 audio encodings is disregarded. 123 The RTP profile for audio and video conferences [3] lists a set of 124 payload types and provides for a dynamic range of 32 encodings that 125 may be defined through a conference control protocol. This leads 126 to two possible schemes for assigning additional RTP payload types 127 for redundant audio applications: 129 1.A dynamic encoding scheme may be defined, for each combination 130 of primary/redundant payload types, using the RTP dynamic payload 131 type range. 133 2.A single fixed payload type may be defined to represent a packet 134 with redundancy. This may then be assigned to either a static 135 RTP payload type, or the payload type for this may be assigned 136 dynamically. 138 It is possible to define a set of payload types that signify a particular 139 combination of primary and secondary encodings for each of the 32 dynamic 140 payload types provided. This would be a slightly restrictive yet feasible 141 solution for packets with a single block of redundancy as the number of 142 possible combinations is not too large. However the need for multiple 143 blocks of redundancy greatly increases the number of encoding combinations 144 and makes this solution not viable. 146 A modified version of the above solution could be to decide prior 147 to the beginning of a conference on a set a 32 encoding combinations 148 that will be used for the duration of the conference. All tools in the 149 conference can be initialized with this working set of encoding 150 combinations. Communication of the working set could be made through the 151 use of an external, out of band, mechanism. Setup is complicated as great 152 care needs to be taken in starting tools with identical parameters. This 153 scheme is more efficient as only one byte is used to identify combinations 154 of encodings. 156 It is felt that the complication inherent in distributing the mapping of 157 payload types onto combinations of redundant data preclude the use of this 158 mechanism. 160 A more flexible solution is to have a single payload type which signifies 161 a packet with redundancy. That packet then becomes a container, 162 encapsulating multiple payloads into a single RTP packet. Such a 163 scheme is flexible, since any amount of redundancy may be encapsulated 164 within a single packet. There is, however, a small overhead since 165 each encapsulated payload must be preceded by a header indicating 166 the type of data enclosed. This is the preferred solution, since 167 it is both flexible, extensible, and has a relatively low overhead. 168 The remainder of this document describes this solution. 170 3 Payload Format Specification 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC2119 [8]. 176 The assignment of an RTP payload type for this new packet format 177 is outside the scope of this document, and will not be specified 178 here. It is expected that the RTP profile for a particular class 179 of applications will assign a payload type for this encoding, or 180 if that is not done then a payload type in the dynamic range shall 181 be chosen. 183 An RTP packet in redundant stream shall have a standard RTP header, 184 with payload type indicating redundancy. The other fields of the 185 RTP header relate to the primary data block of the redundant data. 187 Following the RTP header are a number of additional headers, defined 188 in the figure below, which specify the contents of each of the encodings 189 carried by the packet. Following these additional headers are a 190 number of data blocks, which contain the standard RTP payload data 191 for these encodings. It is noted that all the headers are aligned 192 to a 32 bit boundary, but that the payload data will typically not 193 be aligned. If multiple redundant encodings are carried in a packet, 194 they should correspond to different time intervals: there is no 195 reason to include multiple copies of data for a single time interval 196 within a packet. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |F| block PT | timestamp offset | block length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 The bits in the header are specified as follows: 206 F: 1 bit First bit in header indicates whether another header block 207 follows. If 1 further header blocks follow, if 0 this is the 208 last header block. 210 block PT: 7 bits RTP payload type for this block. 212 timestamp offset: 14 bitsUnsigned offset of timestamp of this block 213 relative to timestamp given in RTP header. The use of an unsigned 214 offset implies that redundant data must be sent after the primary 215 data, and is hence a time to be subtracted from the current 216 timestamp to determine the timestamp of the data for which this 217 block is the redundancy. 219 block length: 10 bits Length in bytes of the corresponding data 220 block excluding header. 222 It is noted that the use of an unsigned timestamp offset limits the use of 223 redundant data slightly: it is not possible to send redundancy before the 224 primary encoding. This may affect schemes where a low bandwidth coding 225 suitable for redundancy is produced early in the encoding process, and 226 hence could feasibly be transmitted early. However, the addition of a sign 227 bit would unacceptably reduce the range of the timestamp offset, and 228 increasing the size of the field above 14 bits limits the block length 229 field. It seems that limiting redundancy to be transmitted after the 230 primary will cause fewer problems than limiting the size of the other 231 fields. 233 The timestamp offset for a redundant block is measured in the same 234 units as the timestamp of the primary encoding (ie: audio samples, 235 with the same clock rate as the primary). The implication of this 236 is that the redundant encoding MUST be sampled at the same rate as 237 the primary. 239 It is further noted that the block length and timestamp offset are 240 10 bits, and 14 bits respectively; rather than the more obvious 8 241 and 16 bits. Whilst such an encoding complicates parsing the header 242 information slightly, and adds some additional processing overhead, 243 there are a number of problems involved with the more obvious choice: 244 An 8 bit block length field is sufficient for most, but not all, 245 possible encodings: for example 80ms PCM and DVI audio packets comprise 246 more than 256 bytes, and cannot be encoded with a single byte length 247 field. It is possible to impose additional structure on the block 248 length field (for example the high bit set could imply the lower 249 7 bits code a length in words, rather than bytes), however such schemes 250 are complex. The use of a 10 bit block length field retains simplicity 251 and provides an enlarged range, at the expense of a reduced range 252 of timestamp values. 254 The primary encoding block header is placed last in the packet. It 255 is therefore possible to omit the timestamp and block-length fields 256 from the header of this block, since they may be determined from 257 the RTP header and overall packet length. The header for the primary 258 (final) block comprises only a zero F bit, and the block payload 259 type information, a total of 8 bits. This is illustrated in the 260 figure below: 262 0 1 2 3 4 5 6 7 263 +-+-+-+-+-+-+-+-+ 264 |0| Block PT | 265 +-+-+-+-+-+-+-+-+ 267 The final header is followed, immediately, by the data blocks, stored 268 in the same order as the headers. There is no padding or other delimiter 269 between the data blocks, and they are typically not 32 bit aligned. 270 Again, this choice was made to reduce bandwidth overheads, at the 271 expense of additional decoding time. 273 At the start of talkspurts, there is not enough information to send | 274 redundant information. In this case the largest offset in the talkspurt | 275 SHOULD be advertised to enable receiving applications to provision | 276 sufficient buffer space to ensure all of the redundant data received | 277 can be used. The advertisement is communicated by a redundant header | 278 showing zero block length and the maximum timestamp offset required. | 280 The choice of encodings used should reflect the bandwidth requirements of 281 those encodings. It is expected that the redundant encoding shall use 282 significantly less bandwidth that the primary encoding: the exception 283 being the case where the primary is very low-bandwidth and has high 284 processing requirement, in which case a copy of the primary MAY be used as 285 the redundancy. The redundant encoding MUST NOT be higher bandwidth than 286 the primary. 288 The use of multiple levels of redundancy is rarely necessary. However, 289 in those cases which require it, the bandwidth required by each level 290 of redundancy is expected to be significantly less than that of the 291 previous level. 293 4 Limitations 295 The RTP marker bit is not preserved for redundant data blocks. Hence 296 if the primary (containing this marker) is lost, the marker is lost. 297 It is believed that this will not cause undue problems: even if 298 the marker bit was transmitted with the redundant information, there 299 would still be the possibility of its loss, so applications would 300 still have to be written with this in mind. 302 In addition, CSRC information is not preserved for redundant data. 303 The CSRC data in the RTP header of a redundant audio packet relates 304 to the primary only. Since CSRC data in an audio stream is expected 305 to change relatively infrequently, it is recommended that applications 306 which require this information assume that the CSRC data in the RTP 307 header may be applied to the reconstructed redundant data. 309 5 Relation to SDP 311 When a redundant payload is used, it may need to be bound to an 312 RTP dynamic payload type. This may be achieved through any out-of-band 313 mechanism, but one common way is to communicate this binding using 314 the Session Description Protocol (SDP) [7]. SDP has a mechanism 315 for binding a dynamic payload types to particular codec, sample rate, 316 and number of channels using the ``rtpmap'' attribute. An example 317 of its use (using the RTP audio/video profile [3]) is: 319 m=audio 12345 RTP/AVP 121 0 5 320 a=rtpmap:121 red/8000/1 322 This specifies that an audio stream using RTP is using payload types 323 121 (a dynamic payload type), 0 (PCM u-law) and 5 (DVI). The ``rtpmap'' 324 attribute is used to bind payload type 121 to codec ``red'' indicating 325 this codec is actually a redundancy frame, 8KHz, and monaural. When 326 used with SDP, the term ``red'' is used to indicate the redundancy 327 format discussed in this document. 329 In this case the additional formats of PCM and DVI are specified. 330 The receiver must therefore be prepared to use these formats. Such 331 a specification means the sender will send redundancy by default, 332 but also may send PCM or DVI. However, with a redundant payload we 333 additionally take this to mean that no codec other than PCM or DVI 334 will be used in the redundant encodings. Note that the additional 335 payload formats defined in the ``m='' field may themselves be dynamic 336 payload types, and if so a number of additional ``a='' attributes 337 may be required to describe these dynamic payload types. 339 To receive a redundant stream, this is all that is required. However 340 to send a redundant stream, the sender needs to know which codecs 341 are recommended for the primary and secondary (and tertiary, etc) 342 encodings. This information is specific to the redundancy format, 343 and is specified using an additional attribute ``fmtp'' which conveys 344 format-specific information. A session directory does not parse the 345 values specified in an fmtp attribute but merely hands it to the 346 media tool unchanged. For redundancy, we define the format parameters 347 to be a slash ``/'' separated list of RTP payload types. 349 Thus a complete example is: 351 m=audio 12345 RTP/AVP 121 0 5 352 a=rtpmap:121 red/8000/1 353 a=fmtp:121 0/5 355 This specifies that the default format for senders is redundancy 356 with PCM as the primary encoding and DVI as the secondary encoding. 357 Encodings cannot be specified in the fmtp attribute unless they are 358 also specified as valid encodings on the media (``m='') line. 360 6 Security Considerations 362 RTP packets containing redundant information are subject to the security 363 considerations discussed in the RTP specification [2], and any appropriate 364 RTP profile (for example [3]). This implies that confidentiality 365 of the media streams is achieved by encryption. Encryption of a 366 redundant data stream may occur in two ways: 368 1.The entire stream is to be secured, and all participants are 369 expected to have keys to decode the entire stream. In this 370 case, nothing special need be done, and encryption is performed 371 in the usual manner. 373 2.A portion of the stream is to be encrypted with a different 374 key to the remainder. In this case a redundant copy of the 375 last packet of that portion cannot be sent, since there is no 376 following packet which is encrypted with the correct key in which 377 to send it. Similar limitations may occur when enabling/disabling 378 encryption. 380 The choice between these two is a matter for the encoder only. Decoders 381 can decrypt either form without modification. 383 Whilst the addition of low-bandwidth redundancy to an audio stream 384 is an effective means by which that stream may be protected against 385 packet loss, application designers should be aware that the addition 386 of large amounts of redundancy will increase network congestion, and 387 hence packet loss, leading to a worsening of the problem which the 388 use of redundancy was intended to solve. At its worst, this can 389 lead to excessive network congestion and may constitute a denial 390 of service attack. 392 7 Example Packet 394 An RTP audio data packet containing a DVI4 (8KHz) primary, and a 395 single block of redundancy encoded using 8KHz LPC (both 20ms packets), 396 as defined in the RTP audio/video profile [3] is illustrated: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |V=2|P|X| CC=0 |M| PT | sequence number of primary | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | timestamp of primary encoding | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | synchronization source (SSRC) identifier | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |1| block PT=7 | timestamp offset | block length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |0| block PT=5 | | 410 +-+-+-+-+-+-+-+-+ + 411 | | 412 + LPC encoded redundant data (PT=7) + 413 | (14 bytes) | 414 + +---------------+ 415 | | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 417 | | 418 + + 419 | | 420 + + 421 | | 422 + + 423 | DVI4 encoded primary data (PT=5) | 424 + (84 bytes, not to scale) + 425 / / 426 + + 427 | | 428 + + 429 | | 430 + +---------------+ 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 8 Author's Addresses 435 Colin Perkins/Isidor Kouvelas/Orion Hodson/Vicky Hardman 436 Department of Computer Science 437 University College London 438 London WC1E 6BT 439 United Kingdom 440 Email: {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.uk 442 Mark Handley 443 USC Information Sciences Institute 444 c/o MIT Laboratory for Computer Science 445 545 Technology Square 446 Cambridge, MA 02139, USA 447 Email: mjh@isi.edu 449 Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis 450 INRIA Sophia Antipolis 451 2004 Route des Lucioles, BP 93 452 06902 Sophia Antipolis 453 France 454 Email: {bolot|avega|sfosse}@sophia.inria.fr 456 9 References 458 [1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson; Reliable 459 Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu, 460 Hawaii, September 1995. http://www.isoc.org/in95prc/ 462 [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson; RTP: 463 A Transport Protocol for Real-Time Applications; RFC 1889, January 1996 465 [3] H. Schulzrinne; RTP Profile for Audio and Video Conferences with 466 Minimal Control; RFC 1890, January 1996 468 [4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation in the 469 MBone multicast network; IEEE Globecom Internet workshop, London, 470 November 1996 472 [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error control 473 for packet audio in the Internet; ACM Multimedia Systems, 1997 475 [6] I. Kouvelas, O.Hodson, V.Hardman and J. Crowcroft; Redundancy Control 476 in Real-Time Internet Audio Conferencing Proceedings AVSPN 1997, 477 Aberdeen, Scotland, September 1997 479 [7] M. Handley and V. Jacobson; SDP: Session Description Protocol; 480 RFC2327, April 1998. 482 [8] S. Bradner, "Key words for use in RFCs to indicate requirement 483 levels"; RFC2119, March 1997.