Subject: [clue] CLUE instance versus CLUE message schema

From: Mary Barnes <[email-masked]>
Date: Wed, 5 Sep 2012 17:42:57 -0500

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Sep 2012 07:11:40 +0200

Hi Mary,

I guess you are talking about "CLUE session data", which would be some kind of application level data on top of the SIP dialog data etc?

If this is what you and I talked about in Vancouver,  I did basically volunteer. But, it was unclear whether it was going to be needed/wanted or not - due to the "extremely rough consensus showing a slightly stronger preference" :)

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 6. syyskuuta 2012 1:43
To: CLUE
Subject: [clue] CLUE instance versus CLUE message schema

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

---

From: Mary Barnes <[email-masked]>
Date: Thu, 6 Sep 2012 08:19:58 -0500

On Thu, Sep 6, 2012 at 12:11 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Mary,****
>
> ** **
>
> I guess you are talking about “CLUE session data”, which would be some
> kind of application level data on top of the SIP dialog data etc?
>
Correct.

> ****
>
> ** **
>
> If this is what you and I talked about in Vancouver,  I did basically
> volunteer. But, it was unclear whether it was going to be needed/wanted or
> not – due to the “*extremely* rough consensus showing a *slightly*stronger preference” :)
>
Right.  But, based on the discussion on the call on Tuesday, it seems that
it could help us sort through what needs to be signaled when and how.
 So, if you can put together a strawman that would be extremely helpful.

> ****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Sent:* 6. syyskuuta 2012 1:43
> *To:* CLUE
> *Subject:* [clue] CLUE instance versus CLUE message schema****
>
> ** **
>
> Hi all,****
>
> ** **
>
> where we discussed this thread:****
>
> http://www.ietf.org/mail-archive/web/clue/current/msg01877.html****
>
> ** **
>
> separate email. But, I just wanted to bring up a specific topic. ****
>
> ** **
>
> chart 11).  Our discussion led to the "data model" topic.  ****
>
> ** **
>
> 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.****
>
> ** **
>
> impossible to decide how changes to the information should be signaled.  *
> ***
>
> ** **
>
> to work out in order to move forward.  ****
>
> ** **
>
> Thanks,****
>
> Mary and Paul****
>
> CLUE WG co-chairs****
>
> ** **
>
> ** **
>
> ** **
>

---

From: Andy Pepperell <[email-masked]>
Date: Thu, 6 Sep 2012 16:21:47 +0100

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 <[email-masked]>wrote:

> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2012 14:03:16 +0200

Hi,
 
>Right.  But, based on the discussion on the call on Tuesday, it seems that it could help us sort through what needs to be signaled when and how.    So, if you can put together a strawman that would be extremely helpful.

I didn't participate in the phone meeting, but how different would this be compared to the existing data model?

Regards,

Christer

 
Hi all,

 

 
 
Thanks,
Mary and Paul
CLUE WG co-chairs