idnits 2.17.1 draft-even-mmusic-application-token-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2013) is 3954 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4575' is defined on line 451, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-10 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-msid-00 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-04 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-04) exists of draft-westerlund-avtcore-rtp-simulcast-02 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC WG R. Even 3 Internet-Draft Huawei Technologies 4 Intended status: Informational J. Lennox 5 Expires: December 30, 2013 Vidyo 6 Q. Wu 7 Huawei Technologies 8 June 28, 2013 10 The Session Description Protocol (SDP) Application Token Attribute 11 draft-even-mmusic-application-token-00.txt 13 Abstract 15 The RTP fixed header includes the payload type number and the SSRC 16 values of the RTP stream. RTP defines how you de-multiplex streams 17 within an RTP session, but in some use cases applications need 18 further identifiers in order to identify the application semantics 19 associated with particular streams within the session. 21 This document defines a mechanism to provide the mapping between the 22 SSRCs of RTP streams and the application semantics by defining 23 extensions to RTP and RTCP messages. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 30, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Proposal for an Application ID token . . . . . . . . . . . . 4 62 3.1. RTCP SDES message . . . . . . . . . . . . . . . . . . . . 6 63 3.2. RTP Header Extension . . . . . . . . . . . . . . . . . . 6 64 4. Using Application ID token . . . . . . . . . . . . . . . . . 7 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The RTP [RFC3550] header includes the payload type number and the 76 SSRC values of the RTP stream. RTP defines how you de-multiplex 77 streams within an RTP session, but in some use cases, applications 78 need further identifiers in order to identify semantics associated 79 with particular streams within the session. 81 There is ongoing work to define how to support, using SDP [RFC4566], 82 multiple RTP media streams in one or more m-lines that define a 83 single RTP session (as specified in [RFC3550]). The work is 84 addressing the WebRTC architecture [I-D.ietf-rtcweb-overview], and 85 some work will be needed when looking for a general solution in 86 MMUSIC that can be used for non-WebRTC systems. 88 RTCWEB Plan A [I-D.roach-rtcweb-plan-a] that an m-line in SDP 89 represents a single RTP stream. De-multiplexing is done by payload 90 type (PT) number (which MUST be unique), and if unique PTs are not 91 feasible, use SSRC information in the SDP to identify the RTP stream. 93 RTCWEB Plan B [I-D.uberti-rtcweb-plan] takes a different approach, 94 and creates a hierarchy within SDP; an m= line defines an "envelope", 95 specifying codec and transport parameters, and [RFC5576] a=ssrc lines 96 are used to describe individual media sources within that envelope. 98 Each m-line defines multiple RTP streams. This requires that the 99 SSRCs of all RTP streams in the session are declared before they 100 appear as RTP streams. 102 No plan [I-D.ivov-rtcweb-noplan] proposes using a single m-line for 103 each media type but does not require that all SSRCs will be declared 104 in the SDP. The de-multiplexing is done based on the unique PT 105 numbers and the mapping of SSRC to the application usage may be done 106 by application protocol. In web application, for example, the 107 application specific signaling may use something like { "leftSSRC": 108 "1234", "rightSSRC": "5678" }. 110 Some applications may require more information about the usage of the 111 RTP streams. For example, RTP streams from different cameras that 112 need to be identified by the application in order to render them 113 correctly, or a source that can send multiple versions of the same 114 stream in different resolutions (Simulcast 115 [I-D.westerlund-avtcore-rtp-simulcast]). 117 SDP provides in [RFC4574] a "label" attribute that contains a token 118 defined by an application and is used in its context. "Label" can be 119 attached to m-lines in multiple SDP documents allowing the 120 application to logically identify the media streams across SDP 121 sessions when necessary. The "label" attribute is a token and does 122 not provide any information about the content of the stream. 123 [RFC4796] defines the "content" attribute providing information about 124 the content of the stream, currently there is a small set of values 125 for the content attribute. 127 Both "label" and "content" attribute are SDP media-level attributes, 128 so when an SDP m-line supports multiple RTP streams, this value is 129 applicable to all sources described by the SDP m-line. 131 There is a need to have a token that will allow the mapping between a 132 single source (identified by an SSRC) in an m-line to the application 133 logic (Source may be a single RTP stream identified by a unique 134 SSRC). For example, SSRC1 is the RTP stream from the left camera and 135 SSRC2 is the RTP stream from the right camera both can be specified 136 in a single SDP m-line and may have the same PT number. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC2119[RFC2119] and 143 indicate requirement levels for compliant RTP implementations. 145 3. Proposal for an Application ID token 147 As we saw in the previous section, there are tokens defined that 148 could be used for the mapping, but they have existing usages and 149 semantics, and tend to apply at media-level rather than source-level. 150 In order to avoid overload of existing attributes, it is better to 151 have a new token attribute that can identify a specific source 152 corresponding to the application. This document defines such a new 153 token, called "AppID". 155 AppID is a general-purpose token associated with an RTP stream, 156 allowing the semantics of the stream with a token to be defined by 157 the application. This token may be mapped, for example, to a CLUE 158 media capture using CLUE protocol [I-D.ietf-clue-framework], or to a 159 specific resolution in a simulcast application described in the SDP . 161 The token is chosen by the sender, and represents the RTP stream that 162 will be sent to the receiver. 164 The proposed token can be sent using SDP, RTCP SDES messages 165 [RFC3550], or an RTP header extension [RFC5285] 167 The SSRC mapping may be available to the receiver when receiving the 168 RTP stream through the RTP header extension, but may also be 169 available ahead of time via an RTCP SDES message conveyed before the 170 source started sending, even if the receiver has not seen any RTP 171 packets from this source like in a multipoint conference or in the 172 SDP description. 174 The receiver can receive new sources that may be of two kinds. 176 o A new RTP stream replacing an existing RTP stream, in which case 177 the AppID of the replaced RTP stream will be assigned to the new 178 SSRC. 180 o A new RTP stream requiring a different AppID, for example, when 181 adding a presentation stream to an existing call with two video 182 cameras from a room. 184 The solution should support a RTP session as described using SDP. 185 The RTP session may be specified using a single SDP m-line, or using 186 Bundle [I-D.ietf-mmusic-sdp-bundle-negotiation], using more than one 187 m-line. In the latter case, if the SSRCs of all RTP streams are not 188 known in advance, the AppIDs associated with each m-line need to be 189 available to the receiver in order to map each SSRC to a specific 190 m-line configuration. 192 To support these cases the document defines a new SDP media level 193 attribute a=appID that can be used to list all the appIDs that an 194 application may use. 196 The appID syntax provides a token identifier and optional SDP 197 attributes that describe the application usage if exists in SDP. 198 Application usage in SDP may be, for example, an image attribute 199 describing a simulcast application usage 200 [I-D.westerlund-avtcore-rtp-simulcast]. 202 Each value of the AppID maps to one SSRC at a time. When a new SSRC 203 is mapped to an existing AppID using an RTP header extension or SDES 204 message, it replaces the previous RTP stream for this application 205 usage. 207 The formal representation of the appID token is: 209 appid-attribute = "appID:" tokenlist [SP attribute] 211 tokenlist = token *("," token) 213 ; The base definition of "attribute" is in [RFC4566]. 215 ; (It is the content of "a=" lines.) 217 Examples: 219 The SSRCs of the streams are not known when the SDP offer is sent, 220 two appID are specified and can be used for mapping to specific SSRCs 221 in the application. 223 m=video 49200 RTP/AVP 99 225 a=rtpmap:99 H264/90000 227 a=appID:2,3 229 The second example is when the application usage of the RTP steam is 230 specified using SDP to provide different image resolutions. 232 m=video 49200 RTP/AVP 98, 99 234 a=rtpmap:98 H264/90000 236 a=rtpmap:99 H264/90000 238 a=appID:2 imageattr:98 send [x=480,y=320] recv * 239 a=appID:3 imageattr:99 send [x=800,y=640] recv * 241 3.1. RTCP SDES message 243 The document specify a new RTCP SDES message 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | AppID = XXX | length |AppID token 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | .... 252 This AppID is the same token as defined in the new SDP attribute and 253 will also be used in the RTP header extension. 255 This SDES message MAY be sent in a compound RTCP packet based on the 256 application need. 258 3.2. RTP Header Extension 260 The Application ID could be carried within the RTP header extension 261 field, using [RFC5285] two bytes header extension. 263 This is negotiated within the SDP i.e. 265 a=extmap:1 urn:ietf:params:rtp-hdrext:App-ID 267 Packets tagged by the sender with the AppID will then contain a 268 header extension as shown below 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | ID=1 | Len-1 | AppID 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | AppID .............. | 276 +-+-+-+-+-+-+-+-+ 278 To add or modify the AppID by an intermediary can be an expensive 279 operation, particularly if SRTP is used to authenticate the packet. 280 Modification to the contents of the RTP header requires a re- 281 authentication of the complete packet, and this could prove to be a 282 limiting factor in the throughput of a multipoint device. 284 There is no need to send the AppID header extension with all RTP 285 packets. Senders MAY choose to send it only when a new SSRC is sent, 286 or when an SSRC changes its association to an AppID. If such a mode 287 is being used, the header extension SHOULD be sent in the first few 288 RTP packets to reduce the risk of losing it due to packet loss. For 289 codecs with decoder refresh points (such as I-Frames in video 290 codecs), senders also SHOULD send the AppID header extension along 291 with the packets carrying the decoder refresh. 293 4. Using Application ID token 295 The usage of mapping may depend on the de-multiplexing of the RTP 296 streams in the SDP m-lines. Currently we have three options 297 discussed based on input from the RTCweb WG. 299 For plan A [I-D.roach-rtcweb-plan-a], since each RTP stream is 300 described by a specific m-line it will be enough to have a media 301 level token for mapping the sent stream. 303 Only need for example: 305 m=video 49200 RTP/AVP 99 307 a=rtpmap:99 H264/90000 309 a=appID 2 311 For plan B [I-D.uberti-rtcweb-plan] which adds another level of RTP 312 stream description, the mapping of SSRC to the application will need 313 to be at the SSRC level base on [RFC5576] since all SSRCs are 314 specified in the m-line. The document addresses the mapping of SSRCs 315 using the SSRC attribute but uses the msid [I-D.ietf-mmusic-msid] 316 that defines a specific semantics for each SSRC. The following offer 317 example is using RFC5576 to provide source specific attribute 318 identifier. 320 m=video 49200 RTP/AVP 322 a=rtpmap:99 H264/90000 324 a=max-send-ssrc:{*:3} 326 a=max-recv-ssrc:{*:3} 328 a=ssrc:11111 AppID:1 330 a=ssrc:22222 AppID:2 331 a=ssrc:33333 AppID:3 333 When using noplan [I-D.ivov-rtcweb-noplan] in MMUSIC, not all SSRCs 334 will be known ahead of time. For example, in the following SDP the 335 offer offers either two streams with the same resolution (for example 336 two cameras) or two streams with different resolutions. 338 m=video 5002 RTP/SAVPF 98 340 a=rtpmap:98 H264/90000 342 a= appID 1,2 imageattr:98 send [x=800,y=640,sar=1.1,q=0.6] recv * 344 a= appID 3,4 imageattr:98 send [x=480,y=320] recv * 346 a=max-send-ssrc:{*:2} 348 In the CLUE WG case the mapping is from an RTP stream to a CLUE media 349 capture specified in the CLUE framework [I-D.ietf-clue-framework]. 350 The SSRCs of all streams may be known like in PLAN B but there are 351 cases where the SDP may not be available so a pre-announce is 352 recommended like in the following example. 354 m=video 49200 RTP/AVP 356 a=rtpmap:99 H264/90000 358 a=max-send-ssrc:{*:5} 360 a=max-recv-ssrc:{*:3} 362 a=ssrc:11111 AppID:1 364 a=ssrc:22222 AppID:2 366 a=ssrc:33333 AppID:3 368 a=appID 4, 5 370 The pre-announce is needed since the new RTCP SDES message includes 371 only the SSRC and the appID but not the PT. A receiver of the SDES 372 message will be able to map the SSRC to a codec configuration based 373 on the SDP pre-announced tokens. 375 5. Acknowledgements 377 Place Holder 379 6. IANA Considerations 381 TBD 383 7. Security Considerations 385 TBD. 387 8. References 389 8.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 395 Jacobson, "RTP: A Transport Protocol for Real-Time 396 Applications", STD 64, RFC 3550, July 2003. 398 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 399 Header Extensions", RFC 5285, July 2008. 401 8.2. Informative References 403 [I-D.ietf-clue-framework] 404 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 405 for Telepresence Multi-Streams", draft-ietf-clue- 406 framework-10 (work in progress), May 2013. 408 [I-D.ietf-mmusic-msid] 409 Alvestrand, H., "Cross Session Stream Identification in 410 the Session Description Protocol", draft-ietf-mmusic- 411 msid-00 (work in progress), February 2013. 413 [I-D.ietf-mmusic-sdp-bundle-negotiation] 414 Holmberg, C., Alvestrand, H., and C. Jennings, 415 "Multiplexing Negotiation Using Session Description 416 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 417 bundle-negotiation-04 (work in progress), June 2013. 419 [I-D.ietf-rtcweb-overview] 420 Alvestrand, H., "Overview: Real Time Protocols for Brower- 421 based Applications", draft-ietf-rtcweb-overview-06 (work 422 in progress), February 2013. 424 [I-D.ivov-rtcweb-noplan] 425 Ivov, E., Marocco, E., and P. Thatcher, "No Plan: 426 Economical Use of the Offer/Answer Model in WebRTC 427 Sessions with Multiple Media Sources", draft-ivov-rtcweb- 428 noplan-01 (work in progress), June 2013. 430 [I-D.roach-rtcweb-plan-a] 431 Roach, A. and M. Thomson, "Using SDP with Large Numbers of 432 Media Flows", draft-roach-rtcweb-plan-a-00 (work in 433 progress), May 2013. 435 [I-D.uberti-rtcweb-plan] 436 Uberti, J., "Plan B: a proposal for signaling multiple 437 media sources in WebRTC.", draft-uberti-rtcweb-plan-00 438 (work in progress), May 2013. 440 [I-D.westerlund-avtcore-rtp-simulcast] 441 Westerlund, M., Lindqvist, M., and F. Jansson, "Using 442 Simulcast in RTP Sessions", draft-westerlund-avtcore-rtp- 443 simulcast-02 (work in progress), February 2013. 445 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 446 Description Protocol", RFC 4566, July 2006. 448 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 449 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 451 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 452 Initiation Protocol (SIP) Event Package for Conference 453 State", RFC 4575, August 2006. 455 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 456 Protocol (SDP) Content Attribute", RFC 4796, February 457 2007. 459 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 460 Media Attributes in the Session Description Protocol 461 (SDP)", RFC 5576, June 2009. 463 Authors' Addresses 465 Roni Even 466 Huawei Technologies 467 Tel Aviv 468 Israel 470 Email: roni.even@mail01.huawei.com 471 Jonathan Lennox 472 Vidyo, Inc. 473 433 Hackensack Avenue 474 Seventh Floor 475 Hackensack, NJ 07601 476 US 478 Email: jonathan@vidyo.com 480 Qin Wu 481 Huawei Technologies 483 Email: bill.wu@huawei.com