idnits 2.17.1 draft-wenger-clue-transport-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 (March 12, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3311' is defined on line 552, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-cazeaux-clue-sip-signaling-00 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-00 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-03 == Outdated reference: A later version (-02) exists of draft-romanow-clue-sdp-usage-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Wenger 3 Internet-Draft Vidyo 4 Intended status: Standards Track M. Eubanks 5 Expires: September 13, 2012 AmericaFree.TV 6 R. Even 7 Huawei 8 G. Camarillo 9 Ericsson 10 March 12, 2012 12 Transport Options for Clue 13 draft-wenger-clue-transport-02 15 Abstract 17 This memo describes the assumption and the proposed options for the 18 coding and transport of CLUE messages as outlined in version 01 of 19 the framework draft. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 13, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Transport for CLUE messages . . . . . . . . . . . . . . . . . 5 64 3.1. Option 1 : Piggy-pack on SIP . . . . . . . . . . . . . . . 6 65 3.1.1. Option 1.1: Using SDP (in an offer-answer context) 66 for CLUE information . . . . . . . . . . . . . . . . . 6 67 3.1.2. Option 1.2: Using an SDP MIME body to carry the 68 CLUE information in an INVITE or UPDATE exchange . . . 7 69 3.1.3. Option 1.3: Using a SIP INFO package . . . . . . . . . 7 70 3.1.4. Option 1.4: SIP signaling options . . . . . . . . . . 7 71 3.2. Option 2: CLUE control channel on the media plane over 72 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.3. Option 3: Other Work . . . . . . . . . . . . . . . . . . . 8 74 4. Content Representation . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Option 1 : SDP . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2. Option 2 : XML . . . . . . . . . . . . . . . . . . . . . . 10 77 4.3. Option 3 : ASN.1 . . . . . . . . . . . . . . . . . . . . . 10 78 4.4. Option 4 : Clue Defined Format . . . . . . . . . . . . . . 10 79 4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.6. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5. Clue Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.1. Option 1 : CLUE discovery as a side effect of opening 83 a CLUE control channel . . . . . . . . . . . . . . . . . . 11 84 5.2. Option 2 : SIP Message Transport . . . . . . . . . . . . . 11 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 88 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 The CLUE WG is chartered to design a protocol to enable communication 94 about media streams for videoconferencing and telepresence working in 95 conjunction with the IETFOs protocol suites of choice, namely SIP for 96 basic call setup and control and RTP for media transport. (It should 97 be noted that ITU-T Q.xx/16 has informally expressed a desire that 98 parts or all of the work of the CLUE WG can be re-used in an H.323 99 environment. Therefore, occasionally, we comment on the re-use of 100 CLUE work outside of SIP systems. This does not mean that we want to 101 extent the charter; however, it seems sensible at least to us that if 102 a cross protocol solution and a SIP-only solution to the CLUE problem 103 could be devised, and both solutions are comparable in in their 104 complexity etc etc, a solution with applicability beyond SIP may be 105 the appropriate choice.) 107 This document describes options for the coding and transport of CLUE 108 messages in a SIP / RTP environment. Specifically, three issues are 109 addressed. 111 First, while the framework draft conceptually describes message 112 flows, it does not specify how those messages are actually 113 transferred "on the wire" and how they relate to the SIP offer/answer 114 [RFC3264]. This document lists (hopefully all) the options that have 115 been proposed in CLUE to date. 117 Second, the framework-01 draft describes three messages between the 118 producer and the consumer in an abstract form, without specifying the 119 details of the representation of those messages. This memo lists 120 (some of) the options for the representation of the abstract messages 121 of the framework draft. 123 Third, before any CLUE messages can be meaningfully exchanged, it is 124 necessary to discover whether the involved systems are actually CLUE- 125 capable. This memo discusses the proposed options for CLUE 126 capability discovery. 128 In this memo we only present the options discussed to date in the 129 working group. Deciding on the appropriate mechanism (or mechanisms, 130 as it is not always appropriate to have a single solution for a given 131 problem, though this is of course desirable from an interoperability 132 viewpoint) is left for further discussion in the working group. That 133 does not mean that the authors do not have preferences, and/or 134 specific knowledge of certain mechanisms, and may as a result go in 135 greater depth in describing one mechanism than another. 137 2. Assumptions 139 The Basic Clue data model is specified in the framework document. 140 The framework defines three messages that carry the Clue data: 142 Consumer Capability Message 144 Provider Capabilities Announcement 146 Consumer Configure Request 148 (There is no clear consensus that the Consumer Capability Message is 149 needed, but for the time being we attempt to document how it fits in 150 the different options.) 152 CLUE messages may need to be sent at the initialization of a call, 153 and possibly also at irregular intervals within a call, spaced in the 154 order of seconds, minutes or even longer. There is also no hard 155 real-time transmission requirement for CLUE messages; latencies in 156 the seconds range are acceptable. More specifically, there appears 157 not to be an issue with system reaction delay larger than the maximum 158 round trip delay for reasonable operation of a telepresence system. 160 The Clue message handshake as required by the framework (independent 161 from the issue related to the need of the Consumer Capability 162 Message) is different from the offer/answer (o/A) exchange [RFC3264], 163 primarily because the CLUE exchange is uni-directional, requiring a 164 similar exchange for each side of the media flow, while one offer/ 165 answer exchange defines both sides of the media flow. (Note that 166 asymmetry in SIP may require a second offer answer exchange, but this 167 is not the typical case) 169 There is no hard requirement for synchronization of CLUE messages, 170 though there may be a need for sequencing, (TBD). 172 CLUE messages may need to describe the characteristics of all 173 endpoints in a conference (TBD), and that conference can potentially 174 include dozens of endpoints. 176 It appears to be consensus within the CLUE WG that there will be an 177 SDP offer/answer exchange as part of the solution. It further 178 appears to be the consensus that the offer/answer will be used to 179 establish the media channels and negotiate those SDP parameters 180 negotiable with media types (i.e. as defined in RTP payload formats), 181 as well as to allow interoperability with systems that do not support 182 the CLUE protocol. It appears to be a sensible design goal that the 183 CLUE data does not duplicate SDP attributes. 185 In order to achieve interoperability with systems that do not support 186 CLUE, the first offer answer exchange could be used to negotiate CLUE 187 support. 189 An open issue is whether there needs to be a final offer answer 190 exchange, after initial o/A exchange(s) as well as CLUE exchange(s), 191 with an SDP reflecting the negotiated media flows, in order to 192 address requirements imposed by intermediaries like Session Border 193 Controllers (SBC). This topic was discussed in different contexts 194 before, and there is some text about it in RFC5939 section 3.12 195 [RFC5939] 197 The size of a CLUE message is far from final yet but when selecting a 198 solution the issue of message size and fragmentation (if applicable) 199 needs to be addressed. 201 3. Transport for CLUE messages 203 CLUE messages need to be conveyed from one CLUE capable system to 204 another, i.e., there needs to be "transport" of CLUE messages. It 205 should be clear that the message transport can be based on a 206 transport layer (layer 4 in ISO/OSI) protocol or other layers, such 207 as the application layer. 209 In contrast to the "content representation", the transport of CLUE 210 messages is somewhat more tightly bound to the environment. In some 211 scenarios it may be possible to reuse most of the mechanisms defined 212 in an option for transport between SIP and H.323, while in others 213 this is not possible. 215 The selection of the transport may have some affect on the content 216 representation, in that certain transports in the aforementioned 217 sense are defined only to carry certain types of messages. For 218 example, offer-answer is defined for the use in conjunction with SDP 219 as content representation. In contrast, obviously, a CLUE-defined 220 transport mechanism could carry any format specified by CLUE. 222 The CLUE protocol enables the CLUE systems to negotiate the semantic 223 relationships of the media streams, mostly with respect to spatial 224 relations. Another aspect that has recently risen to prominence is 225 the negotiation of media codec settings, taking into account that in 226 practical telepresence systems, certain combinations of codec 227 settings may not be supported by the hardware ("codec alternatives" 228 henceforth). 230 The apparently generally agreed need for interoperability with non 231 CLUE systems requires defining an initial offer involving CLUE 232 support, and guidance on how to progress the call setup based on the 233 answer. The CLUE WG discussed a couple of options including two 234 stage offer answer, using grouping similar to 235 [I-D.ietf-mmusic-sdp-bundle-negotiation], and using the capability 236 negotiation of [RFC5939]. 238 We would like to consider the following options: 240 3.1. Option 1 : Piggy-pack on SIP 242 SIP includes a number of methods that can carry (directly or through 243 content indirection) CLUE messages. Many of these messages can be 244 exchanged during the lifetime of a session. Piggy-packing CLUE 245 messages on SIP has the advantage that any built-in transport and 246 reliability mechanisms of SIP can be re-used. (Whether this is an 247 advantage in practice is somewhat questionable, considering that the 248 vast majority of SIP systems use UDP for the transport of SIP 249 messages, and that their SIP messages are typically small enough to 250 fit into an MTU--something that like is not true for some CLUE 251 messages.) It also has the feature (advantage?) that CLUE signaling 252 is being conveyed in the signaling plane rather than in the media 253 plane (making things such as decomposition potentially easier and 254 certainly more intuitive). 256 There are three sub-options to consider 258 3.1.1. Option 1.1: Using SDP (in an offer-answer context) for CLUE 259 information 261 In this option, the CLUE protocol is specified through the addition 262 of CLUE-specific SDP codepoints in the (essentially unmodified) 263 offer/answer process, for essentially all CLUE functionalities. The 264 stream semantics associated with spatial relations of streams are 265 represented as new SDP attributes . Codec alternatives may be 266 negotiated based on draft-ietf-mmusic-sdp-media-capabilities. 268 The nature of spatial relations currently envisioned by some CLUE 269 participants have some simultaneous restrictions due to the 270 limitations of physical capture devices. For this reason, it may 271 become necessary to separate the negotiation process into a session 272 negotiation that defines RTP sessions, and a session negotiated that 273 deals with the spatial relations. 275 It is noted that, at the time of writing, there is no proposal on the 276 table that would suggest that offer-answer only is a sensible--or 277 even possible--design choice. 279 3.1.2. Option 1.2: Using an SDP MIME body to carry the CLUE information 280 in an INVITE or UPDATE exchange 282 In order to separate the RTP session negotiation from the CLUE media 283 capture selection, a clean solution appears to be to carry the CLUE 284 information in a body separate from the classic media negotiation 285 information, with a parallel negotiation using INVITE and UPDATE for 286 the CLUE information. A similar approach is proposed in 287 [I-D.ietf-siprec-protocol]. 289 There were concerns about using re-invite, claiming that it takes too 290 long since that commonly implies codec boxes teardown of every 291 existing media session during re-invites. [RFC3311]suggests that 292 although UPDATE can be used on confirmed dialogs, it is RECOMMENDED 293 that a re-INVITE be used instead. This is because an UPDATE needs to 294 be answered immediately, ruling out the possibility of user approval. 295 Such approval may be needed, and is possible only with a re-INVITE. 297 3.1.3. Option 1.3: Using a SIP INFO package 299 Another option may be to define a new SIP INFO package [RFC6086]. 300 The SIP-INFO method is very flexible in that the package can define, 301 at least to a large extent, the semantics of a SIP-INFO exchange. 302 However, SIP-INFO is subject to SIPOs limitations, for example in 303 terms of message size when SIP messages are transported over UDP 304 (which, we understand, is the common operation point. 306 3.1.4. Option 1.4: SIP signaling options 308 There may be other options using SIP signaling, such as subscribe/ 309 notify or Message method, see [RFC6086] section 8.4.1. Note that, in 310 those cases, a subscribe creates a separate dialog usage and is 311 normally sent outside of existing dialog. Within this document, we 312 are not discussing the implications of such a possible implementation 313 path. 315 3.2. Option 2: CLUE control channel on the media plane over UDP 317 During the initial SIP handshake, a secure(?) CLUE channel is 318 established (if both systems are CLUE capable). This channel may be 319 UDP or TCP based. Using UDP may require an additional reliability 320 mechanism, perhaps using a mechanism similar to BFCP over UDP, and 321 addressing fragmentation is likely to be necessary due to message 322 size. These complications are not required for a TCP based solution. 323 On the other hand, using ICE to address firewall and NAT traversal as 324 well as working with intermediaries like SBCs works better with UDP. 325 Note that even under this option, we assume that the actual protocol 326 exchange to negotiate and open media channels is being conducted 327 using an SDP content representation, quite possibly through a 328 "fincal" offer-answer exchange that nails down the actual media flows 329 to be used, for the benefit of SBCs and similar middleboxes. 331 3.3. Option 3: Other Work 333 At least three other individual submissions address similar topics as 334 this section, and the the readerOs attention is drawn to those. 335 Specifically: 337 [I-D.hansen-clue-protocol-choices-evaluation] goes into some detail 338 in analyzing the pros and cons of a previous version of our document. 339 The authors arrive at a conclusion that can be summarized as that 340 there is a need for a transport mechanism that is not based on SIP, 341 but using a UDP session negotiated using SIP and Offer/Answer for the 342 transport of CLUE messages. CLUE messages in this case probably 343 ought to be interpreted narrowly in that they relate to spatial 344 relationships and related issues, in contrast to codec parameter 345 negotiation. 347 [I-D.romanow-clue-sdp-usage] arrives at a similar conclusion. The 348 draft lists those codepoints that could be conveyed using SDP in an 349 offer-answer setting: video properties (bandwidth and resolution), 350 and bandwidth-related group settings. Everything else, including 351 spatial relationship of captures, is suggested to be conveyed over a 352 CLUE-specific protocol, conveyed over a UDP(?) session negotiated in 353 SIP during the early (first) offer/answer exchange. 355 [I-D.cazeaux-clue-sip-signaling] signaling appears to advocate a 356 solution in which SDP based O/A is used to negotiate media. The 357 negotiated media appear to be a superset of the media later being 358 used. CLUE specific information, such as spatial relationships, but 359 also the details of the media sessions (including restrictions of 360 provider content selection based on consumer capabilities), appear to 361 be relegated to signaling conveyed over a SIP/OA negotiated CLUE 362 channel. 364 All three aforementioned drafts appear to acknowledge the need for a 365 CLUE signaling channel, possibly conveyed directly over UDP (in 366 contrast to a being conveyed over SIP-info or something similar), 367 although these drafts vary in the degree to which they use the CLUE 368 signaling channel. 370 4. Content Representation 372 The data model in the framework-03 draft does not include a 373 specification of the representation of the data. Many different 374 representation languages, for example XML, possibly SDP, ASN.1, and 375 others can be used, and we need to decide on one, possibly for each 376 data structure defined in a CLUE solution (that is, for example, it's 377 possible that some data points of CLUE can be conveyed in SDP, 378 whereas others use XML). Depending on the transport decision, we may 379 be restricted to certain representations for certain data structures, 380 or we may have freedom of choice. Referring to the options suggested 381 above, it is clear that option 3.1.1 mandates SDP for representing 382 CLUE. However, all other options appear not to require any pre- 383 defined choice, at least for some (though not necessarily for all) of 384 the CLUE-defined codepoints. 386 One observation that has to be made at this point (described in 387 greater detail above) is that the framework-01 draft's message 388 exchange system requires more than one end to end exchange due to the 389 asymmetry. Another observation is that the advertisement describes 390 the sending options, which makes the CLUE exchange different from the 391 offer/answer mechanism SIP videoconferencing endpoints use today. 392 For this reason we do not think that the option in 3.1.1 is a good 393 direction. Therefore, there appears not to be a hard requirement to 394 use SDP exclusively for the representation of CLUE messages. For 395 some messages, SDP may be an appropriate choice, but for others, 396 there is no precedence: We have a freedom of choice here, which is 397 why this section exists. 399 It is very well possible that even moderately complex CLUE messages 400 may exceed MTU sizes commonly found in todayOs Internet. There has 401 been discussion in CLUE of sessions with thousands of participantsNa 402 very real requirement for at least one of the authors of this draft, 403 who routinely participates in multipoint videoconferences with 200+ 404 participants. Even if a CLUE message can be compressed into a few 405 bytes for each endpoint, such sessions will violate the commonly 406 found Ethernet 1492-byte MTU. Accordingly, message transport 407 protocols will have to be prepared to split CLUE messages into 408 fragments, which has implications on the design complexity of those 409 protocols. This problem is especially an issue for verbose 410 representations, such as XML. 412 4.1. Option 1 : SDP 414 SDP and its various extensions are used in SIP based systems for the 415 offer/answer exchange, and, therefore, those systems include SDP 416 parsers that could probably be extended to support CLUE messages. 417 SDP is also a fairly compact, but still (though barely) human 418 readable . Even though it does not appear to us to make overly much 419 sense to use SDP for CLUE, since it will require a separate blob for 420 describing the CLUE relations between the media captures, it still 421 viable to use text based representation for CLUE if using any of the 422 options which is not 3.1.1. [I-D.romanow-clue-sdp-usage] suggests 423 that an SDP-only representation of CLUE based parameters is an 424 (impossible/suboptimal) bad choice. We concur. As mentioned before, 425 though, those parameters that can reasonably be negotiated using SDP 426 o/A (with however many round trip it takes) should in our opinion be 427 represented in SDP. We shouldn't be in SDP-ng's business. 429 4.2. Option 2 : XML 431 XML is very flexible, and the representation of choice for many IETF 432 technologies not bound to a certain legacy. It certainly allows for 433 all flexibility needed to represent all CLUE messages currently 434 considered. It also is naturally extensible in a way SDP is not. On 435 the downside, XML is fairly verbose, which has implications on the 436 transport. Even considering this verboseness, we believe that XML 437 may be an appropriate representation for CLUE messages that cannot be 438 represented in SDP. 440 4.3. Option 3 : ASN.1 442 ASN.1 is similarly flexible and extensible as XML, and (in its binary 443 representation) fairly compact. While it is commonly used in H.323, 444 and while the video conferencing industry certainly has access to the 445 tools necessary to deploy ASN.1 (a major obstacle in other 446 industries), it is not widely used by SIP implementations. 448 4.4. Option 4 : Clue Defined Format 450 It is, of course, possible that the CLUE WG defines its own format, 451 possibly compact, possibly binary and possibly extensible 452 representation language or format for CLUE messages. 454 4.5. Examples 456 An example or examples should be added here when possible 458 4.6. Proposal 460 The preferred solution can be XML-based for codepoints not easily 461 (currently?) representable in SDP, and SDP based for everything else. 462 ] With respect to XMLOs verboseness, fragmentation support in the 463 transport protocol may be needed and the transport probably should 464 include a fragmentation and reassembly support beyond IP 465 fragmentation/re-assembly. Such support may require an encapsulation 466 of the message with headers that will allow fragmentation and 467 reassembly support. 469 5. Clue Discovery 471 This section summarizes ways to discover whether systems involved are 472 CLUE-capable. For simplicity, point-to-point scenarios are assumed. 473 Multipoint scenarios are similar since we are considering centralized 474 conference models only. 476 Discovery appears to be necessarily bound to the capability exchange 477 of the involved systems. 479 5.1. Option 1 : CLUE discovery as a side effect of opening a CLUE 480 control channel 482 If, for the transport of CLUE messages (or at least a subset 483 thereof), a media plane control channel were used (section 3.2), then 484 the discovery of CLUE capability would be a side effect of the 485 opening of this control channel during the initial offer/answer 486 exchange. At this point in time, there is no proposal on the table 487 that suggest that we can avoid a CLUE control channel. 489 5.2. Option 2 : SIP Message Transport 491 Very roughly speaking, if we use the INFO message for the transport 492 of all CLUE messages, then by using the Recv-Info header field the 493 support for the CLUE package can be signaled. If using a second MIME 494 body the support of the MIME body in the offer answer can be used. 496 6. IANA Considerations 498 This document makes no request of IANA. 500 Note to RFC Editor: this section may be removed on publication as an 501 RFC. 503 7. Security Considerations 505 Any method for bypassing NAT/Firewall protections of course brings 506 security issues, which need to be dealt with. 508 8. Acknowledgements 510 The list of authors needs to grow. 512 9. Informative References 514 [I-D.cazeaux-clue-sip-signaling] 515 Cazeaux, S. and E. Bertin, "Requirements for ControLling 516 mUltiple streams for tElepresence (CLUE) signaling.", 517 draft-cazeaux-clue-sip-signaling-00 (work in progress), 518 March 2012. 520 [I-D.hansen-clue-protocol-choices-evaluation] 521 Hansen, R. and A. Romanow, "Evaluation of using SIP or an 522 independent protocol for CLUE messaging", 523 draft-hansen-clue-protocol-choices-evaluation-00 (work in 524 progress), November 2011. 526 [I-D.ietf-mmusic-sdp-bundle-negotiation] 527 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 528 Using Session Description Protocol (SDP) Port Numbers", 529 draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in 530 progress), February 2012. 532 [I-D.ietf-siprec-protocol] 533 Portman, L., Lum, H., Johnston, A., and A. Hutton, 534 "Session Recording Protocol", 535 draft-ietf-siprec-protocol-03 (work in progress), 536 March 2012. 538 [I-D.romanow-clue-sdp-usage] 539 Romanow, A., Andreasen, F., and A. Krishna, "Investigation 540 of Session Description Protocol (SDP) Usage for 541 ControLling mUltiple streams for tElepresence (CLUE)", 542 draft-romanow-clue-sdp-usage-00 (work in progress), 543 March 2012. 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 549 with Session Description Protocol (SDP)", RFC 3264, 550 June 2002. 552 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 553 UPDATE Method", RFC 3311, October 2002. 555 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 556 Capability Negotiation", RFC 5939, September 2010. 558 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 559 Initiation Protocol (SIP) INFO Method and Package 560 Framework", RFC 6086, January 2011. 562 Authors' Addresses 564 Dr. Stephan Wenger 565 Vidyo 566 433 Hackensack Ave 567 Hackensack, NJ 07601 568 USA 570 Email: stewe@stewe.org 572 Marshall Eubanks 573 AmericaFree.TV 574 P.O. Box 141 575 Clifton, Virginia 20124 576 USA 578 Phone: +1-703-501-4376 579 Email: marshall.eubanks@gmail.com 581 Roni Even 582 Huawei 584 Email: ron.even.tlv@gmail.com 586 Gonzalo Camarillo 587 Ericsson 589 Email: Gonzalo.Camarillo@ericsson.com