Subject: [clue] CLUE meetings @ IETF-86

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Feb 2013 18:18:04 -0600

The preliminary agenda is out:
https://datatracker.ietf.org/meeting/86/agenda.html

We seem to have our usual Monday morning slot.  Our second slot is
Thursday afternoon.  That should allow some discussions in between and
perhaps we can make some progress.

Note that it's become increasingly clear to those of us that just sat
through 3 days of WebRTC/RTCWEB/MMUSIC that there is still a lot of
work to be done to support multiple media streams- whatever "media
streams" means since it's clear that the definition of such is not
clear.  I think it's important for CLUE participants to be following
the work in MMUSIC as it is relevant to CLUE unless we want multiple
ways of doing the exact same thing.

Regards,
Mary.

---

From: John Leslie <[email-masked]>
Date: Fri, 8 Feb 2013 10:18:06 -0500

Mary Barnes <[email-masked]> wrote:
> work to be done to support multiple media streams-

   I only "sat through" two of those days; but I'll say what Mary tried
to avoid saying: not merely is there a lot of work to be done, there's
little consensus what that work is and less consensus on what path to
pursue.

   There were a bunch of very good folks there; and when I left Wednesday
a half-dozen of them were plotting a way forward. They need _active_
support!

> whatever "media streams" means since it's clear that the definition
> of such is not clear.

   There was actually something approaching consensus that they wouldn't
be able to reach consensus on what it means. ;^)

   (I recommend listening to the audio so you can learn how to say
"avocado" and evoke peals of laughter.)

> I think it's important for CLUE participants to be following the work
> in MMUSIC

   "Following" isn't enough. We need some CLUE people _participating_
in MMUSIC to make it clear that multiple streams of media is a MUST
support issue (and what _we_ mean by that). Several proposals are out
there with differing levels of pain for CLUE -- but we cannot do our
work reasonably while we have to design for all of them (without
knowing which will actually be available).

> as it is relevant to CLUE unless we want multiple ways of doing the
> exact same thing.

   This isn't stated quite right, IMHO. If we _have_ multiple ways of
doing the same thing, we can _design_for_ those multiple ways. What
we're looking at now is near-total uncertainty about which of the
proposed multiple ways (if any) may get blessed by MMUSIC.

   (Nobody there actually _liked_ having multiple ways; but there was
so much tenacity about differing proposals that it's unclear whether
they can reach consensus to discard any of them. IMHO we're better
off having to work around multiple ways than waiting for Godot, only
to find that what we've been assuming ends up being forbidden.)

   YMMV, obviously... but unless we participate in MMUSIC I worry
that progress there will continue to be glacial.

--
John Leslie <[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 8 Feb 2013 19:59:43 +0200

Hi John,
I fully agree with your concerns and I even posted before the meeting that
it should have also been a CLUE interim meeting.
I believe that most of the contributions to MMUSIC are from people who also
follow CLUE.
I think that the relevant work in CLUE is with the RTP mapping draft and we
will try to see how the direction in MMUSIC affect it.

Roni 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Leslie
Sent: 08 February, 2013 5:18 PM
To: Mary Barnes
Cc: CLUE
Subject: Re: [clue] CLUE meetings @ IETF-86

> work to be done to support multiple media streams-

   I only "sat through" two of those days; but I'll say what Mary tried to
avoid saying: not merely is there a lot of work to be done, there's little
consensus what that work is and less consensus on what path to pursue.

   There were a bunch of very good folks there; and when I left Wednesday a
half-dozen of them were plotting a way forward. They need _active_ support!

> whatever "media streams" means since it's clear that the definition of 
> such is not clear.

   There was actually something approaching consensus that they wouldn't be
able to reach consensus on what it means. ;^)

   (I recommend listening to the audio so you can learn how to say "avocado"
and evoke peals of laughter.)

> I think it's important for CLUE participants to be following the work 

   "Following" isn't enough. We need some CLUE people _participating_ in
MMUSIC to make it clear that multiple streams of media is a MUST support
issue (and what _we_ mean by that). Several proposals are out there with
differing levels of pain for CLUE -- but we cannot do our work reasonably
while we have to design for all of them (without knowing which will actually
be available).

> as it is relevant to CLUE unless we want multiple ways of doing the 

   This isn't stated quite right, IMHO. If we _have_ multiple ways of doing
the same thing, we can _design_for_ those multiple ways. What we're looking
at now is near-total uncertainty about which of the proposed multiple ways
(if any) may get blessed by MMUSIC.

   (Nobody there actually _liked_ having multiple ways; but there was so
much tenacity about differing proposals that it's unclear whether they can
reach consensus to discard any of them. IMHO we're better off having to work
around multiple ways than waiting for Godot, only to find that what we've
been assuming ends up being forbidden.)

   YMMV, obviously... but unless we participate in MMUSIC I worry that
progress there will continue to be glacial.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2013 13:19:54 -0500

> it should have also been a CLUE interim meeting.

It would not have worked to have a concurrent CLUE meeting.
This was an intense three days and people were frazzled.

> I believe that most of the contributions to MMUSIC are from people who also

Not so much recently. There are clearly a bunch of RTCWEB people who 
have had to become MMUSIC contributors who only follow clue slightly if 
at all. Several don't really understand SIP either.

But there *are* several of us who are active in CLUE who also follow 
MMUSIC closely. Until now I have refrained from doing much on behalf of 
CLUE because it wasn't clear to me exactly what would be the right thing 
to do.

> will try to see how the direction in MMUSIC affect it.

We also need to either take a stand on the bundling issue, or else 
convince ourselves that anything being proposed for that will meet our 
needs. Until recently I was of the opinion that either "bundle" or "mmt" 
would work for CLUE. But that was partly based on them being "fuzzy". 
This needs to be continually watched.

I've also been commenting actively on the SCTP-SDP draft the ensure that 
what comes out of that will work for CLUE to negotiate its CLUE channel, 
for both native SIP clue endpoints and ones that are browser-rtcweb-based.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Sat, 9 Feb 2013 14:16:28 -0600

> knowing which will actually be available).
[MB] My point was with regards to folks that haven't been following
*any* of the work in RTCWEB that is being fed into MMUSIC.  I think we
had everyone that has been following & more importantly contributing
except Roni at the meeting.   Other folks that are working on a
signaling solution really do need to understand how CLUE will be using
SDP. [/MB]
> to find that what we've been assuming ends up being forbidden.)
[MB] I had side discussions about us ending up with multiple ways.
If we end up with multiple ways (which is certainly likely based upon
where RTCWEB is right now), then we still have issues with interop.
At this point we are most likely going to have to do quite a bit
(somewhere in the middle) to get RTCWEB to work with a CLUE client,
for example, and even to interop with a "legacy" SIP client. [/MB]
> that progress there will continue to be glacial.
[MB] Again, I think that we have participants, the problem is that we
haven't agreed the details for the CLUE signaling thus we don't really
know what solution we would need in MMUSIC.  I don't think we'll end
up with an optimal solution and I think part of it is due to the fact
that SDP is just so overloaded right now and is being pushed to the
limits of it's original design intent.  That's why my preference would
be for CLUE to do the minimum in SDP and leave as much as possible for
the CLUE protocol to allow flexibility and extensibility in the
solution.  Otherwise, it will be a nightmare to extend CLUE and we
really don't achieve some of our primary objectives.[/MB]