Requirements for ControLling mUltiple streams for tElepresence (CLUE) signaling.
draft-cazeaux-clue-sip-signaling-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Stephane Cazeaux , Emmanuel Bertin | ||
| Last updated | 2012-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cazeaux-clue-sip-signaling-00
Network Working Group S. Cazeaux
Internet-Draft E. Bertin
Intended status: Informational France Telecom Orange
Expires: September 6, 2012 March 5, 2012
Requirements for ControLling mUltiple streams for tElepresence (CLUE)
signaling.
draft-cazeaux-clue-sip-signaling-00
Abstract
This document defines requirements relating to the design of CLUE
signaling. This document also proposes two alternative design
approaches the CLUE signaling.
Status of this Memo
This Internet-Draft is submitted to IETF 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 6, 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.
Cazeaux & Bertin Expires September 6, 2012 [Page 1]
Internet-Draft CLUE signaling requirements March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. CLUE signaling options . . . . . . . . . . . . . . . . . . . . 4
4.1. Option A: CLUE signaling based on SIP-SDP signaling . . . 5
4.1.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Transport and encoding choice . . . . . . . . . . . . 6
4.2. Option B: media capture selection in a separate
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Transport and encoding choice . . . . . . . . . . . . 8
4.3. Interoperability with legacy endpoints . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative references . . . . . . . . . . . . . . . . . . . 9
8.2. Informative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Cazeaux & Bertin Expires September 6, 2012 [Page 2]
Internet-Draft CLUE signaling requirements March 2012
1. Introduction
The framework defined for Telepresence Multi-Streams
[I-D.ietf-clue-framework] in the context of CLUE introduces the need
to have CLUE messages, conveying CLUE data, exchanged between
telepresence endpoints. It is necessary to agree upon signaling
protocol enabling these CLUE messages to be exchanged, taking into
account the existing SIP-SDP ecosystem.
This document first outlines signaling requirements to be met by the
CLUE protocol. Then the document proposes two possible approaches
for the design of this protocol.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119].
3. Requirements
The term of "solution" designates here the set of mechanisms that
allows endpoints to exchange CLUE related information.
REQ-1 The solution MUST enable the implementation of the CLUE
framework described in [I-D.ietf-clue-framework], in
particular : CLUE data model, provider/consumer exchange.
REQ-2 The solution MUST allow session establishment between two
Telepresence endpoints, and between a Telepresence endpoint
and a Multipoint Control Unit (MCU). The solution MUST
support the establishment of symmetrical or asymmetrical
media streams between the Telepresence endpoints (or MCU).
REQ-3 The solution MUST enable interoperability with SIP legacy
endpoints, without requiring intermediary protocol
translation systems. At a minimum, the solution MUST enable
interoperability with legacy SIP audio endpoints (one audio
media stream) and SIP video endpoints (one audio media
stream, zero or one main video media stream, zero or one
presentation video media stream, zero or one BFCP stream).
Cazeaux & Bertin Expires September 6, 2012 [Page 3]
Internet-Draft CLUE signaling requirements March 2012
REQ-4 The solution MUST enable interoperability with SIP legacy
endpoints, with a minimum number of offer-answer cycles.
REQ-5 The solution MUST NOT make any assumptions on the SIP
implementation level (besides [RFC3261]) of intermediary
systems that could be in the signaling path of a Telepresence
session (e.g. a Session Border Controller, SBC).
REQ-6 The solution MUST enable to discover whether a remote party
is CLUE-enabled or not.
REQ-7 The solution MUST rely on the SDP offer/answer model for any
CLUE data related to the definition of media streams. This
requirement in particular aims to enable intermediaries (such
as SBCs) to apply appropriate policies (e.g. QoS marking,
Bandwidth control ...), which require that SDP offers and
answers provide and accurate description of the actual media
streams.
REQ-8 The solution MUST enable to exchange data related to media
capture (description, spatial relations, etc.) and to select
media capture without dependency or impact on the negotiated
media streams (except that a media capture MUST refer to a
negotiated media stream).
REQ-9 The solution MUST take into account that a media capture
selection could result from the interaction with an end-user,
at any time during a session. The user interaction can
indeed occur between the provider capability advertisement
and the consumer selection, but also at any moment during the
established session.
REQ-10 The solution MUST NOT add new requirements regarding NAT
traversal compared to legacy video systems (NOTE : lesson
learned from BFCP over TCP).
REQ-11 The solution MUST be extensible in order to support future
evolution in a backward compatible manner.
Note that no requirement is placed regarding to the latency of the
CLUE messages exchanged between the provider and the consumer.
4. CLUE signaling options
Cazeaux & Bertin Expires September 6, 2012 [Page 4]
Internet-Draft CLUE signaling requirements March 2012
4.1. Option A: CLUE signaling based on SIP-SDP signaling
This option proposes an approach where the exchange of CLUE messages
between the provider and the consumer is based on the SDP O/A model
as specified in [RFC3264]. The SDP is used for the exchange of media
stream and media capture data.
4.1.1. Signaling
CLUE session establishment
A B
| |
|OPTIONS |
|----------------------------------->|
| 200 OK (SDP:cons-capB)|
|<-----------------------------------|
|INVITE (SDP-O1:ann-capA) |
|----------------------------------->|
| 200 OK (SDP-A1:conf-capB)|
|<-----------------------------------|
|ACK |
|----------------------------------->|
| |
| OPTIONS|
|<-----------------------------------|
|200 OK (SDP:cons-capA) |
|----------------------------------->|
| INVITE (SDP-O1:ann-capB+conf-capB)|
|<-----------------------------------|
|200 OK (SDP-A1:conf-capA+conf-capB) |
|----------------------------------->|
| ACK|
|<-----------------------------------|
Figure 1
cons-capX includes the capabilities of the consumer X.
ann-capX includes the capabilities announced by the provider X.
conf-capX includes the capabilities configured by the consumer X.
The first SDP offer/answer cycle enables the CLUE exchange between A
as provider and B as consumer. The second SDP offer/answer cycle
enables the CLUE exchange between A as consumer and B as provider.
This second SDP offer/answer cycle completes the first one, so that
Cazeaux & Bertin Expires September 6, 2012 [Page 5]
Internet-Draft CLUE signaling requirements March 2012
it can safely replace it.
It is worth noting that this option will not satisfy the requirements
following requirements:
REQ-8: this option requires a complete SDP offer/answer cycle to
change media capture selection, thus requires to re-negotiate
(even if not actually required) the media streams.
REQ-9: the transmission of a SDP answer cannot wait for a user
action more than what a SIP transaction timer allows.
4.1.2. Transport and encoding choice
In this option, the CLUE protocol is entirely based on the SDP offer/
answer model as described in [RFC3264]. Thus the transport protocol
for CLUE messages is SIP, and the encoding of CLUE messages is SDP.
4.2. Option B: media capture selection in a separate protocol
This option proposes an approach where the exchange of CLUE messages
between the provider and the consumer related to media stream is
based on the SDP offer/answer model as described in [RFC3264], and
the exchange of CLUE messages related to media captures is based on a
dedicated channel (named futher the CLUE channel).
Cazeaux & Bertin Expires September 6, 2012 [Page 6]
Internet-Draft CLUE signaling requirements March 2012
4.2.1. Signaling
CLUE session establishment
A B
| |
|INVITE (SDP-offer1) |
|------------------------------>|
| 200 OK (SDP-answer1)|
|<------------------------------|
|ACK |
|------------------------------>|
| |
| CLUE channel |
|<=============================>|
| |
|re-INVITE (SDP-offer2) |
|------------------------------>|
| 200 OK (SDP-Answer2)|
|<------------------------------|
|ACK |
|------------------------------>|
| |
Figure 2
SDP-offer1: This SDP provides the capabilities of A acting as a
consumer (what A can receive) under the form of the number and
characteristics of media streams that A is able to receive. This
SDP also provides the capabilities of A acting as a provider
(what A can send) which describe the characteristics A's media
streams . The characteristics of the media streams that A can
send include, among other: spatial relations, available media
captures. At this stage: A can receive and can send.
SDP-answer1: This SDP provides the capabilities of B as consumer. B
builds his SDP in response to the capabilities of A, meaning that
B will here define what it will receive according to A's
capabilities as provider. This SDP also provides the
capabilities of B as provider, here also in response to the
capabilities of A, meaning that B will define what it will send
to A. At this stage : B will receive and send, A will receive and
send.
After this SDP offer/answer cycle, A and B are able to send and
receive media through the media streams that have been
negotiated. Additionally, each entity (as consumer) know what
media captures can be sent by the remote provider. However, no
Cazeaux & Bertin Expires September 6, 2012 [Page 7]
Internet-Draft CLUE signaling requirements March 2012
media capture selection has been yet performed.
CLUE channel: The CLUE channel enables each consumer to perform
media content selection according to provider capabilities. It
is worth noting that any operation performed on this channel is
done in the context of the previous SDP offer-answer. The use of
this channel is optional. Without it, a consumer cannot perform
selection, thus the provider will adopt a default behavior in
terms of media content.
SDP-offer2 and SDP-answer2: Subsequent SDP offer/answer cycles may
occur, when A or B wishes to update his capabilities (add or
remove a media stream for instance).
This option should satisfy all requirements.
4.2.2. Transport and encoding choice
In this option, the solution is constituted of at least two protocol
elements.
The first protocol element aims to handle the CLUE media streams and
the advertisement of the CLUE media captures. For this part, the
transport protocol of CLUE messages is SIP, and the encoding is SDP.
The second protocol element (named hereafter the CLUE channel), aims
to handle the CLUE media capture configuration and selection. The
CLUE channel most likely relies on a separate protocol.
A possible design of the CLUE channel is to rely on the BFCP protocol
([RFC4582]) extended as defined in
[I-D.westerlund-dispatch-stream-selection].
4.3. Interoperability with legacy endpoints
To enable the interoperability with legacy endpoints, a CLUE-enabled
endpoint must be able to discover whether the remote endpoint is
CLUE-enabled or not. When the remote endpoint is not CLUE-enabled,
the telepresence endpoints must establish a session without using
CLUE extensions.
Two solutions are possible:
Solution 1: OPTIONS procedures are invoked before the first offer/
answer cycle between a consumer and a provider. The OPTIONS
procedure enables the provider to retrieve consumer capabilities
so as to be able to build an SDP Offer that is meaningful for the
consumer. This procedure is particularly useful to enable the
Cazeaux & Bertin Expires September 6, 2012 [Page 8]
Internet-Draft CLUE signaling requirements March 2012
provider to determine whether the consumer is CLUE-enabled or
not.
Solution 2: RFC5939 ([RFC5939]) is used. The SDP Offer sent by the
provider includes an "Actual Configuration" and one or more
"Potential Configurations". The "Actual Configuration"
corresponds to a basic mono-stream video call and can be
understood by any endpoint. One of the "Potential
Configurations" corresponds to a fully CLUE-compliant endpoint.
Other "Potential Configurations" may correspond to partially
compliant endpoint (e.g. multistream video without clue-specific
data).
The option A as defined in Section 4.1 relies on the solution 1, and
the option B as defined Section 4.2 relies the solution 2. However
it is worth noting that the the design of the solution to enable
interoperability with legacy is actually independent from the choice
of introducing a CLUE channel or not. In other terms, the option A
could also rely on the solution 2, and the option B on the solution
1.
5. Security Considerations
6. IANA Considerations
None.
7. Acknowledgements
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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
Cazeaux & Bertin Expires September 6, 2012 [Page 9]
Internet-Draft CLUE signaling requirements March 2012
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
8.2. Informative references
[I-D.ietf-clue-framework]
Romanow, A., Pepperell, A., Baldino, B., and M. Duckworth,
"Framework for Telepresence Multi-Streams",
draft-ietf-clue-framework-03 (work in progress),
February 2012.
[I-D.westerlund-dispatch-stream-selection]
Grondal, D., Burman, B., and M. Westerlund, "Media Stream
Selection (MESS)",
draft-westerlund-dispatch-stream-selection-00 (work in
progress), October 2011.
Authors' Addresses
Stephane Cazeaux
France Telecom Orange
42 rue des Coutures
Caen 14000
France
Email: stephane.cazeaux@orange.com
Emmanuel Bertin
France Telecom Orange
42 rue des Coutures
Caen 14000
France
Email: emmanuel.bertin@orange.com
Cazeaux & Bertin Expires September 6, 2012 [Page 10]