CLUE WG R. Even Internet-Draft Huawei Intended status: Informational October 21, 2012 Expires: April 24, 2013 Signalling of CLUE and SDP offer/answer draft-even-clue-sdp-clue-relation-01.txt Abstract This document describes the relation between the different CLUE attributes as specified in the CLUE framework and the SDP attributes. The document will discuss the issues with the CLUE call signalling in order to keep the consistency between the Offer/answer state and the CLUE state. 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 April 24, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Even Expires April 24, 2013 [Page 1] Internet-Draft SDP offer/answer and CLUE relation October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Capture attributes . . . . . . . . . . . . . . . . . . . . . . 3 4. Encoding parameters . . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Even Expires April 24, 2013 [Page 2] Internet-Draft SDP offer/answer and CLUE relation October 2012 1. Introduction The CLUE framework[I-D.ietf-clue-framework] is used to specify the information needed for creating a Telepresence call. The model includes the Media capture information providing information about content of the streams and can provide information about the spatial information between streams based on the capture point and area of capture. A capture scene includes media captures that are part of a same scene e.g. room capture or presentation. The other information defined in the framework is the Encoding information providing information about the abilities of the providers to send streams allowing a consumer to configure a capture to a specific encoding. The next sections will look at the capture attributes and the encoding parameter and describe the relation to SDP [RFC4566]. 2. Terminology 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 RFC2119[RFC2119] and indicate requirement levels for compliant RTP implementations. 3. Capture attributes The media capture attributes provide static information about the captures. This includes the content of information and can provide spatial information in order to allow the "being there" experience. The media capture attributes include the content describing the role of the media capture, if the content is composed or switched and spatial information providing the three dimensional position of the streams. The media capture content attribute is based on SDP content attribute [RFC4796] The other attribute do not have similar SDP attributes. When starting a call the initial offer may include more than one media stream of a media type with a content attribute (e.g. offer main and slide SDP content). In this case the advertisement will also include media captures for main and slides. If the initial offer did not provide content attribute there is no need to provide it later assuming that if the answerer do not support CLUE protocol it is not sure that he will support the content attribute [RFC4796] Even Expires April 24, 2013 [Page 3] Internet-Draft SDP offer/answer and CLUE relation October 2012 As for the other attributes, there are no similar SDP attributes and they provide information which can be used by TelePresence systems. The media capture switched and composed attributes provide information about the creation of the content. Using RTP/RTCP SRRC and CSRC [RFC3550] can provide information about the content of the media captures. The CLUE framework [I-D.ietf-clue-framework] recommends using one transport connection for each media type multiplexing using one RTP session. This also makes it simple to add and remove media capture by the consumer without a need for an [RFC3264] offer answer. The exception is if the consumer prefers using a separate RTP non multiplex session. In this case when adding or removing a media capture there will be a need to have also an offer answer session to specify the UDP port for the new RTP session or to close it. (note that ICE exchange may be required too). The open question is what should be done first, CLUE configuration or SDP offer/answer. As can be seen there is minimal duplication between SDP and these media capture attributes. There is a need to correlate between the RTP streams and media captures; this is discussed in CLUE RTP mapping [I-D.even-clue-rtp-mapping] When multiplexing RTP streams in a single RTP session there is probably no need for offer answer exchange when the consumer send a new configuration. 4. Encoding parameters A media capture can specify an encoding group that maps a media capture to encoding parameters. The encoding parameters are used to provide information about the ability of a CLUE endpoint to send streams. An encoding group is composed of individual encodes that may be used by a media capture to encode a stream as long as the total values of the attributes used by the individual encodes in the group do not exceed the group encode values. The individual encode parameters include: maxBandwidth, maxH264Mbps, maxWidth, maxHeight and maxFrameRate. The encoding group parameters include MaxGroupBandWidth, MaxGroupH264Mbps, and for video MaxBandWidth. Note that the use case is to provide information about the send capabilities of the provider. The max H264Mbps is H.264 specific and there is a similar parameters in RFC6184 [RFC6184] but in RFC6184signals the receiver capability. Even Expires April 24, 2013 [Page 4] Internet-Draft SDP offer/answer and CLUE relation October 2012 The maxFrameRate is similar to SDP framerate attribute, for maxWidth and MaxHeight there are similar parameters in [RFC6236]. All these parameters carried in SDP signal the receiver capability or requested mode. The maxBandwidth is similar to the SDP b=attribute and specifying group and individual values can be partially done using the session level and media level attributes. The major different again is that the b= attribute is used to describe receiver capability, maximum bandwidth it can receive. The Media capture encoding information and SDP attribute are similar but they indicate different types of limitations. While the Media capture attributes are sender encoding capabilities the SDP ones specify receiver capabilities. This is because of the different usage. The SDP attributes are used by the receiver to indicate what it can receive and decode. Still in H.264 the parameter sets are used to convey some of the above parameters (like width and height) and can be conveyed in SDP using sprop-parameter-sets or sprop-level- parameter-sets. In general the "sprop" attributes are used to convey sender capabilities. The RFC3264 [RFC3264] offer/answer is used by the receiver to limit or ask for a specific mode. Since the encoding parameters specify limits on the sending side it may look like there is no correlation problem. The next sections will look at the specific parameters and see if this assumption is correct. The CLUE maxBandWidth is limiting the maximum bandwidth that a sender will use. The receiver can ask for higher or lower bandwidth based on H.264 level or using the SDP "b" attribute. If asking for higher than the CLUE value will limit and is asking for lower value the SDP value will be the limiting factor. A change mid-call may happen for example because of congestion. The endpoint must be aware of both values. Note that bandwidth change using RTCP TMMBR [RFC5104] can occur. If the previous bandwidth was higher than the CLUE maxBandwidth and the new band width is lower the EP must use the lowest bandwidth. Since the bandwidth in the offer and answer provide information about receiver capabilities it means that if the value is changed by an intermediary like an SBC the sender will know that the receiver now have different value and act accordingly. The maxH264Mbps and maxFrameRate show similar behavior to maxBandwidth. The CLUE maxWidth and maxHeight as sender capability and the image attribute in SDP are both send and receive capability. The recommendation if for using RFC6236 to negotiate these values and not Even Expires April 24, 2013 [Page 5] Internet-Draft SDP offer/answer and CLUE relation October 2012 CLUE encoding. The maxH264Mbps and maxFrameRate can be sufficient to provide compute limitations on the encoder side. Conclusion - except for the maxWidth and maxHeight there is no problem between the SDP and CLUE encoding values as long as SDP attributes are used as receiver capabilities and the relation between the two protocols is defined. Changing SDP values will not require a change in CLUE advertisement or configuration and vice versa since these parameters signal maximum values and not exact values. 5. Acknowledgements place holder 6. IANA Considerations TBD 7. Security Considerations TBD. 8. References 8.1. Normative References [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. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 8.2. Informative References [I-D.even-clue-rtp-mapping] Even, R. and J. Lennox, "Mapping RTP streams to CLUE media captures", draft-even-clue-rtp-mapping-04 (work in progress), September 2012. [I-D.ietf-clue-framework] Even Expires April 24, 2013 [Page 6] Internet-Draft SDP offer/answer and CLUE relation October 2012 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-06 (work in progress), July 2012. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, February 2007. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008. [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011. [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, May 2011. Author's Address Roni Even Huawei Tel Aviv, Israel Email: roni.even@mail01.huawei.com Even Expires April 24, 2013 [Page 7]