idnits 2.17.1 draft-westerlund-avtcore-max-ssrc-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4273 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) == Outdated reference: A later version (-05) exists of draft-westerlund-avtext-rtp-stream-pause-02 -- 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft B. Burman 4 Intended status: Standards Track F. Jansson 5 Expires: January 17, 2013 Ericsson 6 July 16, 2012 8 Multiple Synchronization sources (SSRC) in RTP Session Signaling 9 draft-westerlund-avtcore-max-ssrc-02 11 Abstract 13 RTP has always been a protocol that supports multiple participants 14 each sending their own media streams in an RTP session. 15 Unfortunately, many implementations are designed only for point to 16 point voice over IP with a single source in each end-point. Even 17 client implementations aimed at video conferences have often been 18 built with the assumption around central mixers that only deliver a 19 single media stream per media type. Thus any application that wants 20 to allow for more advanced usage, where multiple media streams are 21 sent and received by an end-point, has an issue with legacy 22 implementations. This document describes the problem and proposes a 23 signalling solution for how to use multiple SSRCs within one RTP 24 session and at the same time handle the legacy issues. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 17, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Multiple Streams Issues . . . . . . . . . . . . . . . . . . . 5 66 3.1. Legacy Behaviors . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Receiver Limitations . . . . . . . . . . . . . . . . . . . 7 68 3.3. Transmission Declarations . . . . . . . . . . . . . . . . 7 69 4. Multiple Streams SDP Extension . . . . . . . . . . . . . . . . 8 70 4.1. Signaling Support for Multiple Streams . . . . . . . . . . 8 71 4.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. Use in Offer/Answer . . . . . . . . . . . . . . . . . . . 10 73 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document discusses the issues of non basic usage of RTP 84 [RFC3550] where there is multiple media sources sent over an RTP 85 session using the SSRC source identifier to distinguish between the 86 sources. This include multiple sources from the same end-point, 87 multiple end-points each having a source, or an application that 88 sends or receive multiple encodings of a particular media source 89 using multiple SSRCs. 91 1.1. Background 93 RTP sessions are a concept which most fundamental part is an SSRC 94 space. This space can encompass a number of network nodes and 95 interconnected transport flows between these nodes. Each node may 96 have zero, one or more source identifiers (SSRCs) used to either 97 identify a real media source such as a camera or a microphone, a 98 conceptual source (like the most active speaker selected by an RTP 99 mixer that switches between incoming media streams based on the media 100 stream or additional information), or simply as an identifier for a 101 receiver that provides feedback and reports on reception. There are 102 also RTP nodes, like translators that are manipulating data, 103 transport or session state without making their presence aware to the 104 other session participants. 106 RTP was designed to support multiple participants in a session from 107 the beginning. This was not restricted to multicast as many believe 108 but also unicast using either multiple transport flows below RTP or a 109 network node that redistributes the RTP packets, either unchanged in 110 the form of a transport translator (relay) or modified in an RTP 111 mixer. There is also the case where a single end-point have multiple 112 media sources, like multiple cameras or microphones. 114 However, the most common use cases for RTP have been point to point 115 Voice over IP (VoIP) or streaming applications where there have 116 commonly not been more than one media source per end-point. Even in 117 conferencing applications, especially voice only, the conference 118 focus or bridge have provided a single stream being a mix of the 119 other participants to each participant. Thus there has been little 120 need for handling multiple SSRCs in implementations. This has 121 resulted in an installed legacy base that is not fully RTP 122 specification compliant and will have different issues if they 123 receive multiple SSRCs of media, either simultaneously or in 124 sequence. These issues will manifest themselves in various ways, 125 either by software crashes, or simply in limited functionality, like 126 only decoding and playing back the first or latest SSRC received and 127 discarding any other SSRCs. 129 The signaling solutions around RTP, especially the SDP [RFC4566] 130 based, have not considered the fundamental issues around an RTP 131 session's theoretical support of up to 4 billion plus sources all 132 sending media. No end-point has infinite processing resources to 133 decode and mix any number of media sources. In addition the memory 134 for storing related state, especially decoder state is limited, and 135 the network bandwidth to receive multiple streams is also limited. 136 Today, the most likely limitations are processing and network 137 bandwidth although for some use cases memory or other limitations may 138 also exist. The issue is that a given end-point will have some 139 limitations in the number of streams it simultaneously can receive, 140 decode and playback. These limitations need to be possible to expose 141 and enabling the session participants to take them into account. 143 In similar ways there is a need for an end-point to express if it 144 intends to produce one or more media streams in an RTP session. 145 Todays SDP signaling support for this is basically the directionality 146 attribute which indicates an end-point intent to send media or not. 147 There is however no way to indicate how many media streams will be 148 sent. 150 Taking these things together there exist a clear need to enable the 151 usage of multiple simultaneous media streams within an RTP session in 152 a way that allows a system to take legacy implementations into 153 account in addition to negotiate the actual capabilities around the 154 multiple streams in an RTP session. 156 2. Definitions 158 2.1. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 2.2. Terminology 166 The following terms and abbreviations are used in this document: 168 Encoding: A particular encoding is the choice of the media encoder 169 (codec) that has been used to compress the media, the fidelity of 170 that encoding through the choice of sampling, bit-rate and other 171 configuration parameters. 173 Different encodings: An encoding is different when some parameter 174 that characterize the encoding of a particular media source has 175 been changed. Such changes can be one or more of the following 176 parameters; codec, codec configuration, bit-rate, sampling. 178 3. Multiple Streams Issues 180 This section attempts to go a bit more in depth around the different 181 issues when using multiple media streams in an RTP session to make it 182 clear that although in theory multi-stream applications should 183 already be possible to use, there are good reasons to create 184 extensions for signaling. In addition, the RTP specification could 185 benefit from clarifications on how certain mechanisms should be 186 working when an RTP session contains more than two SSRCs. 188 3.1. Legacy Behaviors 190 It is a common assumption among many applications using RTP that they 191 do not have a need to support more than one incoming and one outgoing 192 media stream per RTP session. For a number of applications this 193 assumption has been correct. For VoIP and Streaming applications it 194 has been easiest to ensure that a given end-point only receives 195 and/or sends a single stream. However, all end-points should support 196 a source changing SSRC value during a session, e.g due to SSRC value 197 collision between participants in a conference and the requirement to 198 always use unique SSRC values. 200 Some RTP extension mechanisms require the RTP stacks to handle 201 additional SSRCs, like SSRC multiplexed RTP retransmission described 202 in [RFC4588]. However, that still has only required handling a 203 single media decoding chain. 205 There are however applications that clearly can benefit from 206 receiving and using multiple media streams simultaneously. A very 207 basic case would be T.140 conversational text, where the text 208 characters are transmitted as a real-time media stream as you type. 209 When used in a multi-party chat scenario, an end-point can receive 210 input from multiple sending end-points where the T.140 RTP Payload 211 Format [RFC4103] text media is both low bandwidth and where there is 212 no obvious method to algorithmically distinguish between multiple 213 sources of text, making simple multiplex and identification of 214 separate sources through an identifier (SSRC) a good choice. 216 An RTP session that contains an end-point with more than two SSRCs 217 actively sending media streams puts some requirements on the 218 receiving client, which is not necessarily fulfilled by a legacy 219 client: 221 1. The receiving client needs to handle receiving more than one 222 stream simultaneously rather than replacing the already existing 223 stream with the new one. 225 2. Be capable of decoding multiple streams simultaneously. 227 3. Be capable of rendering multiple streams simultaneously. 229 An application using multiple streams may be very similar to existing 230 one media stream applications at signaling level. To avoid 231 connecting two different implementations, one that is built to 232 support multiple streams and one that is not, it is important that 233 the capabilities are signaled. This also enables a particular 234 application to separate legacy clients that do not signal it 235 explicitly from the ones that do, and take appropriate measures for 236 the legacy application. Due to that there exist both legacy 237 applications that only handle a single stream and applications that 238 handle multiple streams, a single authoritative interpretation cannot 239 be defined by this specification. 241 There exist many models for legacy behaviors when it comes to 242 handling multiple SSRCs. This briefly describes some of the more 243 common ones: 245 Single SSRC per Direction: As previously discussed there exist a 246 large number of applications where each end-point has only a 247 single SSRC and the number of end-points in the RTP session are 248 only two. This class of applications needs to have a legacy 249 fallback behavior that provide only a single SSRC, or issues will 250 likely occur. 252 Multiple SSRCs per Direction Single Media Stream: There exist some 253 applications that uses multiple concurrent SSRCs but in the end 254 only consumes a single media stream. This include the streaming 255 applications using RTP retransmission with SSRC multiplexing, but 256 also applications switching between sources although only 257 consuming one at a time. When an offer or answer without the 258 signalling extension is received, the end-point can potentially 259 determine this by inspecting payload types in use and correctly 260 determine the legacy behavior. In some cases it must be 261 determined through application context or SDP external signaling 262 indications. 264 Multi-Party Each Using Multiple SSRCs: Multicast applications 265 commonly have multiple SSRCs, if for no other reason than the 266 existence of multiple end-points in the same RTP session. Similar 267 considerations exist in multi-party applications that uses central 268 nodes. There may be no indications in the SDP regarding how the 269 application will handle multiple concurrent SSRCs and the 270 expectancy to decode these. Thus also this legacy behavior must 271 commonly be determined from the application context and external 272 signaling. 274 3.2. Receiver Limitations 276 An RTP end-point that intends to process the media in an RTP session 277 needs to have sufficient resources to receive and process all the 278 incoming streams. It is extremely likely that no receiver is capable 279 to handle the theoretical upper limit of more than 4 billion media 280 sources in an RTP session. Instead, one or more properties will 281 limit the end-points' capabilities to handle simultaneous media 282 streams. These properties are for example memory, processing, 283 network bandwidth, memory bandwidth, or rendering estate to mention a 284 few possible limitations. Those limits in number of simultaneous 285 streams may also differ depending on what codec (payload type) that 286 is used. 288 We have also considered the issue of how many simultaneous non-active 289 sources an end-point can handle. We cannot see that inactive media 290 sending SSRCs result in significant resource consumption and there 291 should thus be no need to limit them. 293 A potential issue that needs to be acknowledged is where a limited 294 set of simultaneously active sources varies within a larger set of 295 session members. As each media decoding chain may contain state, it 296 is important that a receiver can flush a decoding state for an 297 inactive source and if that source becomes active again it does not 298 assume that this previous state exists. Thus, we see need for a 299 signaling solution that allows a receiver to indicate its upper limit 300 in terms of capability to handle simultaneous media streams. We see 301 little need for an upper limitation of RTP session members. 302 Applications will need to account for its own capability to use 303 different codecs simultaneously when choosing general and payload 304 specific limits. 306 3.3. Transmission Declarations 308 In an RTP based system where an end-point may either be legacy or has 309 an explicit upper limit in the number of simultaneous streams, one 310 will encounter situations where the end-point can not receive and 311 process all simultaneous active streams in the session. Instead, the 312 sending end-points or central nodes, like RTP mixers, will have to 313 provide the end-point with a selected set of streams based on various 314 metrics, such as most active, most interesting, or user selected. In 315 addition, the central node may combine multiple media streams using 316 mixing or composition into a new media stream to enable an end-point 317 to get sufficient source coverage in the session, despite existing 318 limitations. 320 For such a system to be able to correctly determine the need for 321 central processing, the capabilities needed for such a central 322 processing node, and the potential need for an end-point to do sender 323 side limitations, it is necessary for an end-point to declare how 324 many simultaneous streams it may send. Thus, enabling negotiation of 325 the number of streams an end-point sends. The limit in number of 326 simultaneous streams may also differ depending on what codec (payload 327 type) that is used. 329 4. Multiple Streams SDP Extension 331 This section describes an extension of the media-level SDP attributes 332 to support signaling of the end point's multiple stream capabilities. 334 4.1. Signaling Support for Multiple Streams 336 A solution to the issues described in the previous section needs to: 338 o Enable signaling between the RTP sender and receiver how many 339 simultaneous RTP streams that can be handled, including a 340 possibility to specify a different number of streams depending on 341 what codec (payload type) that is used. 343 o Be able to handle the case where the number of RTP streams that 344 can be sent from a client do not match the number of streams that 345 can be received by the same client. 347 It is also a requirement that a multiple streams capable RTP sender 348 MUST be able to adapt the number of sent streams to the RTP receiver 349 capability. 351 For this purpose and for use in SDP, two new media-level SDP 352 attributes are defined, max-send-ssrc and max-recv-ssrc, which can be 353 used independently to establish a limit to the number of 354 simultaneously active SSRCs for the send and receive directions, 355 respectively. Active SSRCs are the ones counted as senders according 356 to [RFC3550], i.e. they have sent RTP packets during the last two 357 regular RTCP reporting intervals. Alternatively, if the end-points 358 supports PAUSE and RESUME signaling 359 [I-D.westerlund-avtext-rtp-stream-pause], any stream that the media 360 sender sent a PAUSED indication for can be regarded as non-Active and 361 can immediately be replaced by another SSRC, considering the limits 362 established by this specification, including possible changes in the 363 applicable limit required by a change of codec. 365 The syntax for the attributes is in ABNF [RFC5234]: 367 max-ssrc = "a="( "max-send-ssrc:" / "max-recv-ssrc:" ) alt-list 368 alt-list = alt-set *(WSP alt-set) 369 alt-set = "{" alt *("&" alt)) "}" 370 alt = pt ":" limit 371 pt = ( pt-list / pt-wildcard ) 372 pt-list = ( pt-value / pt-range ) *(","( pt-value / pt-range )) 373 pt-value = 1*3DIGIT 374 pt-range = pt-value "-" pt-value 375 pt-wildcard = "*" 376 limit = 1*8DIGIT 377 ; WSP and DIGIT defined in [RFC5234] 379 A Payload Type (PT)-agnostic upper limit to the total number of 380 simultaneous SSRCs that can be sent or received in this RTP session 381 is signaled with a "*" instead of the PT number. A value of 0 MAY be 382 used as maximum number of SSRC, but it is then RECOMMENDED that this 383 is also reflected using the sendonly or recvonly attribute. 385 A PT-specific upper limit to the total number of simultaneous SSRCs 386 in the RTP session with that specific PT is signaled with a defined 387 PT (static, or dynamic through rtpmap). Multiple, alternative sets 388 of PT and limit MAY be specified on the same line, where each set 389 indicates the codec-dependent limit when a certain PT is used. A 390 combination of a comma-separated list of PT and a range of PT sharing 391 a single limit MAY be used. Within the alternative set, there MAY be 392 a specification of limits valid when different PT are used 393 simultaneously. Any PT-agnostic specification on a line MUST be 394 interpreted as valid for any PT that was not included within an 395 explicit limit within that alternative set. Multiple lines with max- 396 send-ssrc or max-recv-ssrc attributes specifying a single PT MAY be 397 used, but MUST NOT contain conflicting limits. PT values that are 398 not defined in the media block MUST be ignored. 400 When max-send-ssrc or max-recv-ssrc are not included in the SDP, it 401 is to be interpreted in the application's context. The default 402 number of allowed SSRCs can vary depending on the type of 403 application. 405 4.2. Declarative Use 407 When used as a declarative media description, the specified limit in 408 max-send-ssrc indicates the maximum number of simultaneous streams of 409 the specified payload types that the configured end-point may send at 410 any single point in time. Similarly, max-recv-ssrc indicates the 411 maximum number of simultaneous streams of the specified payload types 412 that may be sent to the configured end-point. Payload-agnostic 413 limits MAY be used with or without additional payload-specific 414 limits. 416 4.3. Use in Offer/Answer 418 When used in an offer [RFC3264], the specified limits indicate the 419 agent's intent of sending and/or capability of receiving that number 420 of simultaneous SSRCs. An offerer supporting this specification MUST 421 include both attributes for sendrecv media streams, even if one or 422 both has a value of 1. For sendonly or recvonly m= blocks, the one 423 matching the Offer/Answer agent's role MUST be included when using 424 this extension, and the other directionality MAY be included for 425 informational purpose, if bi-directionality can potentially be used 426 in the future for this m= block. The answerer MUST reverse the 427 directionality of recognized attributes such that max-send-ssrc 428 becomes max-recv-ssrc and vice versa. The answerer SHOULD modify the 429 offered limits in the answer to suit the answering client's 430 capability and intentions. A sender MUST NOT send more simultaneous 431 streams of the specified payload type(s) than the receiver has 432 indicated ability to receive, taking into account also any payload 433 type-agnostic limit. 435 In case an answer fails to include any of the limitation attributes, 436 the agent is RECOMMENDED to have defined a suitable interpretation 437 for the application context. This may be the choice of being capable 438 of supporting only a single stream (SSRC) in the direction for which 439 attributes are missing. It may also indicate multiple SSRC support 440 depending on the application. In case the offer lacks both max-send- 441 ssrc and max-recv-ssrc, they MUST NOT be included in the answer. 443 4.4. Examples 445 The SDP examples below are not complete. Only relevant parts have 446 been included, for brevity and readability. 448 m=video 49200 RTP/AVP 99 449 a=rtpmap:99 H264/90000 450 a=max-send-ssrc:{*:2} 451 a=max-recv-ssrc:{*:4} 453 An offer with a stated intention of sending 2 simultaneous SSRCs and 454 a capability to receive 4 simultaneous SSRCs. 456 m=video 50324 RTP/AVP 96 97 457 a=rtpmap:96 H264/90000 458 a=rtpmap:97 H263-2000/90000 459 a=max-recv-ssrc:{96:2&97:3} {96:1&97:4} {97:5} 460 a=max-send-ssrc:{* 1} 462 An offer to receive at most 5 SSRCs, at most 2 of which using payload 463 type 96 and the rest using payload type 97. The "max- send-ssrc" is 464 used to explicitly indicate the value of 1. 466 m=video 50324 RTP/AVP 96 97 98 467 a=rtpmap:96 H264/90000 468 a=rtpmap:97 H263-2000/90000 469 a=rtpmap:98 H263/90000 470 a=max-recv-ssrc:{96:2&97:3} {96-97:2&98:1} {96,98:2&97:1} 471 a=max-recv-ssrc:{96,98:1&97:3} {96:1&97-98:2} {96-97:1&98:3} 472 a=max-recv-ssrc:{96:1&98:4} {97:3&98:2} {97:2&98:3} {97:1&98:4} 473 a=max-recv-ssrc:{98:5} 474 a=max-send-ssrc:{* 1} 476 An offer to receive at most 5 SSRCs, at most 2 of which using payload 477 type 96, at most 3 of which using payload type 97, and at most 5 478 using payload type 98. Since there are many combinations, more than 479 one "max-recv-ssrc" line is used, which is OK since no specifications 480 on those lines are in conflict. 482 5. IANA Considerations 484 This document registers two media level SDP attributes. 486 6. Security Considerations 488 The SDP attributes defined in this document "a=max-recv-ssrc" and 489 "a=max-send-ssrc" signals capabilities of the end-point. Thus they 490 are vulnerable to attacks. The primary security concerns would be 491 with third parties that modifies the values of the attributes or 492 inserts the attributes in a signalling context. Thus changing the 493 peers view of the others peers capabilities and proposals. A 494 modification reducing either of send or receive values will degrade 495 the service, potentially preventing the service all together. 496 Increasing the value or inserting the attribute with a value 497 different from 1 have the potential of being even more effective. It 498 can result in that an end-point that only supports a single stream 499 will be sent multiple streams. First of all, this potentially 500 exposes software flaws regarding handling of multiple streams, thus 501 causing crashes, less severe it can cause media degradation as the 502 receiving entity flaps between media streams, or plays only a single 503 one, where the other side assumes both will be played. In addition, 504 negotiation of several streams has transport impact, potentially 505 increasing the bit-rate consumed towards the end-point, and in 506 addition forcing an adaptation response over a limited path, thus 507 degrading the media stream the end-point may play out. 509 To prevent third party manipulation of the SDP, it should be source 510 authenticated and integrity protected. The solution suitable for 511 this depends on the signalling protocol being used. For SIP S/MIME 512 [RFC3261] is the ideal, and hop by hop TLS provides at least some 513 protection, although not perfect. For SDPs retrieved using RTSP 514 DESCRIBE [RFC2326], TLS would be the RECOMMENDED solution. 516 7. References 518 7.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 524 Jacobson, "RTP: A Transport Protocol for Real-Time 525 Applications", STD 64, RFC 3550, July 2003. 527 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 528 Specifications: ABNF", STD 68, RFC 5234, January 2008. 530 7.2. Informative References 532 [I-D.westerlund-avtext-rtp-stream-pause] 533 Akram, A., Burman, B., Grondal, D., and M. Westerlund, 534 "RTP Media Stream Pause and Resume", 535 draft-westerlund-avtext-rtp-stream-pause-02 (work in 536 progress), July 2012. 538 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 539 Streaming Protocol (RTSP)", RFC 2326, April 1998. 541 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 542 A., Peterson, J., Sparks, R., Handley, M., and E. 543 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 544 June 2002. 546 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 547 with Session Description Protocol (SDP)", RFC 3264, 548 June 2002. 550 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 551 Conversation", RFC 4103, June 2005. 553 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 554 Description Protocol", RFC 4566, July 2006. 556 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 557 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 558 July 2006. 560 Authors' Addresses 562 Magnus Westerlund 563 Ericsson 564 Farogatan 6 565 SE-164 80 Kista 566 Sweden 568 Phone: +46 10 714 82 87 569 Email: magnus.westerlund@ericsson.com 571 Bo Burman 572 Ericsson 573 Farogatan 6 574 SE-164 80 Kista 575 Sweden 577 Phone: +46 10 714 13 11 578 Email: bo.burman@ericsson.com 580 Fredrik Jansson 581 Ericsson 582 Farogatan 6 583 Kista, SE-164 80 584 Sweden 586 Phone: +46 10 719 00 00 587 Fax: 588 Email: fredrik.k.jansson@ericsson.com 589 URI: