idnits 2.17.1 draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 837. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 13) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (July 6, 2007) is 6133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 763, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Magnus Westerlund 3 INTERNET-DRAFT Per Frojdh 4 Expires: January 2008 Ericsson 5 Intended Status: Informational July 6, 2007 7 SDP and RTSP extensions defined for 3GPP Packet-switched Streaming 8 Service and Multimedia Broadcast/Multicast Service 9 11 Status of this memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a individual submission to the IETF MMUSIC WG. 35 Comments should be directed to the MMUSIC WG mailing list, 36 mmusic@ietf.org. 38 Abstract 40 The Packet-switched Streaming Service (PSS) and the Multimedia 41 Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP 42 with some extensions. This document provides information about these 43 extensions and registers the RTSP and SDP extensions with IANA. 45 TABLE OF CONTENTS 47 1. Definitions..................................................3 48 1.1. Glossary.................................................3 49 2. Introduction.................................................3 50 3. Applicability Statement......................................4 51 4. PSS SDP Extensions...........................................5 52 4.1. Video Buffering attributes...............................5 53 4.2. Video Frame Size attribute...............................5 54 4.3. Integrity Protection Configuration Attributes............6 55 4.4. The Alternative Attributes...............................6 56 4.5. Adaptation Attribute.....................................6 57 4.6. Quality of Experience Attribute..........................7 58 4.7. Asset Information Attribute..............................7 59 5. MBMS SDP Extensions..........................................7 60 5.1. MBMS Bearer Mode Declaration Attribute...................7 61 5.2. FEC Flow ID Attribute....................................7 62 5.3. MBMS Repair Attribute....................................8 63 5.4. SDP Protocol Identifiers for FEC.........................8 64 5.4.1. RTP Protocol Identifiers.............................8 65 5.4.2. FEC Repair Data Identifier...........................8 66 6. SDP Offer/Answer Consideration...............................8 67 7. PSS RTSP Extensions..........................................9 68 7.1. 3GPP-Link-Char Header....................................9 69 7.2. 3GPP-Adaptation Header...................................9 70 7.3. 3GPP-QoE-Metrics Header..................................9 71 7.4. 3GPP-QoE-Feedback Header.................................9 72 7.5. Video buffer Headers....................................10 73 7.6. Integrity Protection....................................10 74 7.7. RTSP URI extension......................................10 75 8. IANA Considerations.........................................11 76 8.1. SDP Registrations.......................................11 77 8.2. RTSP Registrations......................................16 78 9. Normative References........................................18 79 10. Informative References......................................19 80 11. Authors' Addresses..........................................20 81 12. IPR Notice..................................................21 82 13. Copyright Notice............................................21 83 1. Definitions 85 1.1. Glossary 87 3GP - 3GPP file format, a multi-media file format based on the 88 ISO base media file format, existing in different profiles 89 intended for multimedia messages, direct playback on 90 clients, progressive download, usage on servers to deliver 91 on-demand multi-media sessions in PSS, or servers sending 92 MBMS sessions. 93 3GPP - Third Generation Partnership Project, see www.3gpp.org for 94 more information about this organization. 95 FEC - Forward Error Correction 96 MBMS - Multimedia Broadcast/Multicast Service, a service defined 97 by 3GPP that utilizes broadcast or multicast technologhy 98 in combination with unicast for delivery of a wide range 99 of content to mobile terminals. 100 PSS - Packet-switched Streaming Service, a unicast-based 101 streaming service for delivery of on-demand or live 102 streaming multi-media content to mobile terminals. 103 RTSP - Real Time Streaming Protocol, see [RFC2326] 104 SDP - Session Description Protocol, see [RFC4566] 105 SRTP - Secure Real-time Transport Protocol, see [RFC3711] 106 QoE - Quality of Experience, the quality level of the the user 107 experience of a service. In PSS this is estimated by a 108 combination of application-level metrics. 109 QoS - Quality of Service, the quality (properties) that the 110 network provides toward the upper layer service. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 114 in this document are to be interpreted as described in RFC 2119. 116 2. Introduction 118 3GPP has specified the Packet-switched Streaming Service (PSS) that 119 uses both RTSP [RFC2326] and SDP [RFC4566]. The service is specified 120 in technical specifications TS 26.233 [PSS-233] and TS 26.234 [PSS- 121 234] in Release 4 and later releases. The basic service defined in 122 Release 4 is enhanced in Release 5 with capability exchange and in 123 Release 6 with a number of features, such as adaptation, digital 124 rights management, progressive download as well as a streaming 125 server file-format defined in [PSS-3GP]. 127 3GPP has also specified the Multimedia Broadcast/Multicast Service 128 (MBMS) that uses SDP. The IP layer protocols used by this service 129 are specified in technical specification TS 26.346 Release 6 [MBMS]. 131 In the process of defining these services, there has occasionally 132 been the need to extend both SDP and RTSP functionality. These 133 extensions have mostly been in the form of SDP attributes and RTSP 134 headers. The purpose of this informational document is to register 135 these SDP and RTSP extensions, in order to avoid future conflicts, 136 and also to raise the awareness of their existence within IETF. 138 This document defines in Section 5.4 three SDP protocol identifiers 139 used in MBMS to enable the usage of block-based FEC. The other SDP 140 and RTSP extensions registered by this document are not normatively 141 defined in this document. Instead the normative definitions are 142 referenced by the registrations. 144 The document begins with two chapters presenting the different 145 extensions of SDP for PSS and MBMS, respectively, followed by a 146 section noting that offer/answer considerations are not applicable 147 here. The subsequent section presents the extensions of RTSP for 148 PSS. The IANA registration of SDP attributes and protocol 149 identifiers is given in section 8.1, and the RTSP headers in section 150 8.2. For normative descriptions of all SDP and RTSP extensions we 151 refer to TS 26.234 [PSS-234] and TS 26.346 [MBMS]. 153 3. Applicability Statement 155 This document describes 3GPP-defined extensions to SDP [RFC4566] and 156 RTSP [RFC2326] and registers attributes that are normatively defined 157 in 3GPP technical specifications 26.234, 26.244 and 26.346. 159 They have only been defined with the usage within the service that 160 defines them in mind. The applicability for usage outside of these 161 services has not been considered or addressed. Usage of these 162 attributes in other contexts may require further definitions or 163 clarifications. For example, all SDP attributes lack offer/answer 164 usage rules [RFC3264] which currently makes it impossible to use 165 them with offer/answer. Please note that change control of these SDP 166 and RTSP extensions belongs to 3GPP. 168 4. PSS SDP Extensions 170 The PSS specification [PSS-234] defines a number of different SDP 171 attributes for different purposes. They are informatively listed 172 below grouped by purpose. The text is intentionally not specific 173 enough to allow implementation from this document. The normative 174 definition is in the 3GPP technical specification cited. 176 4.1. Video Buffering attributes 178 The following attributes are used to provide parameters for the 179 video buffer model provided in Annex G and Section 5.3.3.2 of [PSS- 180 234]. The attributes were defined in Release 5 as "X-" attributes 181 and were at the time not considered for registration. In hindsight, 182 however, they should not have been "X-" attributes, and they should 183 have been registered, as the registration rules of SDP [RFC4566] 184 point out. Changing their names today is impossible due to the 185 deployed base of millions of mobile handsets supporting PSS, and 186 therefore they are registered in their current form. 188 All attributes are defined at media level. 190 - The "a=X-predecbufsize" attribute provides the size of the pre- 191 decoder buffer in bytes. 192 - The "a=X-initpredecbufperiod" attribute provides the time during 193 which a receiver should initially buffer, in 90kHz ticks, before 194 starting to consume the data in the buffer in order to ensure 195 that underflow does not occur, assuming correct data delivery. 196 - The "a=X-initpostdecbufperiod" attribute provides the initial 197 buffering period, in 90kHz ticks, for the post-decoder buffer 198 present in H.263 and MPEG-4 Visual. 199 - The "a=X-decbyterate" attribute indicates the maximum peak byte- 200 decoding rate used in the verification of the Annex G buffer 201 model expressed in bytes per second. 202 - The "a=3gpp-videopostdecbufsize" attribute is used to indicate 203 the value used in determining the H.264 video post-decoder buffer 204 size. 206 Note that complete descriptions of these attributes can be found in 207 section 5.3.3.2 of [PSS-234]. 209 4.2. Video Frame Size attribute 211 This media-level attribute provides the receiver with the largest 212 picture size a specific H.263 payload type will carry within the 213 session. The attribute has the following form (see 5.3.3.2 of 214 [PSS-234]): 216 "a=framesize: -" 218 4.3. Integrity Protection Configuration Attributes 220 These attributes are all used to configure the integrity-protection 221 mechanism defined in Annex K (section K.2.2.1, K.2.2.2 and K.2.2.3) 222 of [PSS-234]. 224 - The session-level attribute "a=3GPP-Integrity-Key" carries the 225 integrity key used to derive SRTP master keys for integrity 226 protection. They key is protected in different ways depending on 227 a method identifier. When using OMA DRM keymanagement, the key is 228 encrypted using AES [AES] before it is base64 encoded [RFC4648]. 229 - The media-level attribute "a=3GPP-SRTP-Config" is used to 230 configure SRTP for integrity protection and contains an integrity 231 nonce, a key salt used in deriving the SRTP master key from the 232 integrity key, and any SRTP configuration parameters, such as the 233 integrity tag length. 234 - The session-level attribute "a=3GPP-SDP-Auth" is used to carry an 235 authentication tag calculated over certain parts of the SDP to 236 prevent manipulation of the security attributes. 238 4.4. The Alternative Attributes 240 Two media and one session-level attributes are used in a mechanism 241 for providing alternative SDP lines. One or more SDP lines at media 242 level can be replaced, if desired, by alternatives. The mechanism is 243 backwards compatible in the way that a receiver that does not 244 support the attributes will get the default configuration. The 245 different alternatives can be grouped using different attributes 246 that can be specified hierarchically with a top and a lower level. 247 3GPP Release 6 supports grouping based on bit-rate, according to the 248 SDP bandwidth modifiers AS and TIAS, and language. 250 The SDP attributes (see 5.3.3.3 and 5.3.3.4 of [PSS-234]) are: 251 - The media-level attribute "a=alt::" carries any SDP 252 line and an alternative identifier. 253 - The media-level attribute "a=alt-default-id:" identifies the 254 default configuration to be used in groupings. 255 - The session-level attribute "a=alt-group" is used to group 256 different recommended media alternatives. Providing aggregated 257 properties for the whole group according to the grouping type. 258 Language and bit-rate are two defined grouping types. 260 4.5. Adaptation Attribute 262 The media-level SDP attribute "a=3GPP-Adaptation-Support" (see 263 5.3.3.5 of [PSS-234]) is defined as part of the negotiation 264 procedure of the PSS adaptation mechanism. The attribute carries a 265 single value indicating how often the RTCP "Next Application Data 266 Unit" (NADU) APP packet shall be included in sent RTCP compound 267 packets. The adaptation mechanism allows the client to provide the 268 server with information on the available transmission bit-rate and 269 receiver buffer status. 271 4.6. Quality of Experience Attribute 273 The session and media-level attribute "a=3GPP-QoE-Metrics" (see 274 5.3.3.6 of [PSS-234]) is used to negotiate the usage of the quality 275 of experience metrics. The included parameters indicate which 276 metrics, over which duration there should be measurements, and how 277 often reports should be sent. 279 4.7. Asset Information Attribute 281 The session and media-level attribute "a=3GPP-Asset-Information" 282 (see 5.3.3.7 of [PSS-234]) can exist in multiple instances in a 283 description and describes different types of asset information. The 284 different asset classes defined in Release 6 are: Title, 285 Description, Copyright, Performer, Author, Genre, Rating, 286 Classification, Keywords, Location, Album, and Recording Year. The 287 different assets are described with a BASE64-encoded asset box from 288 the 3GP file format [PSS-3GP]. 290 5. MBMS SDP Extensions 292 The MBMS specification [MBMS] defines a number of different SDP 293 attributes for different purposes. They are informatively listed 294 below. 296 5.1. MBMS Bearer Mode Declaration Attribute 298 The session and media-level attribute "a=mbms-mode" (see 7.3.2.7 of 299 [MBMS]) is used to describe MBMS broadcast mode media. The attribute 300 may be used at session level to set the default for all media and at 301 media level to specify differences between media. However, the 302 attribute is never used at session level when the session includes 303 MBMS multicast mode media, nor at media level to describe MBMS 304 multicast mode media. 306 5.2. FEC Flow ID Attribute 308 The media-level attribute "a=mbms-flowid" (see 8.3.1.9 of [MBMS]) 309 maps one or more FEC source block flow IDs to their corresponding 310 destination IP addresses and UDP port numbers. It is present in each 311 SDP media block for repair packet streams. 313 5.3. MBMS Repair Attribute 315 The session and media-level attribute "a=mbms-repair" (see 8.3.1.8 316 of [MBMS]) is used to provide FEC repair packets with non-FEC 317 specific parameters. For Release 6 one such parameter is defined, 318 specifying the required minimum receiver buffer time. 320 5.4. SDP Protocol Identifiers for FEC 322 MBMS defines a mechanism to provide block-based FEC for UDP-based 323 traffic. This solution uses the SDP protocol "proto" identifier to 324 identify the media streams that use the FEC shim layer. The media 325 streams may be either source streams and repair streams. As required 326 by SDP [RFC4566] these protocol identifiers are normatively defined 327 in this document in accordance with their usage specified by 3GPP. 329 5.4.1. RTP Protocol Identifiers 331 For FEC-protected RTP streams the following two "proto" identifiers 332 are defined: 334 - UDP/MBMS-FEC/RTP/AVP 335 - UDP/MBMS-FEC/RTP/SAVP 337 They indicate the usage of UDP [RFC0768] with MBMS FEC Source packet 338 formats, as defined in Section 8.2.2.4 of [MBMS], that transport RTP 339 packets in accordance with the AVP [RFC3551] or SAVP (Secure RTP) 340 [RFC3711] profiles, respectively. 342 These protocol identifiers SHALL use the FMT space rules that are 343 used for RTP/AVP and RTP/SAVP, respectively. 345 5.4.2. FEC Repair Data Identifier 347 A media stream carrying MBMS FEC repair information over UDP 348 requires its own "proto" identifier. Protocol identifier "UDP/MBMS- 349 REPAIR" identifies the FEC repair packet containing the protocol 350 combination of UDP [RFC0768] and FEC repair payload ID and repair 351 symbols as specified in Section 8.2.2.5 of [MBMS]. The FMT string is 352 not used and SHALL be set to "*". 354 6. SDP Offer/Answer Consideration 355 The usage of the SDP attributes in an Offer/Answer [RFC3264] context 356 is not defined. These SDP attributes are defined for being used in a 357 declarative context, and for PSS specifically in RTSP [RFC2326] 358 context. 360 7. PSS RTSP Extensions 362 The RTSP extensions for PSS consist of a number of new RTSP headers 363 and a narrowing of URI usage in regards to 3GP files. The headers 364 are informatively described here; see [PSS-234] for the normative 365 declaration. 367 7.1. 3GPP-Link-Char Header 369 The "3GPP-Link-Char" header (see 5.3.2.1 of [PSS-234]) is used by 370 clients to provide the server with QoS information about the 371 wireless link it is currently using. The header can be used to 372 provide the server with three different QoS parameters: 373 - Guaranteed Bandwidth 374 - Maximum Bandwidth 375 - Maximum Transfer Delay 377 The header may be included in RTSP requests using either of the 378 methods SETUP, PLAY, OPTIONS and SET_PARAMETER. 380 7.2. 3GPP-Adaptation Header 382 The "3GPP-Adaptation" header (see 5.3.2.2 of [PSS-234]) is used by 383 the client to provide the server with adaptation-related parameters 384 and to indicate support of the adaptation function. The header 385 carries the resource identification as a URI, the client's buffer 386 size, and the desired target time. 388 The header may be included in requests using the methods SETUP, 389 PLAY, OPTIONS and SET_PARAMETER. The response to a request using 390 this method shall include this header. 392 7.3. 3GPP-QoE-Metrics Header 394 The "3GPP-QoE-Metrics" header (see 5.3.2.3.1 of [PSS-234]) is used 395 to negotiate the usage of the quality of experience (QoE) metrics 396 (see Section 11 of [PSS-234]). 398 The header may be included in requests and responses using the 399 SETUP, SET_PARAMTER, OPTIONS or PLAY method. 401 7.4. 3GPP-QoE-Feedback Header 402 The "3GPP-QoE-Feedback" header (see 5.3.2.3.2 of [PSS-234]) is used 403 to carry QoE metrics from the client to the server when it reports, 404 which happen either during or at the end of the media delivery. 406 The header may be included in requests using the SET_PARAMETER, 407 PAUSE, or TEARDOWN method. 409 7.5. Video buffer Headers 411 PSS uses several headers to provide the client with the different 412 buffer parameters. They provide the buffer status at the point of a 413 stream that a PLAY request plays from. These headers may only be 414 used in PLAY responses. See Section 5.3.2.4 and Annex G of [PSS-234] 415 for normative definitions. 417 The three "x-" headers were defined in 3GPP Release 5. When it was 418 realized that they should not have been given "x-" names it was too 419 late rename them due to deployment. 421 The RTSP headers are: 422 - x-predecbufsize 423 - x-initpredecbufperiod 424 - x-initpostdecbufperiod 425 - 3gpp-videopostdecbufsize 427 7.6. Integrity Protection 429 The integrity-protection mechanism defined in PSS Annex K uses the 430 "3GPP-Freshness-Token" (See Section K.2.2.4 of [PSS-234]) RTSP 431 header to carry a freshness token in DESCRIBE requests. 433 7.7. RTSP URI extension 435 The PSS specification also defines syntax for referencing tracks 436 within the "3GP" file format [PSS-3GP]. The 3GP format is based on 437 the ISO base media file format and defined in several different 438 profiles, including a streaming-server profile, in Release 6. 440 This syntax is fully contained within the generic URI syntax defined 441 for RTSP URIs. It is only a syntax restriction server manufacturers 442 follow to allow clients or proxies to understand what encodes the 443 track number in the URI. This is provided for information only. 445 To identify a track within a 3GP file the last URI segment has to 446 contain a structure that is = (See 5.3.3.1 447 of [PSS-234]). 449 8. IANA Considerations 451 8.1. SDP Registrations 453 IANA is requested to register the SDP attributes listed below in the 454 registry at http://www.iana.org/assignments/sdp-parameters. The 455 contact person for this registration is Magnus Westerlund 456 (magnus.westerlund@ericsson.com) Phone number +46 8 719 0000. 458 SDP Protocol Identifiers ("proto"): 460 Name: UDP/MBMS-FEC/RTP/AVP 461 Long form: 3GPP MBMS FEC protected RTP/AVP over UDP 462 Type of name: proto 463 Purpose: 3GPP MBMS defines a mechanism to provide block- 464 based FEC for UDP-based traffic. This solution 465 uses the SDP protocol "proto" identifier to 466 identify the media streams that use the FEC 467 shim layer. This protocol identifier indicates 468 that the FEC protected data is RTP using the 469 AVP profile. 470 Reference: RFCXXXX, 3GPP TS 26.346 472 Name: UDP/MBMS-FEC/RTP/SAVP 473 Long form: 3GPP MBMS FEC protected RTP/SAVP over UDP 474 Type of name: proto 475 Purpose: 3GPP MBMS defines a mechanism to provide block- 476 based FEC for UDP-based traffic. This solution 477 uses the SDP protocol "proto" identifier to 478 identify the media streams that use the FEC 479 shim layer. This protocol identifier indicates 480 that the FEC protected data is RTP using the 481 Secure AVP profile (SAVP). 482 Reference: RFCXXXX, 3GPP TS 26.346 484 Name: UDP/MBMS-REPAIR 485 Long form: 3GPP MBMS FEC repair symbols over UDP 486 Type of name: proto 487 Purpose: 3GPP MBMS defines a mechanism to provide block- 488 based FEC for UDP-based traffic. This solution 489 uses the SDP protocol "proto" identifier to 490 identify the media streams that use the FEC 491 shim layer. This protocol identifier indicates 492 that the FEC repair data is sent over UDP. 493 Reference: RFCXXXX, 3GPP TS 26.346 494 SDP Attribute ("att-field"): 496 Attribute name: X-predecbufsize 497 Long form: Pre-decoder buffer size 498 Type of name: att-field 499 Type of attribute: Media level only 500 Subject to charset: No 501 Purpose: See Section 4.1 502 Reference: 3GPP TS 26.234, Section 5.3.3.2 503 Values: See Reference 505 Attribute name: X-initpredecbufperiod 506 Long form: Pre-decoder initial buffering period 507 Type of name: att-field 508 Type of attribute: Media level only 509 Subject to charset: No 510 Purpose: See Section 4.1 511 Reference: 3GPP TS 26.234, Section 5.3.3.2 512 Values: See Reference 514 Attribute name: X-initpostdecbufperiod 515 Long form: Post-decoder initial buffering period 516 Type of name: att-field 517 Type of attribute: Media level only 518 Subject to charset: No 519 Purpose: See Section 4.1 520 Reference: 3GPP TS 26.234, Section 5.3.3.2 521 Values: See Reference 523 Attribute name: X-decbyterate 524 Long form: Peak decoding rate in bytes per second 525 Type of name: att-field 526 Type of attribute: Media level only 527 Subject to charset: No 528 Purpose: See Section 4.1 529 Reference: 3GPP TS 26.234, Section 5.3.3.2 530 Values: See Reference 532 Attribute name: 3gpp-videopostdecbufsize 533 Long form: Post decoder buffer size 534 Type of name: att-field 535 Type of attribute: Media level only 536 Subject to charset: No 537 Purpose: See Section 4.1 538 Reference: 3GPP TS 26.234, Section 5.3.3.2 539 Values: See Reference 540 Attribute name: framesize 541 Long form: Maximum Video Frame Size 542 Type of name: att-field 543 Type of attribute: Media level only 544 Subject to charset: No 545 Purpose: See Section 4.2 546 Reference: 3GPP TS 26.234, Section 5.3.3.2 547 Values: See Reference 549 Attribute name: 3GPP-Integrity-Key 550 Long form: 3GPP DRM Integrity Key 551 Type of name: att-field 552 Type of attribute: Session level only 553 Subject to charset: No 554 Purpose: See Section 4.3 555 Reference: 3GPP TS 26.234, Sections 5.3.3.2 and K.2.2.1 556 Values: See Reference 558 Attribute name: 3GPP-SRTP-Config 559 Long form: 3GPP DRM SRTP Configuration 560 Type of name: att-field 561 Type of attribute: Media level only 562 Subject to charset: No 563 Purpose: See Section 4 564 .3 565 Reference: 3GPP TS 26.234, Sections 5.3.3.2 and K.2.2.2 566 Values: See Reference 568 Attribute name: 3GPP-SDP-Auth 569 Long form: 3GPP DRM Integrity SDP Authentication 570 Type of name: att-field 571 Type of attribute: Session level only 572 Subject to charset: No 573 Purpose: See Section 4.3 574 Reference: 3GPP TS 26.234, Sections 5.3.3.2 and K.2.2.3 575 Values: See Reference 577 Attribute name: alt 578 Long form: Alternative SDP line 579 Type of name: att-field 580 Type of attribute: Media level only 581 Subject to charset: No 582 Purpose: See Section 4 583 .4 584 Reference: 3GPP TS 26.234, Section 5.3.3.3 585 Values: See Reference 586 Attribute name: alt-default-id 587 Long form: Default alternative ID 588 Type of name: att-field 589 Type of attribute: Media level only 590 Subject to charset: No 591 Purpose: See Section 4.4 592 Reference: 3GPP TS 26.234, Section 5.3.3.3 593 Values: See Reference 595 Attribute name: alt-group 596 Long form: Grouping of SDP Line alternatives 597 Type of name: att-field 598 Type of attribute: Session level only 599 Subject to charset: No 600 Purpose: See Section 4.4 601 Reference: 3GPP TS 26.234, Section 5.3.3.4 602 Values: See Reference 604 Attribute name: 3GPP-Adaptation-Support 605 Long form: 3GPP Adaptation Support 606 Type of name: att-field 607 Type of attribute: Media level only 608 Subject to charset: No 609 Purpose: See Section 4.5 610 Reference: 3GPP TS 26.234, Section 5.3.3.5 611 Values: See Reference 613 Attribute name: 3GPP-QoE-Metrics 614 Long form: 3GPP Quality of Experience Metrics 615 Type of name: att-field 616 Type of attribute: Session and Media level 617 Subject to charset: No 618 Purpose: See Section 4 619 .6 620 Reference: 3GPP TS 26.234, Section 5.3.3.6 621 Values: See Reference 623 Attribute name: 3GPP-Asset-Information 624 Long form: 3GPP Asset Information 625 Type of name: att-field 626 Type of attribute: Session and Media level 627 Subject to charset: No 628 Purpose: See Section 4.7 629 Reference: 3GPP TS 26.234, Section 5.3.3.7 630 Values: See Reference 631 Attribute name: mbms-mode 632 Long form: MBMS Bearer Mode Declaration 633 Type of name: att-field 634 Type of attribute: Session and Media level 635 Subject to charset: No 636 Purpose: See Section 5.1 637 Reference: 3GPP TS 26.346, Section 7.3.2.7 638 Values: See Reference 640 Attribute name: mbms-flowid 641 Long form: FEC Flow ID 642 Type of name: att-field 643 Type of attribute: Media level 644 Subject to charset: No 645 Purpose: See Section 5.2 646 Reference: 3GPP TS 26.346, Section 8.3.1.9 647 Values: See Reference 649 Attribute name: mbms-repair 650 Long form: MBMS Repair 651 Type of name: att-field 652 Type of attribute: Session and Media level 653 Subject to charset: No 654 Purpose: See Section 5.3 655 Reference: 3GPP TS 26.346, Section 8.3.1.8 656 Values: See Reference 658 8.2. RTSP Registrations 660 IANA is requested to register the RTSP headers listed below in the 661 RTSP 1.0 registry table "RTSP/1.0 Headers" at: 663 http://www.iana.org/assignments/rtsp-parameters. 665 Note: This registry requires Standards document, preferably an IETF 666 RFC. The document that defines the registered headers below is a 667 technical standards document from 3GPP, although the request for 668 registration is submitted using this document to achieve further 669 information spreading within IETF. 671 The contact person for this registration is Magnus Westerlund 672 (magnus.westerlund@ericsson.com) Phone number +46 8 719 0000. 674 Header Name: 3GPP-Freshness-Token 675 Purpose: See Section K.2 of 3GPP TS 26.234 676 Methods: DESCRIBE Requests 677 Reference: Section K.2.2.4 of 3GPP TS 26.234 678 Values: See Reference 680 Header Name: 3GPP-Link-Char 681 Purpose: See Section 5.3.2.1 of 3GPP TS 26.234 682 Methods: SETUP, PLAY, OPTIONS or SET_PARAMETER Requests 683 Reference: Section 5.3.2.1 of 3GPP TS 26.234 684 Values: See Reference 686 Header Name: 3GPP-Adaptation 687 Purpose: See Section 5.3.2.2 of 3GPP TS 26.234 688 Methods: SETUP, PLAY, OPTIONS, or SET_PARAMETER Requests 689 and Responses 690 Reference: Section 5.3.2.2 of 3GPP TS 26.234 691 Values: See Reference 693 Header Name: 3GPP-QoE-Metrics 694 Purpose: See Section 5.3.2.3.1 of 3GPP TS 26.234 695 Methods: SETUP, PLAY, OPTIONS, or SET_PARAMETER Requests 696 and Responses 697 Reference: Section 5.3.2.3.1 of 3GPP TS 26.234 698 Values: See Reference 700 Header Name: 3GPP-QoE-Feedback 701 Purpose: See Section 5.3.2.3.2 of 3GPP TS 26.234 702 Methods: SET_PARAMETER, PAUSE, or TEARDOWN Requests 703 Reference: Section 5.3.2.3.2 of 3GPP TS 26.234 704 Values: See Reference 705 Header Name: x-predecbufsize 706 Purpose: See Section 5.3.2.4 of 3GPP TS 26.234 707 Methods: PLAY Response 708 Reference: Section 5.3.2.4 of 3GPP TS 26.234 709 Values: See Reference 711 Header Name: x-initpredecbufperiod 712 Purpose: See Section 5.3.2.4 of 3GPP TS 26.234 713 Methods: PLAY Response 714 Reference: Section 5.3.2.4 of 3GPP TS 26.234 715 Values: See Reference 717 Header Name: x-initpostdecbufperiod 718 Purpose: See Section 5.3.2.4 of 3GPP TS 26.234 719 Methods: PLAY Response 720 Reference: Section 5.3.2.4 of 3GPP TS 26.234 721 Values: See Reference 723 Header Name: 3gpp-videopostdecbufsize 724 Purpose: See Section 5.3.2.4 of 3GPP TS 26.234 725 Methods: PLAY Response 726 Reference: Section 5.3.2.4 of 3GPP TS 26.234 727 Values: See Reference 729 9. Security Considerations 731 SDP attributes are subject to modification by an attacker unless 732 they are integrity protected and authenticated. The security 733 consideration of the SDP specification [RFC4566] should be reviewed 734 in this regard. The registered SDP attributes are vulnerable to 735 modification attacks or removal, which may result in problems of 736 serious nature, including failure to use service and reduced 737 quality. 739 The registered RTSP headers are also vunerable to insertion, 740 deletion or modification attacks similar to SDP attributes. Also in 741 this case it can result in failure of the service or reduced quality 742 of streaming content. 744 The three SDP protocol indentifiers do not by themselves introduce 745 any additional security threats that don't exist for other protocol 746 identifiers in SDP. The media stream and the protocols identified by 747 the protocol identifier may however contain security issues by 748 themselves. 750 Normative References 752 [PSS-234] 3GPP TS 26.234, "Transparent end-to-end Packet-switched 753 Streaming Service (PSS); Protocols and codecs", version 754 6.11.0 (2007-06), 3rd Generation Partnership Project 755 (3GPP). 756 [PSS-3GP] 3GPP TS 26.244, "Transparent end-to-end packet switched 757 streaming service (PSS); 3GPP file format (3GP)", version 758 6.7.0 (2007-06), 3rd Generation Partnership Project 759 (3GPP). 760 [MBMS] 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service 761 (MBMS); Protocols and codecs", version 6.9.0 (2007-06), 762 3rd Generation Partnership Project (3GPP). 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 765 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 766 Video Conferences with Minimal Control", STD 65, RFC 3551, 767 July 2003. 768 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 769 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 770 RFC 3711, March 2004. 771 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 772 August 1980. 774 10. Informative References 776 [RFC2326] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 777 Protocol (RTSP)", RFC 2326, April 1998. 778 [PSS-233] 3GPP TS 26.233, "Transparent end-to-end packet switched 779 streaming service (PSS) General Description", version 780 6.0.0 (2004-09), 3rd Generation Partnership Project 781 (3GPP). 782 [RFC4566] M. Handley, V. Jacobson and C. Perkins, "SDP: Session 783 Description Protocol", RFC 4566, July 2006. 784 [RFC3264] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model 785 with the Session Description Protocol (SDP)", RFC 3264, 786 June 2002. 787 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 788 Encodings", RFC 4648, October 2006. 789 [AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, 790 http://www.nist.gov/aes/. 792 Any 3GPP document can be downloaded from the 3GPP webserver, 793 "http://www.3gpp.org/", see specifications. 795 11. Authors' Addresses 797 Magnus Westerlund 798 Ericsson Research 799 Ericsson AB 800 SE-164 80 Stockholm 801 SWEDEN 803 Phone: +46 8 7190000 804 EMail: Magnus.Westerlund@ericsson.com 806 Per Frojdh 807 Ericsson Research 808 Ericsson AB 809 SE-164 80 Stockholm 810 SWEDEN 812 Phone: +46 8 7190000 813 EMail: Per.Frojdh@ericsson.com 815 12. IPR Notice 817 The IETF takes no position regarding the validity or scope of any 818 Intellectual Property Rights or other rights that might be claimed 819 to pertain to the implementation or use of the technology described 820 in this document or the extent to which any license under such 821 rights might or might not be available; nor does it represent that 822 it has made any independent effort to identify any such rights. 823 Information on the procedures with respect to rights in RFC 824 documents can be found in BCP 78 and BCP 79. 826 Copies of IPR disclosures made to the IETF Secretariat and any 827 assurances of licenses to be made available, or the result of an 828 attempt made to obtain a general license or permission for the use 829 of such proprietary rights by implementers or users of this 830 specification can be obtained from the IETF on-line IPR repository 831 at http://www.ietf.org/ipr. 833 The IETF invites any interested party to bring to its attention any 834 copyrights, patents or patent applications, or other proprietary 835 rights that may cover technology that may be required to implement 836 this standard. Please address the information to the IETF at 837 ietf-ipr@ietf.org. 839 13. Copyright Notice 841 Copyright (C) The IETF Trust (2007). 843 This document is subject to the rights, licenses and restrictions 844 contained in BCP 78, and except as set forth therein, the authors 845 retain all their rights. 847 This document and the information contained herein are provided on 848 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 849 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 850 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 851 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 852 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 853 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 854 FOR A PARTICULAR PURPOSE. 856 This Internet-Draft expires in January 2008. 858 RFC Editor Considerations 860 Please replace any occurance of RFCXXXX with the RFC number this 861 document receives.