Internet DRAFT - draft-groves-clue-latent-config
draft-groves-clue-latent-config
CLUE C. Groves, Ed.
Internet-Draft W. Yang
Intended status: Informational R. Even
Expires: July 30, 2014 Huawei
January 26, 2014
CLUE and latent configurations
draft-groves-clue-latent-config-00
Abstract
This document proposes to use Latent Configurations as described by
the SDP media capability negotiation framework [RFC6871] for the
description and negotiation of CLUE encodings.
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 July 30, 2014.
Copyright Notice
Copyright (c) 2014 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.
Groves, et al. Expires July 30, 2014 [Page 1]
Internet-Draft CLUE and latent config January 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Latent Configurations and CLUE . . . . . . . . . . . . . . . 3
2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Returning an Answer . . . . . . . . . . . . . . . . . . . 5
2.5. Interworking . . . . . . . . . . . . . . . . . . . . . . 5
2.6. Relation to BUNDLE . . . . . . . . . . . . . . . . . . . 6
2.7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 6
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
One of the issues faced in CLUE is how to describe the encodings
associated with the Advertised Captures. It was recently decided
that this encoding information would not be described in CLUE itself.
This means that other methods such as the use of SDP are required to
transmit this encoding information. When considering the use of SDP
(and in particular the use of SDP Offer/Answer) it should be
recognized that there is a semantic difference between a CLUE
encoding and an SDP media stream description. Given the nature of a
CLUE exchange the encoding represents a Capture/Stream that may occur
in the future (i.e. no resources are reserved) whereas a SDP Offer
typically relates to resources that are available at that point in
time. This does lead to complications when trying to describe CLUE
encodings using standard SDP O/A mechanisms.
An alternate approach to using the standard SDP O/A mechanisms for
describing CLUE encodings is to use the "SDP Capability Negotiation
framework" [RFC5939] and in particular to use the SDP Media
Capabilities Negotiation [RFC6871]. [RFC6871] defines "Latent
Configurations" as a means to describe media streams that may be used
in the future.
Groves, et al. Expires July 30, 2014 [Page 2]
Internet-Draft CLUE and latent config January 2014
2. Latent Configurations and CLUE
The sections below discuss different aspects and benefits of using
Latent Configurations to describe CLUE encodings.
2.1. Semantics
[RFC6501] defines a Latent Configuration as:
A latent configuration indicates which combinations of
capabilities could be used in a future negotiation for the
session and its associated media stream components. Latent
configurations are neither ready for use nor offered for actual
or potential use in the current offer/answer exchange. Latent
configurations merely inform the other side of possible
configurations supported by the entity. Those latent
configurations may be used to guide subsequent offer/answer
exchanges, but they are not offered for use as part of the
current offer/answer exchange.
From the above description it can be seen that the semantic of a
Latent Configurations closely matches a CLUE message flow. I.e. A
set of possible Captures/Encodings (e.g. configurations) are
Advertised, the receiver can choose particular Captures/Encodings and
then the actual media stream is subsequently established. Therefore
the authors believe that use of latent configurations is a good
semantic fit with CLUE to describe the encodings.
2.2. Messaging
It has been recognized that CLUE Advertisements may contain a large
number of Captures and as there may be multiple encodings per capture
potentially a larger number of encodings.
Section 4.2 of CLUE signaling draft [I-D.kyzivat-clue-signaling]
indicates the CLUE Provider uses an "m" line for each separate
encoding and utilizes the "a=inactive", "a=sendonly" and "a=recvonly"
to manage when the media flows are instantiated.
This means that ports must be allocated for these "m" lines and the
SDP Offer/Answer [RFC3264] rules regarding maintaining these "m"
lines must be followed.
This results in potentially very large SDP descriptions containing
superfluous information that must be maintained for the life of the
session.
Groves, et al. Expires July 30, 2014 [Page 3]
Internet-Draft CLUE and latent config January 2014
Latent Configurations allow a Provider to advertise potential media
without allocating multiple "m" lines or allocating ports for the
configurations. The SDP O/A model doesn't apply to Latent
Configurations which means that less data is sent over the life of a
session.
This allows a Provider to offer a basic media stream for immediate
use (i.e. an audio "m" line) and a list of latent configurations for
later use without the need for additional m-lines. This is described
by [RFC6871]:
A new attribute ("a=lcfg") specifies latent media stream
configurations when no corresponding media line ("m=") is
offered. An example is the offer of latent configurations for
video even though no video is currently offered. If the peer
indicates support for one or more offered latent configurations,
the corresponding media stream(s) may be added via a new offer/
answer exchange.
AND
The "lcfg" attribute is defined as a media-level attribute since
it specifies a possible future media stream. However, the "lcfg"
attribute is not necessarily related to the media description
within which it is provided. Each media line in an SDP
description represents an offered simultaneous media stream,
whereas each latent configuration represents an additional stream
that may be negotiated in a future offer/answer exchange.
The use of Latent Configurations also means that resources aren't
tied up and can be allocated when they are needed. i.e. from
[RFC6871]:
A latent configuration represents a future capability; hence, the
"pt=" parameter is not directly meaningful in the "lcfg"
attribute because no actual media session is being offered or
accepted. It is permitted in order to tie any payload type
number parameters within attributes to the proper media format.
Therefore the authors believe that Latent Configurations provide a
clear benefit in terms of messaging size and complexity over normal
SDP Offer/Answer mechanism for Advertising CLUE encodings.
2.3. Correlation
One of the issues recognized in the CLUE work it that there needs to
be a correlation between the Captures signaled in CLUE and the
encodings defined in SDP. The encoding identity (EncodeID) is used
Groves, et al. Expires July 30, 2014 [Page 4]
Internet-Draft CLUE and latent config January 2014
as an identity in CLUE. This same identity is then assigned to the
encoding in SDP. Currently [I-D.kyzivat-clue-signaling] indicates
that the label attribute [RFC4574] is used to identify the encoding
and that it is set per "m" line.
This same method can be used with Latent configurations as they allow
the use of SDP attributes in the configurations' description.
Section 3.3.8/[RFC6871] shows an example of the use of "label" with a
latent configuration, e.g.
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=acap:41 label:13
a=acap:42 content:slides
The use of Latent Configurations does not require any new SDP
attributes to be defined in order for it to be used for CLUE
encodings.
2.4. Returning an Answer
A consumer upon receiving an SDP Offer containing CLUE related latent
configurations from the Provider could immediately send an SDP answer
with the configurations that it could support, i.e. section 3.3.6.1/
[RFC6871]:
Potential and/or latent configuration attributes may be returned
within an answer SDP to indicate the ability of the answerer to
support alternative configurations of the corresponding
stream(s).
The consumer would then send a CLUE Configure indicating the Capture
Encodings it wants. The Provider can then subsequently offer actual
media streams for the encodings.
2.5. Interworking
One aspect to be considered is the level of adoption of the SDP media
capabilities negotiation framework in network entities. Whilst the
framework is not widely deployed it is supported by 3GPP (e.g.
[SDO-3GPP.24.292]) and is supported by the ITU-T (e.g.
[ITU.H248.80.2014] and [ITU.T38.2010].
It must also be recognized that CLUE itself is something completely
new and clients and network equipment must be upgraded to support
CLUE signaling. Thus this equipment could also be upgraded to
support Latent Configurations at the same time.
Groves, et al. Expires July 30, 2014 [Page 5]
Internet-Draft CLUE and latent config January 2014
In cases where a CLUEfull client sends SDP requesting a CLUE channel
and a number of latent configurations to a client that doesn't
support CLUE or the media capability framework, the receiving client
will ignore the attributes associated with the latent configuration
as per normal SDP behavior. Thus there are no interworking issues in
this case.
In cases where a CLUEfull client sends SDP requesting a CLUE channel
and a number of latent configurations to a client that doesn't
support CLUE but DOES support the media capability framework, the
receiving client would ignore the CLUE related attributes but could
respond with what latent configurations it could support. This would
allow the sender to decide if it wanted to offer subsequent media
streams. Again there are no interworking issues in this case.
In either of the above cases the session between the clients wouldn't
be forced to maintain "m" lines for media that would never be used.
2.6. Relation to BUNDLE
At its core BUNDLE is about using SDP to describe that several "m"
lines use the same IP Address/Port for the transport of RTP media.
If SDP O/A is being used to describe CLUE encodings then there is a
potential interaction in that the CLUE encoding "m" lines would all
be subject the BUNDLE procedures whether or not they were actually
used for media.
The use of Latent Configurations would simplify this interaction
because Latent Configurations do not allocate or specify ports. They
would not be subject to BUNDLE procedures. Once the use of BUNDLE is
established (i.e. for the base media streams), then only the media
streams (Capture Encodings) that have been chosen by the Consumer can
be added to the BUNDLE.
2.7. Open Issues
There are several issues that need to be clarified in [RFC6871] with
respect to latent configurations.
1. Latent configurations are specified as media level attributes and
thus may be associated with any m-line in an SDP O/A as they
don't really pertain to a particular media. There appears to be
no guidance as to with m-line they should be associated with in
the case of multiple m-line in a SDP Offer.
2. It's not clear from [RFC6871] what happens to latent
configurations when an endpoint decides to instantiate the latent
configuration as an m-line through an updated SDP Offer.
Groves, et al. Expires July 30, 2014 [Page 6]
Internet-Draft CLUE and latent config January 2014
Section 3.4.4/[RFC6871] discusses modifying the session but has
minimal information. It is assumed by the authors that the
latent configuration is removed once instantiated.
3. It needs to be clarified whether [RFC6871] indicates that the SDP
Answerer SHOULD reply with the latent configurations it supports
or whether this is optional. If it's optional what does it mean?
4. [RFC6871] allows an SDP Answerer to reply with additional latent
configurations. However it doesn't specify what action the SDP
Offerer should take. This needs to be clarified.
3. Example
This section describes an example session establishment utilizing
CLUE and latent configurations. The Provider offers a base audio
stream, a CLUE channel (according to [I-D.ietf-mmusic-sctp-sdp] and
several latent configurations related to video captures.
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0 ; Base audio stream
a=rtpmap:0 PCMU/8000
; CLUE channel establishment request
m=application 49172 SCTP 49172
a=setup:actpass
a=connection:new
a=sctpmap:49172 CLUE 1
;Offered configurations
a=rmcap:1 H264/90000 ; this is needed for the m=
a=rmcap:2 VP8/90000
a=tcap:1 RTP/AVPF ; for the t=
a=acap:5 sendonly
a=acap:1 label:encoding1
a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100,2:101
a=acap:2 label:encoding2
a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102,2:103
a=acap:3 label:encoding3
a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104,2:105
a=acap:4 label:encoding4
a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106,2:107
Figure 1: Initial Offer
Groves, et al. Expires July 30, 2014 [Page 7]
Internet-Draft CLUE and latent config January 2014
The receiver is CLUE capable and responds indicating support of the
CLUE channel and indicates the IP Address/Port where the Provider
should establish a connection to. It also indicates that it only
supports H264 encoding.
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
; Accepted SCTP CLUE connection
m=application 54321 SCTP 54321
c=IN IP4 192.0.2.1
a=setup:passive
a=connection:new
a=sctpmap:54321 CLUE 1
;Accepted configurations
a=rmcap:1 H264/90000 ; this is needed for the m=
a=tcap:1 RTP/AVPF ; for the t=
a=acap:5 sendonly
a=acap:1 label:encoding1
a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100
a=acap:2 label:encoding2
a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102
a=acap:3 label:encoding3
a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104
a=acap:4 label:encoding4
a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106
Figure 2: Answer
Author's note: In the signaling document the grouping framework
[RFC5888] is used to indicate the "m" lines that are under CLUE
control. It's not clear whether a=group:CLUE and a=mid is needed at
this stage or during the updated-Offer. It could be assumed that the
above latent configurations are related to CLUE due to the fact they
appear under the m=application SCTP/CLUE line.
On receipt of the SDP Answer the Provider establishes the SCTP
connection, performs CLUE version and capability negotiation (not
shown) and then sends the initial CLUE Advertisement. In it the
Provider advertises a single Capture Scene described by three video
captures (i.e. Left,Centre,Right) or a video capture of the entire
scene.
Groves, et al. Expires July 30, 2014 [Page 8]
Internet-Draft CLUE and latent config January 2014
Author's note: According to the current CLUE protocol work
[I-D.presta-clue-protocol], it's the consumer that sends the first
Advertisement. The author believes that the Provider should send the
first Advertisement to align with the Offer.
+-----------------------|---------------------------------+
| Capture Scene #1 | |
+-----------------------|---------------------------------+
| VC1 | CaptureArea=Left |
| | EncodingGroup=EG1 |
| VC2 | CaptureArea=Centre |
| | EncodingGroup=EG2 |
| VC3 | CaptureArea=Right |
| | EncodingGroup=EG3 |
| VC4 | CaptureArea=All |
| | EncodingGroup=EG4 |
| CSE(VC1,VC2,VC3) | |
| CSE(VC4) | |
+-----------------------|---------------------------------+
| EncodingGroups | |
+-----------------------|---------------------------------+
| EG1 | EncodeID=encoding1 |
| EG2 | EncodeID=encoding2 |
| EG3 | EncodeID=encoding3 |
| EG4 | EncodeID=encoding4 |
+=======================+=================================+
Figure 3: Advertisement
On receipt of the Advertisement the Consumer determines that it wants
the three video captures representing left/centre/right. It sends a
CLUE Configure to the Provider:
+-----------------------+---------------------------------+
| VC1 | encoding1 |
| VC2 | encoding2 |
| VC3 | encoding3 |
+-----------------------|---------------------------------+
Figure 4: Configure
On receipt of the CLUE Configure the Provider determines that the
Consumer wants to see VC1, VC2 and VC3 according to encoding1,
encoding2 and encoding3 respectively. The Provider then issues an
updated SDP Offer for three additional video streams. Note: The
latent configurations have been removed but the latent configuration
related to VC4/encoding4 could also be maintained if still available.
Groves, et al. Expires July 30, 2014 [Page 9]
Internet-Draft CLUE and latent config January 2014
The grouping framework [RFC5888] is used to indicate that the
additional video streams are under CLUE control.
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
a=group:CLUE 1 2 3
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0 ; Base audio stream
a=rtpmap:0 PCMU/8000
; CLUE channel estab. Req.
m=application 49172 SCTP 49172
a=setup:actpass
a=connection:new
a=sctpmap:49172 CLUE 1
;Additional video streams
m=video 49174 RTP/AVPF 100
a=rtpmap:100 H264/90000
a=label:encoding1
a=mid:1
a=sendonly
m=video 49176 RTP/AVPF 102
a=rtpmap:102 H264/90000
a=label:encoding2
a=mid:2
a=sendonly
m=video 49178 RTP/AVPF 104
a=rtpmap:104 H264/90000
a=label:encoding3
a=mid:3
a=sendonly
Figure 5: Updated Offer
The Consumer then receives the Updated Offer and confirms with an
updated Answer. Media flow for the 3 video streams then starts to
flow.
Groves, et al. Expires July 30, 2014 [Page 10]
Internet-Draft CLUE and latent config January 2014
4. Summary
The authors believe that the use of Latent Configurations is an ideal
way to indicate CLUE encoding information. It is proposed that the
use of Latent Configuration is the preferred way of describing CLUE
encoding information.
5. Acknowledgements
This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.
6. IANA Considerations
It is not expected that the proposed changes present the need for any
IANA registrations.
7. Security Considerations
It is not expected that the proposed changes present any addition
security issues to the current framework.
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.
8.2. Informative References
[I-D.ietf-mmusic-sctp-sdp]
Loreto, S. and G. Camarillo, "Stream Control Transmission
Protocol (SCTP)-Based Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-05
(work in progress), October 2013.
[I-D.kyzivat-clue-signaling]
Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE
Signaling", draft-kyzivat-clue-signaling-05 (work in
progress), September 2013.
[I-D.presta-clue-protocol]
Presta, R. and S. Romano, "CLUE protocol", draft-presta-
clue-protocol-03 (work in progress), November 2013.
Groves, et al. Expires July 30, 2014 [Page 11]
Internet-Draft CLUE and latent config January 2014
[ITU.H248.80.2014]
International Telecommunications Union, "Usage of the
revised SDP offer / answer model with H.248", ITU-T
Recommendation H.248.80, 2014.
[ITU.T38.2010]
International Telecommunications Union, "Procedures for
real time Group 3 facsimile communication between
terminals using IP Networks", ITU-T Recommendation T.38,
2010.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
[RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session
Description Protocol (SDP) Media Capabilities
Negotiation", RFC 6871, February 2013.
[SDO-3GPP.24.292]
3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
Centralized Services (ICS); Stage 3", 3GPP TS 24.292
10.11.0, June 2013.
Authors' Addresses
Christian Groves (editor)
Huawei
Melbourne
Australia
Email: Christian.Groves@nteczone.com
Weiwei Yang
Huawei
P.R.China
Email: tommy@huawei.com
Groves, et al. Expires July 30, 2014 [Page 12]
Internet-Draft CLUE and latent config January 2014
Roni Even
Huawei
Tel Aviv
Isreal
Email: roni.even@mail01.huawei.com
Groves, et al. Expires July 30, 2014 [Page 13]
