Internet DRAFT - draft-even-clue-swithed-use-cases
draft-even-clue-swithed-use-cases
CLUE WG R. Even
Internet-Draft Huawei
Intended status: Informational June 11, 2012
Expires: December 13, 2012
CLUE switched and mixed captures use cases
draft-even-clue-swithed-use-cases-00.txt
Abstract
This document describes multi stream use cases using switched and
mixed streams. This document present the cases when using the
switched and mixed attributes with Boolean values may not provide the
best results.
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 December 13, 2012.
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 December 13, 2012 [Page 1]
Internet-Draft Switched use cases June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Even Expires December 13, 2012 [Page 2]
Internet-Draft Switched use cases June 2012
1. Introduction
The CLUE framework[I-D.ietf-clue-framework] defines "mixed" and
"composed" attributes for media captures. Both attributes have a
Boolean value. These attributes tell the receiver that the
advertised media captures are composed or switched and the content is
based on provider logic.
using only Boolean values can support basic point to point call
scenario and basic multipoint calls scenarios.
For example we may have a Telepresence three camera system
advertising four Capture Scene Entries (CSE).
Note: Left, center and right position for media capture is conveyed
using the point of capture and area of capture attributes.
(VC1 (Left camera), VC2 (middle Camera), VC3(Right Camera))
(VC4 (left), VC5(right))
(VC6 (Composed))
( VC7(switched))
On the consumer side a three monitor system may choose the first
capture scene entry; a two monitor system may choose the second CSE,
it may select VC1 and VC2 or even VC6 or VC7; a single monitor system
may choose VC6 or VC7 or decide to ask for VC2 for example.
In the centralized multipoint case the MCU may advertise the above
CSE allowing the consumer to have a similar selection as the point to
point case except that the first two CSE may have switched attribute
for all media captures in order to allow the MCU to send views
according to a defined policy.
Note : The MCU advertisement may define if MCU will do site switch or
segment switch using the scene-switch-policy attribute. In the site
switch case when the number of the media capturesbetween the source
and the receivers does not match it is up to the MCU to decide how to
handle the site switch case.
The current framework allows this basic set of interoperability.
Based on these CSEs, the consumer in a point to point call knows who
the source is (both the endpoint and the spatial information). In
the multipoint case the mapping for the mixed and switched media
captures content to RTP streams should be addressed by the RTP
Even Expires December 13, 2012 [Page 3]
Internet-Draft Switched use cases June 2012
mapping document. This should allow for a consumer to know whose
media he is currently receiving in each switched or mixed media
capture. The consumer can get a conference roster using the
conference event package. BTW: The MCU can add a text description in
each sub-window of the mixed stream presenting to the user readable
information about the source.
The attributes specified in the current
framework[I-D.ietf-clue-framework] without a capability message
requires the provider to advertise CSEs that can be used by what he
considers as typical TP systems (one to three or four camera/monitors
systems).
In the above case the consumer cannot control what will be the
content of the composed or switched media captures. The
advertisement will provides partial information that will enable the
consumer to render mixed views using multiple received streams based
on consumer logic.
Note: The current model allows the provider to update previous
advertisements and the consumer to ask for different configurations
from the active advertisement using the configure message. The
current model does not provide a way for the consumer to provide any
information about his system hardware and software capabilities (like
number of monitors, ability to mix multiple streams to render a
mixed/switched view). There is a capability message in the current
framework [I-D.ietf-clue-framework] but it is not specified and it
seems that there will be a consensus to remove it.
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. Use Cases
There is an interest from the CLUE WG members to look at advanced
cases where the consumer wants to get better control over the number
and content of the media captures. Some of the examples given
o A consumer's system may have more monitors than cameras, these
monitors can be used each as a single entity or the consumer would
like to group a couple of them to appear as one.
Even Expires December 13, 2012 [Page 4]
Internet-Draft Switched use cases June 2012
o The consumer's monitors may not be in a one row left to right
spatial order.
o The consumer wants to render multiple media captures to a single
or multiple monitors building his preferred layout.
o The consumer may have N monitors for main video and M monitors for
presentation where N+M is fixed while N and M can change for each
call or during a call.
The above examples represent part of the possible cases where the
consumer wants control over the content of the media captures and of
cases where the consumer provides more information to the provider
about his hardware and software capabilities.
The document will try to list such cases. Some of these cases can be
merged.
1. The provider offers multiple mixed captures. Currently the only
attribute has a Boolean value. The provider would like to
provide more information about the mixes content allowing the
consumer to select a relevant one.
2. The provider would like to offer only media captures that are
useful to the consumer. The simple case is based on the number
of available monitors for main video.
3. The consumer will provide more information about his preferences
for example the total number of monitors that can be used
dynamically for all types of media (number of speakers, number
of monitors for main or presentation video, the number of
simultaneous video streams that the consumer can decode ...).
The provider will advertise relevant CSEs that he can support to
address these preferences. It may be more than one option.
4. The MCU will offer mixed media captures (one or more) in one or
more CSEs. The consumer want to select how many sources are in
each mixed capture and how the layout should look. This will
allow each consumer to create a personal layout if the MCU
allows this functionality. The MCU is doing the actual mix in
the case.
5. The MCU will offer multiple media captures in one or more CSEs.
The consumer want to select who will be seen in each mixed
capture knowing the number of maximum media streams that can
compose the mix. This use cases adds to the previous one the
ability to control the policy by which streams are added or
removed from a mix.
Even Expires December 13, 2012 [Page 5]
Internet-Draft Switched use cases June 2012
6. The MCU will offer multiple switched media captures in one or
more CSEs. The consumer wants to define a switching policy for
each of the switched streams.
7. The MCU will offer multiple switched and mixed media captures in
one or more CSEs. The consumer would like to define the layouts
topology.
8. The MCU will offer multiple switched and mixed media captures in
one or more CSEs. The consumer would like to know what the
available layouts are and optionally define who is in each sub-
window of the layout by defining policy or by selecting specific
individuals.
9. The consumer would like to get multiple media captures and
create his own views. The media capture may be a switched
stream. The information available to the consumer should
include the identity of the stream and its spatial information
(example left camera from TPRoom1). The information should be
available when a switch occurs.
10. The consumer would like to define layouts to the provider to be
used for the media captures. The consumer accepts a mixed or
switched stream in each sub-window. The maximum number of
switched streams will be the number of sub-windows. The
consumer will need to know who is the current stream in a mixed
capture including his spatial information.
Things to consider.
o Which cases we want to support and why not to support the others.
o Are there more use cases.
o The current framework talks about adding attributes. It does not
talk about adding new message to the call flow. A new message may
be needed from the consumer to the provider to address this case
unless the configure message will be used for it which may require
adding a child element to the clue-info element from the data
model individual draft.
o These cases require more information from provider to consumer.
They also require the consumer to provide information to the
provider. At the February interim meeting it was suggested to
have this type of functionality in future extensions. Is this
still how we feel about it.
Even Expires December 13, 2012 [Page 6]
Internet-Draft Switched use cases June 2012
4. Acknowledgements
place holder
5. IANA Considerations
TBD
6. Security Considerations
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.ietf-clue-framework]
Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino,
"Framework for Telepresence Multi-Streams",
draft-ietf-clue-framework-05 (work in progress), May 2012.
Author's Address
Roni Even
Huawei
Tel Aviv,
Israel
Email: even.roni@huawei.com
Even Expires December 13, 2012 [Page 7]
