[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/