Internet DRAFT - draft-groves-perc-clue

draft-groves-perc-clue







PERC                                                      C. Groves, Ed.
Internet-Draft                                                   W. Yang
Intended status: Informational                                   R. Even
Expires: April 18, 2016                                           Huawei
                                                        October 16, 2015


                        Usage of CLUE with PERC
                       draft-groves-perc-clue-00

Abstract

   This document provides an initial discussion of the relationship
   between PERC and CLUE.  It seeks to identify any potential impacts
   or/and enhancement to the way that CLUE is used in the PERC
   architecture.

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 18, 2016.

Copyright Notice

   Copyright (c) 2015 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 April 18, 2016                 [Page 1]

Internet-Draft           Usage of CLUE with PERC            October 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  CLUE Background . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  CLUE Relation to PERC . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Topology  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Media manipulation  . . . . . . . . . . . . . . . . . . .   7
     4.3.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  Encodings . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Mapping RTP streams to CLUE media captures  . . . . . . .   8
     4.6.  Others? . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Potential CLUE enhancements . . . . . . . . . . . . . . . . .   9
     5.1.  Encrypted CLUE information  . . . . . . . . . . . . . . .   9
     5.2.  Others? . . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   OThe PERC working charter specifically mentions that the solution for
   PERC should:

       "be implementable by both SIP (RFC3261) and WebRTC endpoints [I-
       D.ietf-rtcweb-overview].  How telepresence endpoints using the
       protocols defined in the CLUE working group could utilize the
       defined security solution needs to be considered.  However, it is
       acknowledged that limitations may exist, resulting in restricted
       functionality or need for additional adaptations of the CLUE
       protocols."

   It also indicates that work for documenting the model for integrating
   PERC with based with the establishment of CLUE conferences needs to
   be performed.

   This draft provides some initial information to address both these
   areas.








Groves, et al.           Expires April 18, 2016                 [Page 2]

Internet-Draft           Usage of CLUE with PERC            October 2015


2.  Requirements Language

   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] when they
   appear in ALL CAPS.  These words may also appear in this document in
   lower case as plain English words, absent their normative meanings.

3.  CLUE Background

   The CLUE protocol framework [I-D.ietf-clue-framework] effectively is
   a means of sending metadata about media captures and encodings
   between a Providing Endpoint and a Consuming Endpoint.  The CLUE
   protocol is transmitted using a WebRTC Datachannel
   [I-D.ietf-clue-datachannel] meaning that any SRTP based mechanisms
   for encrypting this metadata cannot be used.

   The information that can be sent regarding media captures is
   summarized below:

       - Spatial information, including point of capture, point on line
       of capture, area of capture, mobility of capture and audio
       capture sensitivity pattern;

       - Descriptive information, including a human readable
       description, indication of presentation, field of view type and
       language;

       - Person information, including the role of the person and xCard
       description;

       - Miscellaneous information, including whether text is embedded
       or a relation to other captures.

   It is possible for providers through the Multi-Content Capture (MCC)
   mechanism to provide the information about the individual
   contributing sources.  It can provide the switching policy as well as
   synchronization information.

   Information about the overall "Scene" may also be provided including
   views, human readable descriptions, xCard and scale information.

   Using the CLUE protocol information the Consuming endpoint can then
   choose what media captures and encodings that it would like to
   receive through the use of CLUE and SIP/SDP signalling.  Media is
   typically provided through SRTP.  Figure 2 /
   [I-D.ietf-clue-framework] highlights the basic call flow.  Figure 1
   below provides a copy of this flow.



Groves, et al.           Expires April 18, 2016                 [Page 3]

Internet-Draft           Usage of CLUE with PERC            October 2015


            +-----------+                     +-----------+
            | Endpoint1 |                     | Endpoint2 |
            +----+------+                     +-----+-----+
                 | INVITE (BASIC SDP+CLUECHANNEL)   |
                 |--------------------------------->|
                 |    200 0K (BASIC SDP+CLUECHANNEL)|
                 |<---------------------------------|
                 | ACK                              |
                 |--------------------------------->|
                 |                                  |
                 |<################################>|
                 |     BASIC SDP MEDIA SESSION      |
                 |<################################>|
                 |                                  |
                 |    CONNECT (CLUE CTRL CHANNEL)   |
                 |=================================>|
                 |            ...                   |
                 |<================================>|
                 |   CLUE CTRL CHANNEL ESTABLISHED  |
                 |<================================>|
                 |                                  |
                 | ADVERTISEMENT 1                  |
                 |*********************************>|
                 |                  ADVERTISEMENT 2 |
                 |<*********************************|
                 |                                  |
                 |                      CONFIGURE 1 |
                 |<*********************************|
                 | CONFIGURE 2                      |
                 |*********************************>|
                 |                                  |
                 | REINVITE (UPDATED SDP)           |
                 |--------------------------------->|
                 |              200 0K (UPDATED SDP)|
                 |<---------------------------------|
                 | ACK                              |
                 |--------------------------------->|
                 |                                  |
                 |<################################>|
                 |   UPDATED SDP MEDIA SESSION      |
                 |<################################>|
                 |                                  |
                 v                                  v

                   Figure 1: CLUE Basic Information Flow

   Whilst CLUE is a point to point protocol it may be used in
   conferences containing multipoint control units (MCU)s.  In this



Groves, et al.           Expires April 18, 2016                 [Page 4]

Internet-Draft           Usage of CLUE with PERC            October 2015


   scenario the MCU acts as an aggregation point for CLUE information.
   That is the MCU receives ADVERTISEMENT messages received from
   multiple endpoints before deciding on the contents of the
   ADVERTISEMENT that it wishes to send.  Likewise the MCU will use
   received CONFIGURE messages to decide what the contents of its
   CONFIGURE messages will be.  In doing so the MCU may apply any local
   policy / provisioning information to its decisions.  Figure 2
   illustrates this CLUE signalling.  The SIP/SDP signalling is omitted
   for brevity.

   +-----------+     +-----------+     +-----------+    +-----------+
   | Endpoint1 |     | Endpoint2 |     | MCU       |    | Endpoint3 |
   +----+------+     +----+------+     +-----+-----+    +-----+-----+
        | ADVERTISEMENT 1 |                  |                |
        |***********************************>|                |
        |                 | ADVERTISEMENT 2  |                |
        |                 |*****************>|                |
        |                 |                  | ADVERTISEMENT 3|
        |                 |                  |***************>|
        |                 |                  | CONFIGURE 1    |
        |                 |                  |<***************|
        | CONFIGURE 2     |                  |                |
        |<***********************************|                |
        |                 | CONFIGURE 3      |                |
        |                 |<*****************|                |
        | MEDIA FLOW      |                  |                |
        |***********************************>|                |
        |                 | MEDIA FLOW       |                |
        |                 |*****************>|                |
        |                 |                  | MEDIA FLOW     |
        |                 |                  |***************>|


                          Figure 2: CLUE MCU Flow

   Figure 2 shows a unidirectional media flow to Endpoint3.  A bi-
   directional media flow would be enabled by Endpoint3 providing an
   ADVERTISEMENT to the MCU and the MCU providing ADVERTISEMENTS to
   Endpoint1 and Endpoint2.  Endpoint1 and Endpoint2 would then also
   send CONFIGURE messages to the MCU and the MCU would send a CONFIGURE
   message to Endpoint3.

   Thus the selection of a particular Media Capture and Encoding
   (Capture Encoding) by the endpoints drives what topology occurs at
   the MCU.  However there is a caveat.  The MCU could apply filtering
   of the CLUE metadata to provide a sub-set of the data or append its
   own data.  For example it may decide that rather than offer the




Groves, et al.           Expires April 18, 2016                 [Page 5]

Internet-Draft           Usage of CLUE with PERC            October 2015


   source audio from Endpoint1 and Endpoint2 as individual streams, it
   will offer a mix of these two sources, as individual streams.

4.  CLUE Relation to PERC

   As detailed in the charter, the goal of the PERC WG is to:

       "...work on a solution that enables centralized SRTP-based
       conferencing, where the central device distributing the media is
       not required to be trusted with the keys to decrypt the
       participants' media.  The media must be kept confidential and
       authenticated between an originating endpoint and the explicitly
       allowed receiving endpoints or other devices.  The meta
       information provided to the central device is to be limited to
       the minimal required for it to perform its function to preserve
       the conference participant's privacy."

   As described above CLUE largely provides metadata (or meta
   information) so the task is to identify the minimal set of CLUE data
   required for CLUE to still work.  It also needs to be considered the
   limited functionality of a media distribution device (MDD) as
   compared to an MCU.

   In broad terms the initial PERC drafts propose a solution where there
   are two sets of encryption keys, one for the end-to-end (e2e) session
   and another for the transport connection (i.e. between the endpoint
   and MDD).  SRTP extensions are required to carry the e2e encrypted
   data.  The concept of a key management function (KMF) is also
   introduced which receives information about the call and the
   endpoints (as per 8.1/[I-D.jones-perc-private-media-framework] ).
   The KMF is the element that the endpoints trust it provides
   cryptographic keys and authenticates media content.  See 6.1 /
   [I-D.jones-perc-private-media-reqts].

   So far only SRTP media has been considered by PERC.  As the MDD does
   not have access to the un-encrypted media stream it can only provide
   switching topologies (e.g.  Media Switch, Selective Forwarding Unit,
   Transport Translator/ Transport Relay?,
   [I-D.ietf-avtcore-rtp-topologies-update]).

   These aspects have some implications on the use of CLUE.

4.1.  Topology

   As noted in the background section the selection of particular
   captures and encodings by endpoints effectively dictates what
   topology occurs at the MCU/MDD.  Therefore where a CLUE enabled MDD
   receives an indication that an encoding requires the use of PERC, the



Groves, et al.           Expires April 18, 2016                 [Page 6]

Internet-Draft           Usage of CLUE with PERC            October 2015


   MDD must ensure that in any subsequent ADVERTISEMENTs and SIP/SDP
   offers it sends, that the capture encoding is an unmixed local source
   (i.e. doesn't use a MCC indicating a MDD local composition of remote
   sources).  This would be a mismatch in capabilities as the MDD is
   unable to mix SRTP streams.

   Whilst the MDD may utilise the MCC mechanism to indicate that a
   particular capture encoding may represent multiple sources, the
   MaxCaptures attribute (section 7.2.1.1/[I-D.ietf-clue-framework])
   should be set to <=1 or 1 to indicate that only switching is used.
   Other MaxCapture values indicate the potential use of composed (thus
   mixed) capture encodings.

   A MCC Policy attribute (section 7.2.1.2/[I-D.ietf-clue-framework])
   may also be included.  It allows the indication of a "SoundLevel"
   policy that indicates that the content of the capture encoding is
   determined by a sound level detection algorithm.  As a PERC enabled
   MDD cannot access the SRTP media the "SoundLevel" policy should not
   be used unless the endpoint indicates the use of an unencrypted or
   hop by hop mechanism (e.g. utilising [RFC6464]) for sound level
   detection.

4.2.  Media manipulation

   Given that the PERC enabled MDD cannot access the encrypted media, it
   cannot filter possible media content.  For example an endpoint may
   indicate that the media capture contains embedded text (clause
   7.1.1.13/[I-D.ietf-clue-framework]) information.  It has no mechanism
   to filter out (e.g. by removing part of the image, or text signaled
   associated with audio) or to confirm text is being sent.  Therefore
   the MDD can either only remove the capture from being ADVERTISED or
   pass the embedded text attribute without modification.

   A CLUE enabled MDD has the ability of adding its own captures and
   encodings to ADVERTISEMENTS.  PERC enabled consumers should determine
   if the encoding associated with the advertised captures contains the
   correct key/fingerprint information as distributed by the KMF before
   requesting the capture encoding via a CONFIGURE.  This is a similar
   consideration as for non-CLUE endpoint responding with an SDP Answer.

4.3.  Privacy

   The CLUE framework allows the sending of potentially private
   information to the MCU.  Participant and endpoint information via the
   xCard [RFC6351] format may be provided. xCard can contain address,
   contact, company, images and audio information.  Whilst this
   information does not compromise the encrypted media it does provide
   information about the persons generating it.



Groves, et al.           Expires April 18, 2016                 [Page 7]

Internet-Draft           Usage of CLUE with PERC            October 2015


   CLUE also allows the definition of extensions so there may be
   proprietory extensions that may also contain potentially senstive
   information.

   As indicated in the PERC WG charter meta information provided to the
   central device is to be limited to the minimal required for the MDD
   to perform its function.  This may potentially result in an CLUE
   endpoint significantly reducing the amount of metadata it sends in
   ADVERTISEMENTS.  This would result in decreased information for
   CONSUMERs to decide which captures to consumer.  This may lead to a
   decreased telepresence user experience.

4.4.  Encodings

   CLUE itself carries little encoding information other than encoding
   groups with indicate which encodings are linked (and the maxmimum bit
   rate) and encodingIDs of the individual encodings.  The encodingIDs
   provide a link to the actual encoding information provided through
   SIP/SDP.  The SDP utilizes the "a=group" and "a=mid" mechanism to
   reference the CLUE encodingIDs thus providing a linkage between CLUE
   and SDP.

   It is expected that any indication of the use of PERC for SRTP
   streams will be signaled through SDP.  Therefore a CLUE enabled
   endpoint is not required to change any CLUE based encoding
   information to use PERC.

4.5.  Mapping RTP streams to CLUE media captures

   In order to associate RTP media with a particular CLUE capture
   encoding [I-D.ietf-clue-rtp-mapping] defines a RTP header extension
   and a RTCP SDES item both containing a CaptureID.  The draft
   indicates for mapping an RTP stream to a specific MC in the MCC the
   CLUE the media sender MUST send for MCC the captureID in the RTP
   header and as a RTCP SDES message.

   If an MDD produces or modifies MCCs (in particular the individual
   source CaptureIDs) as per section 4.1 above, then it may need to
   potentially modify the received source RTP/RTCP captureIDs to match
   the CLUE MCC before sending RTP/RTCP.  In the case of voice activated
   switching, the MDD should also send the relevant RTP/RTCP captureID.

   Therefore any PERC solution should ensure that the MDD may have
   access to and the ability to send RTP/RTCP captureID.







Groves, et al.           Expires April 18, 2016                 [Page 8]

Internet-Draft           Usage of CLUE with PERC            October 2015


4.6.  Others?

   TBD

5.  Potential CLUE enhancements

   CLUE has a defined extension mechanism (see section 8/[ID.ietf-clue-
   protocol]).  The use of any enhancements related to PERC could be
   negotiated through this mechanism.

5.1.  Encrypted CLUE information

   In order to limit the amount of metadata available to the MDD but
   still allowing the full use of CLUE, CLUE could be enhanced to carry
   encrypted data that is associated with a capture/scene but is not
   available to an MDD.  This would be similar to the proposed solution
   for SRTP.  The KMF could be enhanced to provide keys to the endpoints
   to access this CLUE encrypted data to make decisions on which capture
   encodings to CONFIGURE.

   In a PERC environment the endpoints are responsible for stream
   selection and any composition and thus they should have access to the
   full capture and scene metadata provided by the other endpoints in a
   conference.  A MDD that switches streams doesn't need access to this
   metadata as it should not make decisions regarding the forwarding of
   streams based on the content/characteristics of the stream.
   Accordingly the MDD only strictly needs a CaptureID and the encoding
   information in order to switch streams.  CLUE capture attributes,
   capture scene, simultaneous set and people information may be
   encrypted and passed through the MDD.  This is due to the fact that a
   CONFIGURE only contains a CaptureID and an associated EncodingID.
   It's the CONFIGURE message that determine which capture encoding an
   endpoint sends.

   The syntax below in figure 3 provides a conceptual illustration of
   the clear and encrypted parts of a CLUE ADVERTISEMENT utilising the
   example from section 10.1 / [ID.ietf-clue-protocol]:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<advertisement xmlns="urn:ietf:params:xml:ns:clue-protocol"
               xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
               xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
               protocol="CLUE" v="0.4">
 <clueId>Napoli</clueId>
 <sequenceNr>45</sequenceNr>
 <mediaCaptures>
 <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ns2:videoCaptureType"  captureID="AC0" mediaType="video">



Groves, et al.           Expires April 18, 2016                 [Page 9]

Internet-Draft           Usage of CLUE with PERC            October 2015


            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
            <ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
           /**************** Encrypted contents **************/
 <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC0">
            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
            /**************** Encrypted contents **************/
        </ns2:mediaCapture>
 <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC1">
            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
            /**************** Encrypted contents **************/
        </ns2:mediaCapture>
 <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC3">
            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
            /**************** Encrypted contents **************/
        </ns2:mediaCapture>
 <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC4">
            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
            /**************** Encrypted contents **************/
    </mediaCaptures>
    <encodingGroups>
        <ns2:encodingGroup encodingGroupID="EG0">
            <ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
            <ns2:encodingIDList>
                <ns2:encID>ENC1</ns2:encID>
                <ns2:encID>ENC2</ns2:encID>
                <ns2:encID>ENC3</ns2:encID>
            </ns2:encodingIDList>
        </ns2:encodingGroup>
        <ns2:encodingGroup encodingGroupID="EG1">
            <ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
            <ns2:encodingIDList>
                <ns2:encID>ENC4</ns2:encID>
                <ns2:encID>ENC5</ns2:encID>
            </ns2:encodingIDList>
        </ns2:encodingGroup>
    </encodingGroups>
    <captureScenes>
            /**************** Encrypted contents **************/
    </captureScenes>
    <simultaneousSets>



Groves, et al.           Expires April 18, 2016                [Page 10]

Internet-Draft           Usage of CLUE with PERC            October 2015


            /**************** Encrypted contents **************/
    </simultaneousSets>
    <people>
            /**************** Encrypted contents **************/
    </people>
</advertisement>

                  Figure 3: Encrypted CLUE Advertisement

   The downside of this approach is that the MDD effectively becomes
   unable to offer its own switched streams as multiple content
   captures.  Whilst in theory it could offer its own MCCs utilising the
   unencrypted CaptureIDs, it has little metadata to decide which
   streams are related in order to provide synchronised switching.
   Therefore it could be recommended that information such as the
   capture area (which is unlikely to be sensitive) should be passed in
   the clear (unencrypted) to allow the MDD to distinguish that the
   captures cover different parts of the same scene.  In this case the
   MDD could provide a MCC.

5.2.  Others?

   TBD

6.  Summary

   This draft provides a discussion of the relationship between CLUE and
   PERC and the potential impacts to CLUE when used with PERC streams.

7.  Acknowledgements

   This template was derived from an initial version written by Pekka
   Savola and contributed by him to the xml2rfc project.

8.  IANA Considerations

   None.

9.  Security Considerations

   This draft is about the privacy and security implications of using
   CLUE in a PERC environment.

10.  References







Groves, et al.           Expires April 18, 2016                [Page 11]

Internet-Draft           Usage of CLUE with PERC            October 2015


10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

10.2.  Informative References

   [I-D.ietf-avtcore-rtp-topologies-update]
              Westerlund, M. and S. Wenger, "RTP Topologies", draft-
              ietf-avtcore-rtp-topologies-update-10 (work in progress),
              July 2015.

   [I-D.ietf-clue-datachannel]
              Holmberg, C., "CLUE Protocol data channel", draft-ietf-
              clue-datachannel-10 (work in progress), September 2015.

   [I-D.ietf-clue-framework]
              Duckworth, M., Pepperell, A., and S. Wenger, "Framework
              for Telepresence Multi-Streams", draft-ietf-clue-
              framework-23 (work in progress), September 2015.

   [I-D.ietf-clue-rtp-mapping]
              Even, R. and J. Lennox, "Mapping RTP streams to CLUE media
              captures", draft-ietf-clue-rtp-mapping-04 (work in
              progress), March 2015.

   [I-D.jones-perc-private-media-framework]
              Jones, P., Ismail, N., and D. Benham, "A Solution
              Framework for Private Media in Privacy Enhanced RTP
              Conferencing", draft-jones-perc-private-media-framework-01
              (work in progress), October 2015.

   [I-D.jones-perc-private-media-reqts]
              Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson,
              J., and R. Barnes, "Private Media Requirements in Privacy
              Enhanced RTP Conferencing", draft-jones-perc-private-
              media-reqts-00 (work in progress), July 2015.

   [RFC6351]  Perreault, S., "xCard: vCard XML Representation", RFC
              6351, DOI 10.17487/RFC6351, August 2011,
              <http://www.rfc-editor.org/info/rfc6351>.








Groves, et al.           Expires April 18, 2016                [Page 12]

Internet-Draft           Usage of CLUE with PERC            October 2015


   [RFC6464]  Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
              Transport Protocol (RTP) Header Extension for Client-to-
              Mixer Audio Level Indication", RFC 6464, DOI 10.17487/
              RFC6464, December 2011,
              <http://www.rfc-editor.org/info/rfc6464>.

Authors' Addresses

   Christian Groves (editor)
   Huawei
   Melbourne
   Australia

   Email: Christian.Groves@nteczone.com


   Weiwei Yang
   Huawei
   P.R.China

   Email: tommy@huawei.com


   Roni Even
   Huawei
   Tel Aviv
   Isreal

   Email: roni.even@mail01.huawei.com






















Groves, et al.           Expires April 18, 2016                [Page 13]