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]