Subject: [clue] CLUE design call meeting notes, 7 January 2013

From: Andy Pepperell <[email-masked]>
Date: Thu, 10 Jan 2013 18:51:55 +0000

All,

Apologies for not sending these out until now; here are the notes I took on
Monday's call.

Andy

Simon: I tried to provider notes, and foster discussion on a few more
items. Together with Roberta we're trying to write down a call flow
including Offer / Answer and CLUE messages.

Simon: I think that the new introduction to the framework is quite useful
as it tries to shed some light on the new features. I really like this new
approach I think it did contain a number of unresolved issues. We have not
yet reached consensus on a number of important issues - so trying to focus
on those issues. Trying to put ourselves into the body of a newcomer - some
parts of the document are really helpful but some are distracting and
contain too much information.

Simon: Before RTP mapping issue, should focus more on the messages flowing
on the CLUE control channel. Useful to describe those messages at a very
high level rather than the detail. I think the detail is needed, but it
should come afterwards,

Roni: The way I read what Simon was writing was that he was viewing the
CLUE messages as a capability exchange but I worry what happens what
happens in the second and further advertisements, and whether we require a
new O/A after the advertisement / configuration cycle.

Paul: as I read the framework right now, it explains it quite well, and the
O/A isn't needed in all such cases. We keep coming round to this; until we
get the signalling nailed down we can't get these questions answered. I'm
not sure we can.

Mary: really we're in a chicken and egg situation and we need to work
through the detail and see if it works.
Mark: That's what we tried to do within Stephan's changes - not sure if
that addresses Roni's question except at a very high level. There's likely
to be an additional O/A after the initial CLUE messages.

Paul: the highlighted paragraph in the framework document ("During the
lifetime of a call...") takes a position on this (O/A done later than the
advertisement / configure). It's still a little unclear here.

Simon: sorry to interrupt... with reference to the data model link, we
tried to go through this from the data model point of view:
http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-clue-call-flow-example-00.html
The advertisement should be seen as a copy of the data model information,
99% the same as the data model.
Not trying to worry about what parts of the data model can be modelled in
SDP and what cannot, but what might flow between 2 CLUE capable endpoints
on the CLUE channel, exchange of XML documents describing the telepresence
room. Updates SDP would be the result of ongoing work in MMUSIC (RTP
multiplexing, BUNDLE etc.) - I feel this is out of scope for CLUE at this
time.

Paul: I agree with what you say - do we want to put this level of detail
into the framework?

Mark: I agree that these diagrams are consistent with the new framework
material and they would be useful in the framework document.

Simon: It is my view that these documents are more important for the
framework than the data model.

Paul: I think it should be made clear that the point of the reinvite is to
enable the most recent configuration.

Roni: I don't have any problem with this example - I think it is correct. I
have a problem with the next stage - if we want to send a new
configuration, how does it work? If we have a later configure, do we always
have a reinvite?

Paul: I think the reinvite is (always) optional - if the configuration is
consistent with SDP 1 and SDP 2, we shouldn't need a reinvite.

Roni: Paul, I have a question: how do you know if you have to reinvite or
wait for a new reinvite before you can send? You might need a reinvite from
both sides, and get glare.

Paul: we have this come up again and again - we can just let glare be
handled (as it has to be handleable anyway). For the framework this should
be enough - otherwise the extra detail would make the framework too big,
and more distracting. In a signalling document, we need to go into that in
excruciating detail.

Simon: I agree, at the moment we need to agree that the advertisement is
sent across the CLUE channel if 2 sides are both CLUE capable. In the
picture, advertisement 1 and 2 aren't sent in an SDP body, but they're
transferred directly via XML across the CLUE channel - it would be a good
step forward for this to be agreed.

Jonathan: I have one comment on what Paul said: I think I agree with you,
Paul, in that you don't need to send an updated SDP if the existing is
compatible with the current adv / configure, but I'm thinking about the
case where the old SDP is consistent with the new configure etc. but not
optimal. i.e. it works for the minimal but not the optimal one.
e.g.Configuration says I can do up to 1080p but the SDP says up to 720p.

Paul: That's not inconsistent with saying the O/A is optional
Jonathan: my concern is that it is optional, then it becomes confusing to
know for implementors whether to wait for a new O/A or to continue with
what I've got
Roni: that's my concern also, whether you're allowed to send the new
configuration
Jonathan: you'd be *allowed* but it might not be optimal

Paul: what happens between the new advertisement and the new config?
Paul: by the time you've advertised and configs, both sides know enough to
send a new O/A, but which side should reinvite?

Jonathan: in the situation that the consumer sends the configure and
shortly thereafter the provider sends the new reinvite do I send media
based on the old SDP or wait for a new reinvite to come in.
Andy: re-advertisements generally not in sync - the sort of event that
would cause one side to [need to] re-advertise wouldn't be co-incident with
the other side needing to do so, so this is not necessarily a common case
Paul: when you get a new configure you should start to honour it based on
the existing SDP rather than assume a new SDP will arrive
Jonathan: I agree that's the obvious thing to do but I'm concerned *(audio
went very static-y at this point and difficult to hear)*

Paul: at the beginning of the call it's a different story (both sides will
advertise and configure)
Paul: whoever does an offer answer should do it based on the most recent
configure in both directions, not just your own as the other guy's might
require more more m-lines than yours

Rob: deciding who should reinvite is generally bad
Paul: I think requiring O/A based on config is good
Rob: even with 2 well-behaved endpoints you could have middleboxes doing
anything, not following conventions etc. so need to be careful
Paul: conventions won't nail down everything, but they provide guidance.
even if you're required to do O/A because you send config, if you receive
one before you send one then you need to take that into account. if that
puts you in a situation where you don't need to O/A then that's cool. Both
sides send configured, both send offer then you get glare. one side wins
the back off and it sends an offer. It would send offer that takes into
account both offers, and so the other side has achieve what he needs to
achieve
Andy: I think your approach (Paul) here with the configurer required to do
the O/A if necessary is a good one, even though there's still likely to be
glare-type cases at the start of the call

Simon: from our side we'll continue working on this stuff, and we'll
continue on e-mail threads.

Mark: we should continue on the e-mail list, and there are some extra
threads not related to version 8 of the framework, and we should get
consensus on a few specific things and get those in the next version. There
are some discussions on capture attributes that haven't yet been concluded.
Could people also, via e-mail,c all out the various sections of the
framework document they think should be moved to other documents, though
not actually move those things yet.