Minutes for CLUE at interim-2013-clue-1
minutes-interim-2013-clue-1-3

IETF CLUE WG Interim meeting, May 21, 2013

Participants:
------------
Mary Barnes
Paul Kyzivat
Mark Duckworth
Andy Pepperell
Christer Holmberg
Christian Groves
Cullen Jennings
Dan Romascanu
Gonzalo Camarillo
Jonathan Lennox
Keith Drage
Richard Ejzak
Rob Hansen
Roberta Presta
Roni Even
Scott Pennock
Simon Romano
Stephan Wenger
Stephane Cazeaux

Recording:
------------
https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=12686922&rKey=e4198e7067d82c36

Notes by: Mary, Roni, Andy, and Paul
--------

Summary:
---------
The objective of the meeting was to review the updates and open issues around
the framework and focus on the signaling solution

Framework:
- Roles: Christian has an outstanding action to post a document evaluating the
various options that were discussed on the mailing list. Action: Christian
submit the document no later than May 28, 2013. Action: Chairs open an issue to
track this one.

- Switched Capture: Currently unclear in the framework.  Folks are working on
text around this in the form of drafts.  Action:  These drafts must be
submitted no later than June 14, 2013 to ensure there is discussion prior to
Berlin. Discussion on the principles can also be discussed on the mailing list,
but would be most helpful in the context of the drafts.

- Security: Needs to be based on what is outlined in requirements. Definitely
need to address threats and potential security issues with regards to
information sent over CLUE channel.  Action: Mark with Mary (who is doing the
security aspects based on the requirements) to put this together.

- Issue #20 (Rejecting configure).  This needs to be mentioned in the framework
as a possibility, so that the subsequent actions can be described. (E.g., does
the prior configure remain in effect?)  The details of how this is communicated
belong in the solution.  Action: chairs update the issue in the tracker.

- Issue #22 (stale Advertisement).  This appears to be around a race condition
and it should be addressed in the solution. Action: Chairs to change the issue
to the signaling doc.

- Issue around partial advertisement (#25). General sense that this is a
solution issue. However, Christian doesn't necessarily agree. Action:
Christian/Roni figure out if and where this should be addressed in FW.

Signaling/solution:
- Action: Rob to fold the concepts (and feedback thereon) presented into
draft-kyzivat-clue-signaling

Way Forward:
- Actions above to be addressed.
- Schedule another virtual interim 4-5 weeks out.

Roni's notes:
-------------
Notewell
Framework – Mark Duckworth
Recent changes
Switched Capture discussion.
Paul – what is site switch. It is not specified enough in the framework.
Mark – agree that it is not clear.
Where does site switch defined  CSE, MC.
Christer – let people think about it and come with proposals in Berin
Christian – we are working on this issues.
Mary discuss site switch on the mailing list.
Mark – there may be two draft (Mark, Christian)
Roni: is site switch needed for consumer to select policy.
Christer: provide a basic one (voice activated and other user defined)
Jonathan : we need to have a definition what a site is.
Christer: why call it site switch and not switch or scene switch.
Mary: we cannot conclude and there will be drafts and mailing list discussion.
It need resolution. Christer: please take into account that July people will be
on vacation Mary will write the security consideration.

Ticket #20 – is it in the framework? Mary.
Ticket #22 – the configure reference an out of date advertisement. A solution
thing Ticket #25 – is also a solution so for the signaling.

SIP/CLUE call flow – Rob
No specific order for CLUE and SIP
CLUE reference SDP labels
Jonathan – no SDP to CLUE reference – not even for which MC is controlled by
SDP. Rob: the labels in SDP are just labels, no semantics. Rob : when you
receive an SDP with n m-lines and you do not know yet if you use them you can
either accept them since it CLUE or reject and do an O/A later.

Rob: trying not to use any new SDP attributes
Jonathan: if I accept this m-line will I get media now or only when I get
config, reuire that this m-line will indicate if it is controlled by clue
Jonathan: no reason to overload the semantics of “labe” to say that this m-line
is controlled by CLUE Jonathan : whose side labels are used Rob: next step put
the comments in an update version.

Andy's Notes:
-------------

Introduction from Mary.

MarkD: Overview:
Going to go over recent changes arising from Orlando
Slides for 5 minutes then discussion
Refactoring from Orlando: syntax-like notation moved out of the framework and
left to the data model. Lots of questions about switched captures over the
e-mail list over the last couple of years. Have been previous drafts but put on
hold pending more important things - would now like to continue that
discussion. Still open tickets on this.

Paul: Roni, Christian and I have been having some discussions off line about
switching. Reading the documents themselves meant they came to 3 different
ideas about what was being explained - need more clarification about the scope
and nature of the attributes being described / proposed. e.g. if the capture
scene. Roni: if I have a presentation and I have a room view that's switched,
the presentation shouldn't be switched - so can't be capture scene entry
Christer: Roni, presentation and room should be in different CSEs Roni: depends
where you put that attribute - is it a scene attribute or a call attribute?
Christer: would it help to make it per capture - isn't that the most flexible?
Mark: the idea of making the attribute on a CSE then it would apply to all the
captures, so it was a way to enforce the same attribute consistently across all
captures in the CSE Christer: if they're in different CSEs then that solves
this Jonathan: this forces implementers to handle this case if they receive it.
if you have a CSE and a capture in multiple CSEs, what attribute does it have -
do the CSEs have to be consistent for captures that end up in multiple CSEs.
MarkD: good question, and not currently in the framework MarkD: I've heard
proposals to make it illegal for a capture to be in multiple CSEs Christer:
need a proposal and see if it works for people - difficult to make this up on
the fly Christian: language should be addressed - rather than site or segment
switching but need to choose language that works in conjunction with the
framework terms Mary: when do you anticipate this draft appearing? Christian:
depends on Paul and Roni Roni: hopefully in the next couple of days to make
some additions Paul: we're having difficulty agreeing with each other so don't
want to inflict that on the rest of you at this stage! Roni: one of the issues
is that in the use cases when it talks about site switches it describes an
application scenario. I think we can try to narrow this - with site switch if
we narrow the scope to the application - the objective should be to keep the
"being there" experience when switching through the MCU by providing all the
information needed to do it like in a P2P call. You want to show people in the
correct size etc. Christer: if the 3 of you don't mind I'd like to be included
in these discussions too Mary: if we could have the discussions on the mailing
list that would be good Mark: sounds like everyone agrees we should spend more
time on this in the group Christian: I think there are a few interaction issues
here Mark: I was thinking I would do a "half-baked draft" in an e-mail
discussion, and try to have a few revisions before the next meeting Mary: 7 / 8
weeks to the draft cut off - could you guys try to get those on the list in the
next 3 weeks so they can be discussed before Berlin?

Roni: a question of how much information we need to provide in order to allow
full control by the consumer Christer: if the MCU supplies you a site switched
view and provides you with information on who is the active speaker Christian:
so we want to provide enough information Christer: what I'm saying that the MCU
says I can give you site switched and tell you who's the active speaker, or you
can tell me the speaker you want Roni: we kept site switching as a boolean to
not decide any piolicy - up to the provider to decide this Christian: we should
be talking about CSEs and captures rather than attributes. For now we assume
the switched attribute is boolean. MarkD: my understanding of the switched
attribute is that we made a firm decision within the group on that being a
boolean, but that doesn't mean there aren't further attributes to be defined.
As an example we later came up with the policy attribute - so you can have
multiple attributes that work together Christer: I agree Roni: we're trying to
figure out what we want to specify, in relation to the original source, the MCU
and the final consumer Paul: Christer mentioned earlier that site switched only
applied in the MCU case, not P2P. From the point of view if our protocol
there's no visibility of that information. If I'm a room connected to a far end
system I don't know what the other side is - there's no explicit indication of
the far end being an endpoint or and MCU. [AP]: seems slightly wrong to me for
us to try to read anything in to the far end site type - e.g. perhaps a plain
"endpoint" would still be able to offer various switched options even though it
wasn't an MCU? Roni: In SIP you can put "in focus" to indicate you're talking
to an MCU Mark: I agree with Christer about it not applying to P2P - in CLUE
that manifests itself as a provider not advertising having a site switched
attribute in what it advertises Jonathan: once we have some semantics on what a
"site" means then the rest may fall out Christer: why do we need "site" rather
than just a switched attribute. The CSE is one way of representing a scene
which is always represented; why do we need this at all? Christer: why can't we
change the name and call it scene switched? [AP]: as I understand it, "site
switched" means you see complete far end sites (or perhaps, complete far end
sites' capture scenes) in a capture scene sent to you (as the consumer),
whereas "segment switched" allows the provider to send a partial set of
captures (e.g. the left most segment of a 3 camera view). "scene switched", if
we decided to adopt this term, to me would have meaning mostly as a synonym for
"site switched"

Mark: Open issues: need to work on updating example section. Need to revisit
video encode capability (currently H.264 focussed, but might want more controls
over which streams can be provided at high frame rate and others not etc,).
Maybe we can make more use of what's available in SDP already? Mary: no IANA
considerations - security: need to work on requirements document for security
Jonathan: do we think that Telepresence has security considerations above what
videoconferencing has? Mary: not necessarily, but we need to describe
requirements Paul: at the very least the CLUE channel is a new element that
needs to have its own security considerations Mark: people's roles etc. 
spatial information might be sensitive, so need to think about a secure way of
transporting this information Mark: Open Tickets... #20 rejecting configure -
do we need this? (action for Andy) Mary to work on this #22 - out of data
advertisements - what is an out of date advertisements Paul: an advertisement
wouldn't be out of date per se, but the configure that references it might be
#25 - is advertisement all or delta? Christian: for the signalling, need to
understand more on when an advertisement would be sent

Rob's presentation:
Rob: this follows on from Orlando, and takes forward some of the design meeting
decisions.

Key points / ideas:
- No ordering enforced between SIP and CLUE
- CLUE refers to SDP (labels) but no reference in the other direction, i.e.
nothing in the SDP needs to make references to what's transported in the CLUE
channel - No new SDP syntax - BUNDLE not used here

Jonathan: no SDP -> CLUE references - would you need something to indicate
which m lines are controlled by CLUE? Rob: yes, but you don't need to parse the
CLUE to understand the SDP. Labels already exist in SDP Paul: this needs a bit
of a leap of faith - you could get an offer with a bunch of streams ("m
line"s?) - you don't know what they're for yet and so you might reject them.
When you get an advertisement that references the labels and only then do you
know you want the, Depending on the ordering you might take the leap of faith
and accept them all at the start, or you might reject and then try to get them
back later. Other schemes have their complications too though, and this isn't
necessarily any worse than those. Jonathan: I think that leap of faith is
relatively safe if you know those m lines are controlled by CLUE Rob: I'm not
suggesting that in the initial INVITE we put all the m lines in - this scheme
needs rather a lot of reINVITEs Paul: none of these slides show any m lines for
the CLUE channel Rob: The "Initial INVITE" should have the CLUE channel in it
and the far end should zero it out if it doesn't understand it, as it would any
other such m line (there is a feature tag though in the header) Paul: are you
saying that the m lines in the initial INVITE should never be used for real
audio and video? Rob: I think you should be able to start sending media using
the initial m lines if you want to (e.g. to get audio up and running early in
the call) Rob: slide 4 shows second Offer, with 4 video m lines including the
original one (3 additional sendonly, each labelled with "clue:") Paul: why
aren't they "sendrecv"? Rob: the problem is the labels are used, and the labels
are easier to use with sendonly and recvonly I tried not to do anything too
complicated with the SDP - I hope we'll end up with being able to use a single
port eventually Christian: why use a label rather than a new attribute? Rob: I
tried to do this without any new signalling (we may need some for multiplexing)
but wanted to use something existing, rather than a CLUE specific media
attribute. To use this in real life I think we'll need some amount of new SDP
syntax Paul: hopefully what'll we'll need new will come out of the BUNDLE - if
we need something new in the SDP we can propose it but if possible we should
use what's there - e.g. labels, which are for this purpose Rob: labels were
designed for this Jonathan: we would have information saying that "this m line
is controlled by the CLUE channel" in the SDP Rob: we could try to group the m
lines and have a "CLUE group". BFCP uses "mid" as well as a label. Rob: Slide
5: encoding groups should be in SDP, but couldn't figure out a good way to do
this Roni: the advertisement you have for deciding the video codec are receive
parameters Rob: there are implications for the video parameters depending on
whether m lines are recvonly, sendonly or sendrecv Roni: yes, on the previous
slide, "max-mbps" is not allowed in the sendonly case, for instance Rob: agreed
Rob: Slide 6: Bob's advertisement to Alice: includes labels not yet included in
his SDP - you need both SDP and CLUE to have complete meaningful information
Rob: Slide 7: SDP answer includes recvonly Paul: why do you need to put a label
on the recvonly in the answer that corresponds to the sendonly in the offer -
they're already matched up? Rob: I take Paul's point - the labels should only
be needed on the sendonly streams - but they have a use here to signal that
these m lines are controlled by CLUE. You should be able to reference the
sendonly labels here. Bob would then know which m lines were being referred to
here. Paul: you mean for the labels to have meaning here rather than just "this
is controlled by CLUE"? Rob:  the grouping mechanism is maybe better here -
label here is being used for 2 purposes, signalling that the m line is
controlled by CLUE, and also identifying which encoding is to be used Paul: I
think you could have multiple labels Jonathan: I think we shouldn't overload
the label - we need to decide though whose labels go in the configure. I don't
think we need to "save labels" as an optimization. Rob: it makes sense to use
the same labels, with the consumer's configure always using the provider's
labels Rob: Slide 10 / 11: Bob adds sendonly m lines in a third offer, which
then gets answered. You could drop the initial sendrecv at this point, but I
don't think you'd need to, and might give extra in-call options to keep it.
Jonathan: could maybe make it "inactive" Roni: you have to keep RTCP alive for
it too Paul: this does consume resources, so would be worth getting rid of if
we can Rob: Summary slide: nothing in the negotiation about who does INVITEs
first, so glare may happen a lot Paul: there's no issue resolving glare, but
the issue is that it's time consuming

Paul's Notes:
-------------

Framework (Mark):

I brought up question about the meaning of site-switching. My interpretation
seems to be in the minority.

Jonathan asked: if a capture is in more than one CSE, can it be site-switched
on one and not on another. (This is a good question!) We want more discussion
of this on the list. Mark proposes to make a new draft on the subject, and
Christian also does. They want us Huawei people to more our discussions into
the public.

Roni brought up question about the switching policy.

Need more discussion on this. Christer wants us to solve this before Berlin.
Mary asked that any drafts be submitted no more the 4 weeks from now.

Signaling (Rob):

Jonathan asks about references from SDP to clue. Answer: only labels that are
referenced from clue.

Rob says assumes that the clue channel will be offered in the first offer.

Jonathan wants something in the SDP that says “this m-line controlled by clue”.
He wants it as a guarantee that nothing will be sent to it until it is
configured.

Rob explained one reason for using sendonly m-lines is that it means the
attributes then describe what can be sent rather than what can be received.