>Note, that Andy was our notetaker and he'll send what he captured in a
separate email. But, I just wanted to bring up a specific topic.

Thanks for the reminder Mary :) Here's what I captured from Tuesday's
meeting when I wasn't myself talking:

PaulK: described e-mail, pointing out what should go in SDP and what in
CLUE. All relative to when CLUE is sent relative to SDP, e.g. before /
after / interleaved with Offer / Answer ("O/A"). Thought it would be good
to explore how this should work..
Andy: Rob Hansen presented something along these lines on Vancouver
PaulW: Need to ensure that the initial offer doesn't contain the entire bit
rate etc. for multi-stream operations for compatibility
(Mary shares Rob's call flow presentation from Vancouver)
PaulK: should we try to put enough in the initial O/A to allow CLUE to
proceed without an additional O/A?
Roni: all examples show all video multiplexed in same RTP session - should
look at call flows where this isn't the case
PaulK: if some set of CLUE stuff belongs in SDP, we could end up where
every provider advertisement and consumer stream selection needs new O/A
Roni: missing discussion on RTCP - some of the non static changes can be
done today in RTCP. Need to figure out whether some of the new things we're
talking about in CLUE should be in SDP.
Roni: in my view many of the things we're talking about can be accomplished
in SDP, e.g. the mapping (?)
Mary: Some of what you're saying impacts the data model - need perhaps some
of the text and descriptions as per XCON, which we're lacking
PaulK: something of a chicken and egg problem (Mary agrees). Top down
framework vs RTP vs mapping.
Roni: mapping simulcast to media capture - multiple RTP streams to a media
capture, so agree on the need for an "encoding ID"
PaulW: is any information missing whose location is still to be determined?
PaulK: ISTM there are 2 paradigms - O/A vs advertisement / stream choice,
and they need harmonizing
Andy: It was the aim not to need O/A exchanges when CLUE changes happen
Roni: if you change media capture or add a new one, it would have to be
part of the same 5 tuple - if new 5 tuples were needed then you'd need a
new O/A
PaulW: need to ensure compatibility with middle boxes, which might baulk at
too many additional m lines etc.
Jonathan: anything carried today in SDP between standard VC endpoints
should stay there, and not be part of CLUE
PaulK: How about bandwidth?
Jonathan: Bandwidth is a complicated one, but port numbers, ICE candidates
etc. should definitely be in SDP. Things that are purely transport related
are clearly out of scope.
Roni: If you have 2 ways to do things you'll always have interoperability
issues.
Roni: multiple streams, bandwidth, QoS, RTCweb....
PaulK: if you're going to make a new advertisement / configuration that
requires something not currently in SDP, what do you do? Do you make a new
O/A first, or new provider advertisement first?
Roni: I don't understand
Roni: looking at the case where the user wants to start a presentation - a
new O/A
Mary: If the user decides to do something then it may trigger new CLUE
signalling or a new O/A.
PaulK: Need to know which changes need to be signalled via O/A, which need
new CLUE messages, which can be accomplished through RTP+RTCP
Mary: Yes, which was what was trying to be done with the XCON scheme.
Without knowing more about the "state" becomes difficult.
Mary: need information on the CLUE "instance" (set of state held by each
side)



On Wed, Sep 5, 2012 at 11:42 PM, Mary Barnes <mary.ietf.barnes@gmail.com>wrote:

> Hi all,
>
> I'm going to bring up a topic that arose from yesterday's design team call
> where we discussed this thread:
> http://www.ietf.org/mail-archive/web/clue/current/msg01877.html
>
> Note, that Andy was our notetaker and he'll send what he captured in a
> separate email. But, I just wanted to bring up a specific topic.
>
> I put up Rob's charts as presented at IETF-84 for the call flow topic.
>  There is general agreement that a SIP offer/answer occurs before CLUE
> specific signaling (per chart 2).  So, the discussion centered around the
> signaling after the initial O/A and advertisement/configure sequence (ala
> chart 11).  Our discussion led to the "data model" topic.
>
> As a reminder, during the discussion at IETF-84 under the "Data model"
> topic (during the 2nd WG session), we agreed that we were really discussing
> two different approaches to describing the data that is maintained and
> manipulated for a CLUE "session":
> 1) Message schema (i.e., the data to be carried in specific messages)
> 2) CLUE instance - representing the data/state stored at an endpoint.
>
> The extremely rough consensus was that there was a slightly stronger
> preference for the 1st approach.  However, during today's design team call,
> some folks that had preferred the 1st approach came to see the value in the
> second approach.  This becomes more clear when one considers that changes
> are often a result of a user action (e.g., share my presentation).  Thus,
> there needs to be some state and configuration information available at the
> CLUE endpoint.  Until it is clear what this information is, it's virtually
> impossible to decide how changes to the information should be signaled.
>
> We would like WG feedback on the approach to describing the data for CLUE.
>  Secondly, we would like a volunteer for the "instance" approach.  While
> the time is short before the interim, this seems to be something key for us
> to work out in order to move forward.
>
> Thanks,
> Mary and Paul
> CLUE WG co-chairs
>
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
>