IETF
clue@jabber.ietf.org
Thursday, 17 November 2011< ^ >
RjS has set the subject to: Clue WG
Room Configuration

GMT+0
[03:44:43] Jonathan Lennox joins the room
[03:46:50] marshall joins the room
[03:46:52] RjS joins the room
[03:47:06] <marshall> Hi - CLUE / RTCWEB ad hoc
[03:47:07] jlcJohn joins the room
[03:47:09] tsuichi joins the room
[03:47:19] Kepeng joins the room
[03:47:58] EKR joins the room
[03:48:19] <Jonathan Lennox> The slides are on the meeting material page under CLUE
[03:48:30] <EKR> Can someondanke
[03:48:50] <marshall> Cullen - RTCWEB - we want to be able to communicate, put up video
[03:48:56] <marshall> idea is not rocket science
[03:49:08] <marshall> we have agreed to use rtp or srtp
[03:49:21] <marshall> we need some way to agree on what we are sending back and forth
[03:49:27] pm joins the room
[03:49:41] victor.pascual.avila joins the room
[03:49:51] <marshall> javascript -> web server over http
[03:49:55] <marshall> slide page 6
[03:50:02] <EKR> why is it that the dudes in both these pictures on slide 2 look high?
[03:50:05] <marshall> we want a connection to legacy VOIP
[03:50:43] <marshall> this would include CLUE stuff like telepresence
[03:50:48] <marshall> next slide
[03:51:04] <EKR> you can always tell my figures since PIC is so obvious
[03:51:07] <marshall> Security - somewhat like RAI
[03:51:11] <marshall> next slide
[03:51:17] <marshall> you can download some code
[03:52:05] <marshall> maybe the browser has gone to an "evil" browser that is sending stuff that looks like rtp packets, but
[03:52:07] <marshall> aren't
[03:52:09] <marshall> page 10
[03:52:44] <marshall> so, we need to talk over the signalling channel to agree on communication before the broswer
[03:52:51] <marshall> starts receiving data
[03:52:58] burn joins the room
[03:53:10] <marshall> the protocol we picked for this is ICE
[03:53:35] <marshall> another hard part (next slide, with image from EKR) is idenitity
[03:54:06] <marshall> who am I am allowing (for example) to turn on my video camera
[03:54:24] <marshall> use existing identity providers like OATH
[03:54:27] <marshall> slide 12
[03:54:36] <marshall> RTCWeb is going to help chose
[03:55:35] <marshall> audio / video codecs / media transport / data transport
[03:56:00] <marshall> need to set API requirements, deal with NAT/Firewall (ICE/STUN/TURN)
[03:56:24] <marshall> media scurity (DTLS and / or SDES) and assert idensity
[03:56:34] <marshall> we are working with W3C for API requirements
[03:56:42] <marshall> slide 13
[03:57:06] <marshall> Overlap with CLUE
[03:57:18] <marshall> reducing the number of UDP ports
[03:57:43] <marshall> proposals to use video codecs without SDP
[03:58:00] <marshall> [as a CLUE member, I don't agree with either statement RE Clue]
[03:59:06] <Jonathan Lennox> Marshall is at the mic line
[04:01:21] <marshall> Marshall : Slide 13 had two CLUE items that we had never actually, AFAICR, discussed
[04:01:26] <marshall> NEXT
[04:01:46] <marshall> Allyn
[04:01:59] <marshall> EKR, can you hear her?
[04:02:11] <Jonathan Lennox> Ted has written "No nitty-gritty please" on the back of his laptop
[04:02:14] <EKR> yes
[04:02:26] <EKR> thanks
[04:02:44] <marshall> Allyn : It was apparent to me as Cullen was talking how different CLUE and RTCWEB are
[04:02:45] <EKR> one of these things is not like the other
[04:03:02] <marshall> CLUE is about the relationships between multiple streams
[04:03:23] <marshall> this has not been looked at by anyone else in RAI
[04:03:29] <marshall> It is SIP based
[04:03:36] <marshall> and MUST be extensible
[04:03:44] <marshall> for the next 20 years
[04:03:59] <marshall> Slide 3
[04:04:16] <marshall> Mary : This is the functional model we added.
[04:04:23] <marshall> We are using SIP and RTP
[04:04:39] <marshall> we are adding the data needed to achieve presence
[04:04:48] <marshall> we have not decided how to exchange meta data
[04:05:28] <marshall> Allyn : The outstanding issue is how the content will be carried in CLUE
[04:05:50] <marshall> Stephan Wenger : The red lines in figure 3 may not go through a content server
[04:06:14] <marshall> CLUE is about the interrelationships of streams
[04:06:30] <marshall> physcial and spatial relationships between streams
[04:07:03] <marshall> We have a messanging model
[04:07:23] <marshall> a mechanism for a receiver to pick streams it wishe to receive
[04:07:47] victor.pascual.avila leaves the room
[04:08:28] <marshall> a capture set is the aggregation of several media captures, which go down to things like purpose, formats, etc.
[04:08:31] <marshall> slide 8
[04:09:08] <marshall> encoding groups describe characteristics like bandwidth (per stream and total)
[04:09:11] <marshall> slide 9
[04:09:31] <marshall> provider sends information to the consumer which selects amount them
[04:09:39] victor.pascual.avila joins the room
[04:10:12] <marshall> Note : One telepresence unit will be both a provider and consumer, but in principle an endpoint could be one or the other. Logically they are separate
[04:10:15] <marshall> slide 10
[04:10:35] <marshall> basic message flow is 3 way consumer -> provider -> consumer
[04:11:49] <marshall> example ; consumer I can support up to 3 streams at 16:9 ; provider i have N streams at 16:9; consumer; ok send #'s 1 and 3
[04:11:55] <marshall> slide 11
[04:12:16] <marshall> SDP offer answer model - that message model is different than ours - slide 11
[04:12:53] <marshall> SDP offer answer : A sends offer to B and B sends an answer
[04:13:17] <marshall> CLUE is much closer to publish / subscribe : A learns what B has and then choses what it wants
[04:13:43] <marshall> the consumer is actually configuring the other end, which has security implications
[04:14:06] <marshall> We plan to use the RAI infrastrcture and do not want to replace SDP
[04:15:00] hta joins the room
[04:16:09] victor.pascual.avila leaves the room
[04:16:11] <marshall> there may be redundancies between CLUE and SDP
[04:17:02] <marshall> Marshall : Clue is also discussing sending of non-audio non-video presentation data
[04:17:30] <marshall> Cullen : What is the difference between a capability and an advertisement
[04:17:31] Hadriel Kaplan joins the room
[04:18:01] <marshall> Allyn : Some people feel this is arbitrary. It's information
[04:19:54] <marshall> Mary : Slide 6
[04:20:25] <marshall> CLUE is focused on controlling multiple MPEG audio and video streams
[04:20:38] <Hadriel Kaplan> I'd just note that the problem for CLUE isn't the SDP "Messaging model" as the slides said - it's that there's also more metadata that is possibly not appropriate for SDP
[04:20:45] juberti@gmail.com/Meebo joins the room
[04:20:56] <marshall> Quite true
[04:21:20] <marshall> Colin Perkins : There are other drafts
[04:21:44] <marshall> Magnus
[04:21:48] <marshall> on slide 8
[04:22:06] <marshall> Multiple streams can be done for different reasons which have different implications
[04:23:03] suzukisn joins the room
[04:23:17] <marshall> Cullen : What's wrong is that we are discussing this in this working group.. This shouldn't replicate AVTCORE or MMUSIC work
[04:23:50] <marshall> Roni Evens: We were discussing the requirement in CLUE. The minimum requirement was not to multiple everything together
[04:24:11] <marshall> we were also discussing whether or not the presentation data should go in the same string
[04:24:39] <marshall> Jonathan : Most whatCLUE is trying to do is out of scope with what SHIM was trying to do
[04:25:02] <marshall> Colin Perkins : Cullen's slide was actually pretty good
[04:25:43] <marshall> We have legacy case where RTP sessions for audio video are run unmultiplexed on separate ports
[04:26:10] <marshall> we have people who want to multiplex everything on one port, which can be done with some implications
[04:29:11] <marshall> we need to be clear what we are doing and I don't think the drafts on page 8 describe the topics that that figure describes them as doing
[04:30:00] Hadriel Kaplan leaves the room
[04:31:32] <marshall> Ted Hardy : We need to recast this slide. If there are overlapping requirements, then we need to make them aligned so we go to the people who do these things and make sure they can fulfilled
[04:32:05] <marshall> Roni : We are not saying that we have one set of requirements
[04:32:19] <marshall> Magnus : Before we have requirements, this discussion is premature
[04:32:34] <marshall> This meeting is rather pointless
[04:32:50] <marshall> until you have requirements
[04:33:02] <marshall> Mary : We need to undersntad the ongoing work in AVT core
[04:33:43] <marshall> More useful might be are there CLUE use cases that intersect with RTCWEB ?
[04:34:16] victor.pascual.avila joins the room
[04:35:39] <marshall> Cullen : I would fascinated to hear anything how the requirements are different from what the RTCWEB is doing
[04:36:13] <EKR> I would like to observe that I am very lost
[04:36:28] <marshall> Roni : CLUE is giving a mixed message. We have not discussed _not_ using SDP for codec media setup
[04:36:31] <EKR> can someone explain what this meeting is actually doing?
[04:36:41] <marshall> No
[04:37:00] <Kepeng> identify overlaps
[04:37:12] <Kepeng> intended to be
[04:37:22] <marshall> It is the other stuff that has to be sent somehow.
[04:38:46] jesup joins the room
[04:39:39] <marshall> My use case is connecting a telepresence unit and a RTCWEB browser
[04:41:09] <marshall> Jonathan Lennox : If CLUE decided to do extra communication in the data plane, it seems to me that CLUE and RTCWEB look pretty similar to me.
[04:42:27] <marshall> Cullen : A version of Hadrian's use case that my employer would be interested in is a telepresence call into a webex meeting on an ipad
[04:42:36] victor.pascual.avila leaves the room
[04:43:45] <marshall> Roni : We wanted to handle legacy systems but we ran into a problem in that there needs to be metadata
[04:44:17] <hta> let's have two clue confereneces calling each other via the POTS.
[04:44:42] <Jonathan Lennox> hta: VIPR!
[04:44:43] <marshall> Chris : We have been talking about non Clue devices which should be able to call in to a CLUE conference even if we can't handle the extra information
[04:45:40] <Kepeng> A Frank and Open Exchange of Views,on Ted's computer
[04:45:54] <marshall> Hadrian : What we have to get right is to understand the data requirements at a high level
[04:47:15] suzukisn leaves the room
[04:47:19] suzukisn joins the room
[04:50:41] Kepeng leaves the room
[04:51:31] <marshall> Sorry : Here is what I said
[04:51:37] RjS leaves the room
[04:53:06] hta leaves the room
[04:53:24] Jonathan Lennox leaves the room: Computer went to sleep
[04:53:25] burn leaves the room
[04:53:27] <jesup> Are there going to be minutes or a summary?
[04:53:30] suzukisn leaves the room
[04:53:57] <jesup> I had to go deal with putting a toddler to bed and just listened in to hear the last minute
[04:54:26] <marshall> I was hoping that we would tell RTCWEB at a very high level what we would want a high end RTCWEB user to do, such as to show certain screens on the left and certain ones on the right, and associate certain audio channels with certain video channels
[04:54:54] <marshall> and what does that imply for RTCWEB and are we doing things stupdily that will hinder RTCWEB
[04:56:02] RjS joins the room
[04:56:30] suzukisn joins the room
[04:57:52] <marshall> Ted Hardy had a very interesting comment, that these are more API issues, and so the W3C WEBRTC group should be involved
[04:57:55] marshall leaves the room
[05:01:12] juberti@gmail.com/Meebo leaves the room
[05:01:57] RjS leaves the room
[05:04:00] tsuichi leaves the room
[05:04:30] victor.pascual.avila joins the room
[05:06:34] suzukisn leaves the room
[05:06:38] jlcJohn leaves the room
[05:13:01] pm leaves the room
[05:14:15] hta joins the room
[05:14:27] hta leaves the room
[05:29:28] Hadriel Kaplan joins the room
[07:02:31] Hadriel Kaplan leaves the room
[07:11:04] victor.pascual.avila leaves the room
[07:24:16] Hadriel Kaplan joins the room
[08:20:22] jesup leaves the room
[08:22:42] hta joins the room
[08:55:52] Hadriel Kaplan leaves the room
[09:30:27] burn joins the room
[09:30:33] burn leaves the room
[09:31:19] hta leaves the room
[09:32:15] EKR leaves the room
[10:02:36] hta joins the room
[10:02:36] hta leaves the room
[10:02:36] hta joins the room
[10:46:21] hta leaves the room
[13:38:33] hta joins the room
[14:03:52] hta leaves the room