Network Working Group S. Wenger Internet-Draft Vidyo Intended status: Standards Track M. Eubanks Expires: September 13, 2012 AmericaFree.TV R. Even Huawei G. Camarillo Ericsson March 12, 2012 Transport Options for Clue draft-wenger-clue-transport-02 Abstract This memo describes the assumption and the proposed options for the coding and transport of CLUE messages as outlined in version 01 of the framework draft. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Wenger, et al. Expires September 13, 2012 [Page 1] Internet-Draft clue-transport March 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Transport for CLUE messages . . . . . . . . . . . . . . . . . 5 3.1. Option 1 : Piggy-pack on SIP . . . . . . . . . . . . . . . 6 3.1.1. Option 1.1: Using SDP (in an offer-answer context) for CLUE information . . . . . . . . . . . . . . . . . 6 3.1.2. Option 1.2: Using an SDP MIME body to carry the CLUE information in an INVITE or UPDATE exchange . . . 7 3.1.3. Option 1.3: Using a SIP INFO package . . . . . . . . . 7 3.1.4. Option 1.4: SIP signaling options . . . . . . . . . . 7 3.2. Option 2: CLUE control channel on the media plane over UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Option 3: Other Work . . . . . . . . . . . . . . . . . . . 8 4. Content Representation . . . . . . . . . . . . . . . . . . . . 8 4.1. Option 1 : SDP . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Option 2 : XML . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Option 3 : ASN.1 . . . . . . . . . . . . . . . . . . . . . 10 4.4. Option 4 : Clue Defined Format . . . . . . . . . . . . . . 10 4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Clue Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Option 1 : CLUE discovery as a side effect of opening a CLUE control channel . . . . . . . . . . . . . . . . . . 11 5.2. Option 2 : SIP Message Transport . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Wenger, et al. Expires September 13, 2012 [Page 2] Internet-Draft clue-transport March 2012 1. Introduction The CLUE WG is chartered to design a protocol to enable communication about media streams for videoconferencing and telepresence working in conjunction with the IETFOs protocol suites of choice, namely SIP for basic call setup and control and RTP for media transport. (It should be noted that ITU-T Q.xx/16 has informally expressed a desire that parts or all of the work of the CLUE WG can be re-used in an H.323 environment. Therefore, occasionally, we comment on the re-use of CLUE work outside of SIP systems. This does not mean that we want to extent the charter; however, it seems sensible at least to us that if a cross protocol solution and a SIP-only solution to the CLUE problem could be devised, and both solutions are comparable in in their complexity etc etc, a solution with applicability beyond SIP may be the appropriate choice.) This document describes options for the coding and transport of CLUE messages in a SIP / RTP environment. Specifically, three issues are addressed. First, while the framework draft conceptually describes message flows, it does not specify how those messages are actually transferred "on the wire" and how they relate to the SIP offer/answer [RFC3264]. This document lists (hopefully all) the options that have been proposed in CLUE to date. Second, the framework-01 draft describes three messages between the producer and the consumer in an abstract form, without specifying the details of the representation of those messages. This memo lists (some of) the options for the representation of the abstract messages of the framework draft. Third, before any CLUE messages can be meaningfully exchanged, it is necessary to discover whether the involved systems are actually CLUE- capable. This memo discusses the proposed options for CLUE capability discovery. In this memo we only present the options discussed to date in the working group. Deciding on the appropriate mechanism (or mechanisms, as it is not always appropriate to have a single solution for a given problem, though this is of course desirable from an interoperability viewpoint) is left for further discussion in the working group. That does not mean that the authors do not have preferences, and/or specific knowledge of certain mechanisms, and may as a result go in greater depth in describing one mechanism than another. Wenger, et al. Expires September 13, 2012 [Page 3] Internet-Draft clue-transport March 2012 2. Assumptions The Basic Clue data model is specified in the framework document. The framework defines three messages that carry the Clue data: Consumer Capability Message Provider Capabilities Announcement Consumer Configure Request (There is no clear consensus that the Consumer Capability Message is needed, but for the time being we attempt to document how it fits in the different options.) CLUE messages may need to be sent at the initialization of a call, and possibly also at irregular intervals within a call, spaced in the order of seconds, minutes or even longer. There is also no hard real-time transmission requirement for CLUE messages; latencies in the seconds range are acceptable. More specifically, there appears not to be an issue with system reaction delay larger than the maximum round trip delay for reasonable operation of a telepresence system. The Clue message handshake as required by the framework (independent from the issue related to the need of the Consumer Capability Message) is different from the offer/answer (o/A) exchange [RFC3264], primarily because the CLUE exchange is uni-directional, requiring a similar exchange for each side of the media flow, while one offer/ answer exchange defines both sides of the media flow. (Note that asymmetry in SIP may require a second offer answer exchange, but this is not the typical case) There is no hard requirement for synchronization of CLUE messages, though there may be a need for sequencing, (TBD). CLUE messages may need to describe the characteristics of all endpoints in a conference (TBD), and that conference can potentially include dozens of endpoints. It appears to be consensus within the CLUE WG that there will be an SDP offer/answer exchange as part of the solution. It further appears to be the consensus that the offer/answer will be used to establish the media channels and negotiate those SDP parameters negotiable with media types (i.e. as defined in RTP payload formats), as well as to allow interoperability with systems that do not support the CLUE protocol. It appears to be a sensible design goal that the CLUE data does not duplicate SDP attributes. Wenger, et al. Expires September 13, 2012 [Page 4] Internet-Draft clue-transport March 2012 In order to achieve interoperability with systems that do not support CLUE, the first offer answer exchange could be used to negotiate CLUE support. An open issue is whether there needs to be a final offer answer exchange, after initial o/A exchange(s) as well as CLUE exchange(s), with an SDP reflecting the negotiated media flows, in order to address requirements imposed by intermediaries like Session Border Controllers (SBC). This topic was discussed in different contexts before, and there is some text about it in RFC5939 section 3.12 [RFC5939] The size of a CLUE message is far from final yet but when selecting a solution the issue of message size and fragmentation (if applicable) needs to be addressed. 3. Transport for CLUE messages CLUE messages need to be conveyed from one CLUE capable system to another, i.e., there needs to be "transport" of CLUE messages. It should be clear that the message transport can be based on a transport layer (layer 4 in ISO/OSI) protocol or other layers, such as the application layer. In contrast to the "content representation", the transport of CLUE messages is somewhat more tightly bound to the environment. In some scenarios it may be possible to reuse most of the mechanisms defined in an option for transport between SIP and H.323, while in others this is not possible. The selection of the transport may have some affect on the content representation, in that certain transports in the aforementioned sense are defined only to carry certain types of messages. For example, offer-answer is defined for the use in conjunction with SDP as content representation. In contrast, obviously, a CLUE-defined transport mechanism could carry any format specified by CLUE. The CLUE protocol enables the CLUE systems to negotiate the semantic relationships of the media streams, mostly with respect to spatial relations. Another aspect that has recently risen to prominence is the negotiation of media codec settings, taking into account that in practical telepresence systems, certain combinations of codec settings may not be supported by the hardware ("codec alternatives" henceforth). The apparently generally agreed need for interoperability with non CLUE systems requires defining an initial offer involving CLUE Wenger, et al. Expires September 13, 2012 [Page 5] Internet-Draft clue-transport March 2012 support, and guidance on how to progress the call setup based on the answer. The CLUE WG discussed a couple of options including two stage offer answer, using grouping similar to [I-D.ietf-mmusic-sdp-bundle-negotiation], and using the capability negotiation of [RFC5939]. We would like to consider the following options: 3.1. Option 1 : Piggy-pack on SIP SIP includes a number of methods that can carry (directly or through content indirection) CLUE messages. Many of these messages can be exchanged during the lifetime of a session. Piggy-packing CLUE messages on SIP has the advantage that any built-in transport and reliability mechanisms of SIP can be re-used. (Whether this is an advantage in practice is somewhat questionable, considering that the vast majority of SIP systems use UDP for the transport of SIP messages, and that their SIP messages are typically small enough to fit into an MTU--something that like is not true for some CLUE messages.) It also has the feature (advantage?) that CLUE signaling is being conveyed in the signaling plane rather than in the media plane (making things such as decomposition potentially easier and certainly more intuitive). There are three sub-options to consider 3.1.1. Option 1.1: Using SDP (in an offer-answer context) for CLUE information In this option, the CLUE protocol is specified through the addition of CLUE-specific SDP codepoints in the (essentially unmodified) offer/answer process, for essentially all CLUE functionalities. The stream semantics associated with spatial relations of streams are represented as new SDP attributes . Codec alternatives may be negotiated based on draft-ietf-mmusic-sdp-media-capabilities. The nature of spatial relations currently envisioned by some CLUE participants have some simultaneous restrictions due to the limitations of physical capture devices. For this reason, it may become necessary to separate the negotiation process into a session negotiation that defines RTP sessions, and a session negotiated that deals with the spatial relations. It is noted that, at the time of writing, there is no proposal on the table that would suggest that offer-answer only is a sensible--or even possible--design choice. Wenger, et al. Expires September 13, 2012 [Page 6] Internet-Draft clue-transport March 2012 3.1.2. Option 1.2: Using an SDP MIME body to carry the CLUE information in an INVITE or UPDATE exchange In order to separate the RTP session negotiation from the CLUE media capture selection, a clean solution appears to be to carry the CLUE information in a body separate from the classic media negotiation information, with a parallel negotiation using INVITE and UPDATE for the CLUE information. A similar approach is proposed in [I-D.ietf-siprec-protocol]. There were concerns about using re-invite, claiming that it takes too long since that commonly implies codec boxes teardown of every existing media session during re-invites. [RFC3311]suggests that although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval may be needed, and is possible only with a re-INVITE. 3.1.3. Option 1.3: Using a SIP INFO package Another option may be to define a new SIP INFO package [RFC6086]. The SIP-INFO method is very flexible in that the package can define, at least to a large extent, the semantics of a SIP-INFO exchange. However, SIP-INFO is subject to SIPOs limitations, for example in terms of message size when SIP messages are transported over UDP (which, we understand, is the common operation point. 3.1.4. Option 1.4: SIP signaling options There may be other options using SIP signaling, such as subscribe/ notify or Message method, see [RFC6086] section 8.4.1. Note that, in those cases, a subscribe creates a separate dialog usage and is normally sent outside of existing dialog. Within this document, we are not discussing the implications of such a possible implementation path. 3.2. Option 2: CLUE control channel on the media plane over UDP During the initial SIP handshake, a secure(?) CLUE channel is established (if both systems are CLUE capable). This channel may be UDP or TCP based. Using UDP may require an additional reliability mechanism, perhaps using a mechanism similar to BFCP over UDP, and addressing fragmentation is likely to be necessary due to message size. These complications are not required for a TCP based solution. On the other hand, using ICE to address firewall and NAT traversal as well as working with intermediaries like SBCs works better with UDP. Note that even under this option, we assume that the actual protocol exchange to negotiate and open media channels is being conducted Wenger, et al. Expires September 13, 2012 [Page 7] Internet-Draft clue-transport March 2012 using an SDP content representation, quite possibly through a "fincal" offer-answer exchange that nails down the actual media flows to be used, for the benefit of SBCs and similar middleboxes. 3.3. Option 3: Other Work At least three other individual submissions address similar topics as this section, and the the readerOs attention is drawn to those. Specifically: [I-D.hansen-clue-protocol-choices-evaluation] goes into some detail in analyzing the pros and cons of a previous version of our document. The authors arrive at a conclusion that can be summarized as that there is a need for a transport mechanism that is not based on SIP, but using a UDP session negotiated using SIP and Offer/Answer for the transport of CLUE messages. CLUE messages in this case probably ought to be interpreted narrowly in that they relate to spatial relationships and related issues, in contrast to codec parameter negotiation. [I-D.romanow-clue-sdp-usage] arrives at a similar conclusion. The draft lists those codepoints that could be conveyed using SDP in an offer-answer setting: video properties (bandwidth and resolution), and bandwidth-related group settings. Everything else, including spatial relationship of captures, is suggested to be conveyed over a CLUE-specific protocol, conveyed over a UDP(?) session negotiated in SIP during the early (first) offer/answer exchange. [I-D.cazeaux-clue-sip-signaling] signaling appears to advocate a solution in which SDP based O/A is used to negotiate media. The negotiated media appear to be a superset of the media later being used. CLUE specific information, such as spatial relationships, but also the details of the media sessions (including restrictions of provider content selection based on consumer capabilities), appear to be relegated to signaling conveyed over a SIP/OA negotiated CLUE channel. All three aforementioned drafts appear to acknowledge the need for a CLUE signaling channel, possibly conveyed directly over UDP (in contrast to a being conveyed over SIP-info or something similar), although these drafts vary in the degree to which they use the CLUE signaling channel. 4. Content Representation The data model in the framework-03 draft does not include a specification of the representation of the data. Many different Wenger, et al. Expires September 13, 2012 [Page 8] Internet-Draft clue-transport March 2012 representation languages, for example XML, possibly SDP, ASN.1, and others can be used, and we need to decide on one, possibly for each data structure defined in a CLUE solution (that is, for example, it's possible that some data points of CLUE can be conveyed in SDP, whereas others use XML). Depending on the transport decision, we may be restricted to certain representations for certain data structures, or we may have freedom of choice. Referring to the options suggested above, it is clear that option 3.1.1 mandates SDP for representing CLUE. However, all other options appear not to require any pre- defined choice, at least for some (though not necessarily for all) of the CLUE-defined codepoints. One observation that has to be made at this point (described in greater detail above) is that the framework-01 draft's message exchange system requires more than one end to end exchange due to the asymmetry. Another observation is that the advertisement describes the sending options, which makes the CLUE exchange different from the offer/answer mechanism SIP videoconferencing endpoints use today. For this reason we do not think that the option in 3.1.1 is a good direction. Therefore, there appears not to be a hard requirement to use SDP exclusively for the representation of CLUE messages. For some messages, SDP may be an appropriate choice, but for others, there is no precedence: We have a freedom of choice here, which is why this section exists. It is very well possible that even moderately complex CLUE messages may exceed MTU sizes commonly found in todayOs Internet. There has been discussion in CLUE of sessions with thousands of participantsNa very real requirement for at least one of the authors of this draft, who routinely participates in multipoint videoconferences with 200+ participants. Even if a CLUE message can be compressed into a few bytes for each endpoint, such sessions will violate the commonly found Ethernet 1492-byte MTU. Accordingly, message transport protocols will have to be prepared to split CLUE messages into fragments, which has implications on the design complexity of those protocols. This problem is especially an issue for verbose representations, such as XML. 4.1. Option 1 : SDP SDP and its various extensions are used in SIP based systems for the offer/answer exchange, and, therefore, those systems include SDP parsers that could probably be extended to support CLUE messages. SDP is also a fairly compact, but still (though barely) human readable . Even though it does not appear to us to make overly much sense to use SDP for CLUE, since it will require a separate blob for describing the CLUE relations between the media captures, it still viable to use text based representation for CLUE if using any of the Wenger, et al. Expires September 13, 2012 [Page 9] Internet-Draft clue-transport March 2012 options which is not 3.1.1. [I-D.romanow-clue-sdp-usage] suggests that an SDP-only representation of CLUE based parameters is an (impossible/suboptimal) bad choice. We concur. As mentioned before, though, those parameters that can reasonably be negotiated using SDP o/A (with however many round trip it takes) should in our opinion be represented in SDP. We shouldn't be in SDP-ng's business. 4.2. Option 2 : XML XML is very flexible, and the representation of choice for many IETF technologies not bound to a certain legacy. It certainly allows for all flexibility needed to represent all CLUE messages currently considered. It also is naturally extensible in a way SDP is not. On the downside, XML is fairly verbose, which has implications on the transport. Even considering this verboseness, we believe that XML may be an appropriate representation for CLUE messages that cannot be represented in SDP. 4.3. Option 3 : ASN.1 ASN.1 is similarly flexible and extensible as XML, and (in its binary representation) fairly compact. While it is commonly used in H.323, and while the video conferencing industry certainly has access to the tools necessary to deploy ASN.1 (a major obstacle in other industries), it is not widely used by SIP implementations. 4.4. Option 4 : Clue Defined Format It is, of course, possible that the CLUE WG defines its own format, possibly compact, possibly binary and possibly extensible representation language or format for CLUE messages. 4.5. Examples An example or examples should be added here when possible 4.6. Proposal The preferred solution can be XML-based for codepoints not easily (currently?) representable in SDP, and SDP based for everything else. ] With respect to XMLOs verboseness, fragmentation support in the transport protocol may be needed and the transport probably should include a fragmentation and reassembly support beyond IP fragmentation/re-assembly. Such support may require an encapsulation of the message with headers that will allow fragmentation and reassembly support. Wenger, et al. Expires September 13, 2012 [Page 10] Internet-Draft clue-transport March 2012 5. Clue Discovery This section summarizes ways to discover whether systems involved are CLUE-capable. For simplicity, point-to-point scenarios are assumed. Multipoint scenarios are similar since we are considering centralized conference models only. Discovery appears to be necessarily bound to the capability exchange of the involved systems. 5.1. Option 1 : CLUE discovery as a side effect of opening a CLUE control channel If, for the transport of CLUE messages (or at least a subset thereof), a media plane control channel were used (section 3.2), then the discovery of CLUE capability would be a side effect of the opening of this control channel during the initial offer/answer exchange. At this point in time, there is no proposal on the table that suggest that we can avoid a CLUE control channel. 5.2. Option 2 : SIP Message Transport Very roughly speaking, if we use the INFO message for the transport of all CLUE messages, then by using the Recv-Info header field the support for the CLUE package can be signaled. If using a second MIME body the support of the MIME body in the offer answer can be used. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations Any method for bypassing NAT/Firewall protections of course brings security issues, which need to be dealt with. 8. Acknowledgements The list of authors needs to grow. Wenger, et al. Expires September 13, 2012 [Page 11] Internet-Draft clue-transport March 2012 9. Informative References [I-D.cazeaux-clue-sip-signaling] Cazeaux, S. and E. Bertin, "Requirements for ControLling mUltiple streams for tElepresence (CLUE) signaling.", draft-cazeaux-clue-sip-signaling-00 (work in progress), March 2012. [I-D.hansen-clue-protocol-choices-evaluation] Hansen, R. and A. Romanow, "Evaluation of using SIP or an independent protocol for CLUE messaging", draft-hansen-clue-protocol-choices-evaluation-00 (work in progress), November 2011. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in progress), February 2012. [I-D.ietf-siprec-protocol] Portman, L., Lum, H., Johnston, A., and A. Hutton, "Session Recording Protocol", draft-ietf-siprec-protocol-03 (work in progress), March 2012. [I-D.romanow-clue-sdp-usage] Romanow, A., Andreasen, F., and A. Krishna, "Investigation of Session Description Protocol (SDP) Usage for ControLling mUltiple streams for tElepresence (CLUE)", draft-romanow-clue-sdp-usage-00 (work in progress), March 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010. [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Wenger, et al. Expires September 13, 2012 [Page 12] Internet-Draft clue-transport March 2012 Framework", RFC 6086, January 2011. Authors' Addresses Dr. Stephan Wenger Vidyo 433 Hackensack Ave Hackensack, NJ 07601 USA Email: stewe@stewe.org Marshall Eubanks AmericaFree.TV P.O. Box 141 Clifton, Virginia 20124 USA Phone: +1-703-501-4376 Email: marshall.eubanks@gmail.com Roni Even Huawei Email: ron.even.tlv@gmail.com Gonzalo Camarillo Ericsson Email: Gonzalo.Camarillo@ericsson.com Wenger, et al. Expires September 13, 2012 [Page 13]