IRC log of webrtc on 2011-10-05

Timestamps are in UTC.

15:55:59 [RRSAgent]
RRSAgent has joined #webrtc
15:55:59 [RRSAgent]
logging to
15:56:00 [hta]
zakim, aaaa is me
15:56:02 [Zakim]
+hta; got it
15:56:04 [rillian]
604.728 is me, Ralph Giles for Mozilla
15:56:21 [Zakim]
+ +44.122.375.aacc
15:56:27 [burn]
zakim, aabb is Ralph_Giles
15:56:29 [Zakim]
+Ralph_Giles; got it
15:56:29 [francois]
Meeting: Web Real Time Communications Working Group
15:56:52 [burn]
zakim, aacc is Neil_Stratford
15:56:53 [Zakim]
+Neil_Stratford; got it
15:56:58 [Zakim]
+ +
15:57:04 [francois]
15:57:05 [stefanh]
Zakim, aadd is stefanh
15:57:05 [Zakim]
+stefanh; got it
15:57:13 [burn]
zakim, I am Dan_Burnett
15:57:13 [Zakim]
ok, burn, I now associate you with Dan_Burnett
15:57:30 [rillian]
Zakim, I am Ralph_Giles
15:57:30 [Zakim]
ok, rillian, I now associate you with Ralph_Giles
15:57:52 [hta]
zakim, i am Harald Alvestrand
15:57:55 [francois]
zakim, code?
15:57:55 [Zakim]
I don't understand 'i am Harald Alvestrand', hta
15:57:58 [Zakim]
the conference code is 932782 (tel:+1.617.761.6200, francois
15:58:08 [hta]
zakim, i am Harald_Alvestrand
15:58:08 [Zakim]
sorry, hta, I do not see a party named 'Harald_Alvestrand'
15:58:09 [Zakim]
15:58:14 [stefanh]
Zakim, I am Stefan Håkansson
15:58:17 [francois]
zakim, mute me
15:58:19 [Zakim]
I don't understand 'I am Stefan Håkansson', stefanh
15:58:25 [Zakim]
francois should now be muted
15:58:30 [hta]
hehe. robots ain't easy :-)
15:58:39 [Zakim]
+ +1.408.562.aaee
15:58:45 [francois]
ack me
15:58:49 [Zakim]
+ +1.403.244.aaff
15:59:10 [fluffy]
fluffy has joined #webrtc
15:59:32 [fluffy]
Hi All
15:59:41 [stefanh]
Hi Cullen
15:59:50 [francois]
zakim, hta is Harald_Alvestrand
15:59:52 [Zakim]
+Harald_Alvestrand; got it
16:00:05 [stefanh]
Zakim, stefanh is Stefan Håkansson
16:00:05 [Zakim]
I don't understand 'stefanh is Stefan Håkansson', stefanh
16:00:08 [francois]
zakim, stefanh is Stefan_Håkansson
16:00:08 [Zakim]
+Stefan_Håkansson; got it
16:00:15 [francois]
zakim, who is on the phone?
16:00:19 [Zakim]
16:00:21 [Zakim]
On the phone I see Harald_Alvestrand, Ralph_Giles, Dan_Burnett, Neil_Stratford, Stefan_Håkansson, francois, +1.408.562.aaee, +1.403.244.aaff, ??P66
16:00:52 [burn]
zakim, ??P66 is Tim_Panton
16:00:57 [fluffy]
+1.403.244.aaff is fluffy is Cullen Jennings
16:00:57 [Zakim]
+ +1.425.580.aagg
16:01:06 [Zakim]
+ +972.3.645.aahh
16:01:09 [Zakim]
+Tim_Panton; got it
16:01:12 [burn]
zakim, aaff is Cullen_Jennings
16:01:20 [Zakim]
+Cullen_Jennings; got it
16:01:20 [burn]
zakim, aagg is Dan_Druta
16:01:22 [ceyrigno]
ceyrigno has joined #webrtc
16:01:24 [Zakim]
+ +34.38.83.aaii
16:01:29 [Zakim]
+ +
16:01:30 [DanD]
DanD has joined #webrtc
16:01:31 [Zakim]
+Dan_Druta; got it
16:01:54 [DanRomascanu]
DanRomascanu has joined #webrtc
16:02:05 [Zakim]
+ +44.208.144.aakk
16:02:08 [francois]
zakim, who is making noise?
16:02:12 [Zakim]
16:02:15 [richt]
zakim, aakk is me
16:02:17 [DanRomascanu]
this is brutal
16:02:25 [burn]
zakim, aahh is DanRomascanu
16:02:25 [rillian]
thank you
16:02:35 [Zakim]
+richt; got it
16:02:41 [Zakim]
francois, listening for 10 seconds I heard sound from the following: francois (16%)
16:02:52 [Zakim]
+DanRomascanu; got it
16:02:58 [Zakim]
+ +1.314.529.aall
16:03:03 [Zakim]
16:03:13 [richt]
Present+ Rich_Tibbett
16:03:18 [juberti]
juberti has joined #webrtc
16:03:44 [Zakim]
+ +1.425.894.aamm
16:04:28 [francois]
zakim, who is on the phone?
16:04:31 [Zakim]
16:04:42 [Zakim]
- +34.38.83.aaii
16:04:46 [Zakim]
On the phone I see Harald_Alvestrand, Ralph_Giles, Dan_Burnett, Neil_Stratford, Stefan_Håkansson, francois, +1.408.562.aaee, Cullen_Jennings, Dan_Druta, DanRomascanu,
16:04:51 [Zakim]
... +, richt, ??P84, +1.314.529.aall, [Mozilla], +1.425.894.aamm
16:05:24 [francois]
zakim, aaee is Mani_Mahalingam
16:05:24 [Zakim]
+Mani_Mahalingam; got it
16:05:33 [juberti]
zakim, aamm is juberti
16:05:33 [Zakim]
+juberti; got it
16:05:50 [francois]
zakim, aajj is Adam_Bergkvist
16:05:50 [Zakim]
+Adam_Bergkvist; got it
16:06:25 [francois]
zakim, ??P84 is perhaps Christophe_Eyrignoux
16:06:25 [Zakim]
+Christophe_Eyrignoux?; got it
16:06:27 [rillianbis]
rillianbis has joined #webrtc
16:07:26 [francois]
zakim, aamm is Justin
16:07:26 [Zakim]
sorry, francois, I do not recognize a party named 'aamm'
16:07:49 [francois]
zakim, who is on the phone?
16:07:49 [Zakim]
On the phone I see Harald_Alvestrand, Ralph_Giles, Dan_Burnett, Neil_Stratford, Stefan_Håkansson, francois, Mani_Mahalingam, Cullen_Jennings, Dan_Druta, DanRomascanu,
16:07:52 [Zakim]
... Adam_Bergkvist, richt, Christophe_Eyrignoux?, +1.314.529.aall, [Mozilla], juberti
16:07:55 [juberti]
zakim, juberti is Justin_Uberti
16:07:55 [Zakim]
+Justin_Uberti; got it
16:08:27 [francois]
zakim, francois is Francois_Daoust
16:08:27 [Zakim]
+Francois_Daoust; got it
16:08:35 [adambe]
adambe has joined #webrtc
16:08:53 [francois]
zakim, [Mozilla] is Tim_Terriberry
16:08:53 [Zakim]
+Tim_Terriberry; got it
16:09:13 [rillianbis]
hi derf!
16:09:38 [derf]
Hi rillianbis.
16:10:19 [francois]
Chair: Harald
16:10:38 [francois]
16:11:31 [francois]
Scribe: Francois_Daoust
16:11:34 [francois]
Scribenick: francois
16:11:48 [francois]
zakim, mute me
16:11:48 [Zakim]
Francois_Daoust should now be muted
16:12:02 [rillianbis]
Harald: Agenda sent out on the 27th
16:12:06 [rillianbis]
reviewing items
16:12:20 [francois]
16:12:28 [francois]
RRSAgent, draft minutes
16:12:28 [RRSAgent]
I have made the request to generate francois
16:12:32 [rillianbis]
since then, we've added low-level javascript api proposal
16:12:48 [Mani]
Mani has joined #webrtc
16:12:56 [francois]
RRSAgent, make logs public
16:13:01 [rillianbis]
cullen: overview of the changes to the draft
16:13:12 [rillianbis]
primary set of changes was around separating the ICE state machine a bit
16:13:27 [rillianbis]
Want feedback on the overall model
16:13:47 [rillianbis]
ICE state machine checks candidates, and can start using some while still waiting for other candidates
16:14:00 [rillianbis]
at the same tim eyou have have the negotiation with the other endpoint going on
16:14:07 [rillianbis]
codecs, ICE parameters, etc
16:14:18 [rillianbis]
separated those two aparet
16:14:32 [rillianbis]
and tried to update the text and semantics around when things change state
16:14:43 [rillianbis]
second change:
16:14:52 [rillianbis]
want to redo how we do the data channela nd teh data api
16:14:59 [rillianbis]
commented out what was in the previous draft
16:15:03 [rillianbis]
since it didn't have agreement
16:15:12 [rillianbis]
will replace it based on discussion today and on the list going forward
16:15:17 [rillianbis]
those are the major changes
16:15:38 [rillianbis]
Adam: had a discussion on the mailing list about confusing text
16:15:48 [francois]
s/Scribenick: francois/Scribenick: rillianbis/
16:16:10 [rillianbis]
about how you can create a stream from another stream, and if you disable tracks in the parent they affect the derived streams
16:16:30 [rillianbis]
the usecase was to clone streams e.g. to send a copy of a stream somehwere else
16:16:45 [rillianbis]
but you might want different attributes, e.g. to mute the copy you're uploading
16:17:03 [francois]
s/Scribe: Francois_Daoust/Scribe: Ralph_Giles/
16:17:11 [rillianbis]
so when you fork a stream, it's better if you create a new stream which is a peer of the original, without any parent/child relationship
16:17:18 [rillianbis]
this is easier to understand
16:17:33 [rillianbis]
that was teh first step
16:17:47 [fluffy]
I'm getting IM from people that bridge is busy and they can't join.
16:17:50 [rillianbis]
the second was to be able to create a new stream that contained components gathered from multiple other streams
16:17:52 [francois]
i/cullen: overview/Topic: Changes made to the editors draft/
16:17:58 [francois]
RRSAgent, draft minutes
16:17:58 [RRSAgent]
I have made the request to generate francois
16:18:11 [rillianbis]
e.g. to combine all the audio tracks from multiple incoming streams and record a single file with all the conversation audio
16:18:29 [rillianbis]
has implications wrt sync, but we'll take that as a separate discussion
16:19:42 [rillianbis]
harald: next item
16:19:43 [francois]
zakim, mute me
16:19:43 [Zakim]
Francois_Daoust was already muted, francois
16:20:02 [rillianbis]
Assuming people are ok with non-inherentance
16:20:12 [rillianbis]
shall we talk about the data channel api for a moment
16:20:23 [rillianbis]
the main thing going on is the deletion of that part of the spec
16:20:38 [rillianbis]
but the part that has been happening is that eric (sp?)
16:20:43 [anant]
anant has joined #webrtc
16:20:51 [rillianbis]
has suggested how you could define a protocol for this
16:20:53 [Zakim]
+ +1.408.421.aann
16:20:54 [Zakim]
- +1.408.421.aann
16:20:55 [Zakim]
16:21:02 [rillianbis]
and multiplex multiple streams over the channel
16:21:17 [rillianbis]
most of this is happening at the IETF, but what implication does this have for the API
16:21:43 [rillianbis]
someone else: there is a need to have multiple channels
16:21:52 [rillianbis]
so it's nice not to do that at the application lelvel
16:21:54 [burn]
zakim, ??P69 is Tim_Panton
16:21:54 [Zakim]
+Tim_Panton; got it
16:22:04 [rillianbis]
and also signal reliable vs unreliable
16:22:06 [francois]
i/Adam: had a discussion/Topic: Discussion on specific items/
16:22:08 [stefanh]
s/someone else/justin/
16:22:26 [francois]
16:22:31 [rillianbis]
cullen: can we just have a data channel, which you add like an audio or video stream
16:22:43 [Zakim]
+ +1.610.889.aaoo
16:22:55 [rillianbis]
regardless of whether it's reliable or not, I care about realtime/low-latency data transmission
16:23:04 [rillianbis]
that's the important distinction
16:23:20 [rillianbis]
of course if the library does that form me, that's great
16:23:26 [rillianbis]
but can always build something
16:23:37 [rillianbis]
justin: agree
16:23:44 [rillianbis]
randell jesup also agrees
16:24:23 [rillianbis]
someone else: requirements address low latency, reliability
16:24:40 [rillianbis]
harald: requirements are strict on congestion control
16:24:46 [rillianbis]
that means we have to throw data away
16:24:58 [rillianbis]
so a tradeoff we have to be aware of is that reliable will be slow
16:25:20 [rillianbis]
tim terriberry: we can't assume the endpoint supports data
16:25:41 [rillianbis]
so adding a data stream needs to be able to fail, we should reuse the a/v stream api for that
16:26:10 [rillianbis]
someone else: you don't even know if the other side supports data right now
16:26:22 [rillianbis]
harald: in the absence of a draft
16:26:45 [rillianbis]
the group is drifting to having a data channel you can add just like a media stream
16:26:59 [rillianbis]
justin: yes, the other side has a data stream show up just like a/v
16:27:01 [fluffy]
+1 what Justin said
16:27:11 [rillianbis]
and you can have mulitiple such data streams with different properties
16:27:42 [francois]
16:27:54 [rillianbis]
question: thoughts on peer streams vs peer tracks
16:28:08 [rillianbis]
cullen(?): just make them exactly like a mediastream as much as possible
16:28:22 [rillianbis]
one issue is that tracks are SSRC identified, and demuxed that way
16:28:29 [rillianbis]
while the data stream my have internal muxing
16:29:02 [rillianbis]
the lowest unit of a/v transmission is the track, which is an assymmetry
16:29:23 [rillianbis]
question: how do you create data streams?
16:29:38 [rillianbis]
it's strange if the peerconnection is the factory?
16:29:53 [rillianbis]
harald: could have an .addData() method
16:30:03 [tpanton]
tpanton has joined #webrtc
16:30:05 [rillianbis]
right now we don't have a method of having tracks in a media stream
16:30:21 [rillianbis]
so we don't have a symmetric operation of creating data tracks
16:30:38 [rillianbis]
right now getUserMedia just make a stream appear
16:30:47 [rillianbis]
and we can add streams to that
16:31:02 [rillianbis]
it would be something similar to it
16:31:08 [rillianbis]
getUserMedia must be async
16:31:14 [rillianbis]
but getDataStream could be sync
16:31:39 [rillianbis]
Harald: people have argued, we should just have what's effectively capture keyboard and have that be a stream
16:31:48 [rillianbis]
Next agenda point:
16:32:02 [francois]
Topic: Glare resolution
16:32:22 [rillianbis]
Basic issue is that if we're using browsers with SDP to negotiate
16:32:27 [rillianbis]
ignore SIP, etc. for now
16:32:33 [rillianbis]
if we're using offer/answer
16:32:45 [rillianbis]
and if you and the other side both send offers at the same time (glare)
16:32:50 [rillianbis]
SDP doesn't have a way to resolve that
16:32:54 [rillianbis]
both sides need to retry
16:33:06 [rillianbis]
the way I characterized glare in sip on the IETF thread
16:33:10 [rillianbis]
was sort of wrong
16:33:21 [rillianbis]
but the issue is if we're using SDP we need to handle glare
16:33:41 [rillianbis]
if we want to be able to gateway to sip we need to handle it in a way that's compatible with sip's handling
16:33:50 [rillianbis]
and the way sip does it isn't necessarily optimal
16:34:01 [rillianbis]
one question here is, will the sip approach change?
16:34:23 [rillianbis]
will we invent a backwards-compatibile glare resolution which can be used for any SDP protocol
16:34:44 [rillianbis]
the other question is if we want to be able to gateway to SIP wrt to glare handling
16:34:51 [rillianbis]
either way we have to deal with glare somewhere
16:35:03 [rillianbis]
So, that sets the stage for discussion
16:35:09 [rillianbis]
(that was cullen)
16:35:22 [rillianbis]
Tim Terriberry: what API implications are there?
16:35:37 [rillianbis]
your glare resolution had a magic number, do we need to expose that?
16:35:40 [anant]
anant has joined #webrtc
16:35:48 [rillianbis]
cullen: I don't think that has api implications
16:36:07 [rillianbis]
the only implication is that things might take longer than you think
16:36:13 [rillianbis]
adding a stream will always be async
16:36:19 [rillianbis]
because there's some back and forth there
16:36:33 [rillianbis]
someone else: if you throw these SDP messages away
16:36:44 [rillianbis]
if you find a glare, it would be better to reuse the message
16:36:46 [rillianbis]
just a thought
16:36:59 [rillianbis]
cullen: I think that would be an attempt to resolve this in in a better way
16:37:13 [rillianbis]
one side backs down, and that would be a faster way to do that
16:37:19 [rillianbis]
but I don't think it affects the api
16:37:47 [rillianbis]
I expect to see some drafts or other evolution of the email threads about how we can do glare resolution better, how we can map it
16:37:58 [rillianbis]
it's not as bad as I originally made it sound
16:38:08 [rillianbis]
harald: no specific comments?
16:38:15 [rillianbis]
one question for cullen:
16:38:27 [rillianbis]
if we go with this number thing to do faster resolution, woiuld that still work with sip?
16:38:52 [rillianbis]
cullen: yes. this problem exists in sip as well, so anyone using SDP offer/answer would move to this
16:39:06 [rillianbis]
it would have to be an mmusic draft in the IETF
16:39:22 [rillianbis]
if you didn't have the number, you'd fall back to something which was compatible with the way older sip devices did it
16:39:31 [rillianbis]
but if you had the number it would resolve the glare faster
16:39:49 [rillianbis]
maybe even if only one side uses the new resolution it might go faster
16:40:21 [rillianbis]
This matters because there's a common metaphor of people starting with voice, and adding video. That escalation is a really common case when you have glare
16:40:28 [rillianbis]
I wonder if this is premature optimization
16:40:53 [rillianbis]
jesup: I wonder if we lock ourselves in to glare when we're switching modes, or if there's been an interface changes
16:40:58 [rillianbis]
which affects bandwidth
16:41:11 [rillianbis]
cullen: good questions
16:41:28 [rillianbis]
interfaces changes tend to be one sided, so they don't result in glare
16:41:39 [rillianbis]
changes to network are more of a problem
16:41:51 [rillianbis]
e.g. congestion causes them to drop video
16:42:09 [rillianbis]
we need to design algorithms so both sides don't try to do that at the same time
16:42:36 [rillianbis]
cisco telepresense is designed so the two ends aren't likely to switch within a few 100 ms
16:42:48 [rillianbis]
that's by design, but so far it hasn't been a issue
16:43:01 [rillianbis]
Harald: Cullen will work more on the glare problem
16:43:08 [rillianbis]
we have implementation feedback
16:43:14 [rillianbis]
js argument to getUserMedia
16:43:25 [rillianbis]
tim's note on json hints for mediastreams
16:43:34 [rillianbis]
seems to me these are all reasonable things to do
16:43:41 [rillianbis]
modulo suggested modifications
16:43:48 [rillianbis]
want to keep getusermedia async
16:43:50 [rillianbis]
any other comments?
16:44:17 [rillianbis]
jesup: As far as the async nature of getUserMedia, it's still async in anant's proposal
16:44:23 [rillianbis]
but it's async in a different way
16:44:28 [rillianbis]
you get a stream right away
16:44:35 [rillianbis]
but it's inactive until you get an event
16:44:40 [francois]
i/we have implementation/Topic: Changes to getUserMedia/
16:44:55 [rillianbis]
tommy and anant were talking about and forth about what the most appropriate design is
16:45:09 [rillianbis]
Harald: Tommy and Anant will work out a proposal
16:45:16 [rillianbis]
Adam: I also got into that discussion
16:45:24 [rillianbis]
So I think that will continue on the mailing list
16:45:27 [rillianbis]
it's a good discussion
16:45:37 [rillianbis]
Harald: the proposal will actually change the interface
16:45:52 [rillianbis]
to the mediastreamevent and will require that you have a listener on that
16:46:06 [rillianbis]
before it was possible to use MediaStreams without using an event listener
16:46:21 [rillianbis]
Adam: Right, you'll have a stream in a state where you can't use it
16:46:34 [rillianbis]
if we make the track list immutable it will help us in the future
16:46:49 [rillianbis]
I will make it a lot easier
16:46:57 [rillianbis]
Harald: you might not get away with that
16:47:15 [rillianbis]
in the case of remote streams, you'll have tracks popping up which weren't there before
16:47:31 [rillianbis]
Adam: right now you have all the tracks, but they're empty
16:47:42 [rillianbis]
Harald: how is that communicated?
16:47:50 [rillianbis]
Adam: with addStream signalling
16:48:09 [rillianbis]
harald: but what you're connecting to doesn't use addStream, they just appear
16:48:29 [rillianbis]
Need some kind of gateway to make them look like a peerconnection
16:48:48 [rillianbis]
Harald: The change to getUserMedia is non-controversial
16:48:58 [rillianbis]
but the change to MediaStream is controversial
16:49:05 [rillianbis]
Tim: I think the issue harald is describing
16:49:22 [rillianbis]
is that if we want to make the mediastream a representation of an RTP CNAME
16:49:41 [rillianbis]
we have to account for the possibility that a new track is added
16:49:55 [rillianbis]
Cullen: I don't think we have a very good definition of a track
16:50:42 [rillianbis]
Can't have everything in a peerconnection be synchronized
16:50:54 [rillianbis]
jesup: can't have that; they might come from different sources
16:51:14 [rillianbis]
the feeds could be coming from five different devices
16:51:29 [rillianbis]
Cullen: if you have a gateway
16:51:41 [rillianbis]
it may want to tell you that the five streams aren't synchronize
16:51:43 [rillianbis]
16:52:03 [rillianbis]
jesup: those streams are inherently unsynchronized
16:52:22 [rillianbis]
cullen: trying to syncronize them introduces latency
16:52:31 [rillianbis]
and delays them all if one loses a packet
16:52:54 [rillianbis]
someone else: application asks for video and audio at the same time with getUserMedia, so it can add video later if it wants to
16:53:03 [francois]
16:53:37 [rillianbis]
jesup: User may have accepted audio only, so escalating to video requires asking the user again
16:53:53 [rillianbis]
so you can't assume you don't have to call getuserMedia again.
16:54:12 [rillianbis]
Harald: we're running out of time, can someone take an action item to write down
16:54:23 [rillianbis]
what the media stream is and write to the list
16:54:28 [rillianbis]
Tim Terriberry: I can do that
16:54:37 [rillianbis]
Harald: Ok, you got it Tiem
16:54:49 [rillianbis]
topic: Plans for moving to FPWD by Oct 18
16:54:51 [francois]
Topic: Plans to move to FPWD
16:54:52 [francois]
ack me
16:55:10 [rillianbis]
francois: It's a good signal to the rest of the community
16:55:19 [rillianbis]
to other groups that we're making progress
16:55:27 [rillianbis]
it doesn't have to be complete
16:55:42 [rillianbis]
it's a good idea to flag sections which we're still discussion
16:55:47 [rillianbis]
apart from that
16:55:52 [rillianbis]
that only thing missing is an abstract
16:56:17 [rillianbis]
action item: editors to add an abstract before the next draft
16:56:17 [trackbot]
Sorry, couldn't find user - item
16:56:34 [rillianbis]
francois: we need a resolution that the group agrees to publish a draft
16:56:49 [rillianbis]
DanD: can do that on the list
16:57:02 [rillianbis]
francois: no, it has to be explicit
16:57:14 [burn]
s/DanD/Dan Burnett/
16:57:24 [rillianbis]
Harald: I think it's a good idea
16:57:25 [francois]
s/no, it has to be explixit/yes, it just has to be archived/
16:57:33 [rillianbis]
No objection
16:57:39 [rillianbis]
I'll send a note to the list
16:57:57 [rillianbis]
Inserted agenda point (3 minutes left)
16:58:11 [rillianbis]
Are some people ok to stay late
16:58:14 [rillianbis]
(some people are)
16:58:19 [fluffy]
fluffy has joined #webrtc
16:58:21 [rillianbis]
Topic: low level api
16:58:43 [rillianbis]
Neil: based on our experince with phono, we'd like to see
16:58:49 [rillianbis]
the bare minimum in the browser
16:59:07 [rillianbis]
and do the rest of sdp in javascript
16:59:18 [francois]
zakim, mute me
16:59:18 [Zakim]
Francois_Daoust should now be muted
16:59:22 [rillianbis]
Cullen: I think the only thing it would take to convince me this was a good thing
16:59:39 [rillianbis]
is a clear idea that this was mapping to an existing signaling only gateway
16:59:49 [rillianbis]
my concerns would be the complexity of the js
16:59:58 [rillianbis]
and getting that right
17:00:11 [rillianbis]
if it were just audio, I'd be for that
17:00:26 [rillianbis]
but the complexity of the parameters with video are complicated
17:00:38 [rillianbis]
e.g. the number of macroblock per second the decoder can process
17:00:52 [rillianbis]
there are a bunch of different variables you have to negotiation
17:00:57 [rillianbis]
17:01:16 [rillianbis]
and many codec-specific constraints
17:01:28 [rillianbis]
where's the best place to do that negotiation, browser, or javascript?
17:01:36 [rillianbis]
next year, if a better video codec comes out
17:01:51 [rillianbis]
I want websites written in a basic way
17:01:56 [rillianbis]
to be able to take advantage of that
17:02:11 [rillianbis]
jesup: since the parameters are codec-specific
17:02:17 [rillianbis]
some of them map to each other
17:02:29 [rillianbis]
but when a new codec comes out, there's not prebuilt mapping
17:02:33 [rillianbis]
js can use
17:02:46 [rillianbis]
cullen: the last time I looked at this, this was the part which was hard
17:02:57 [rillianbis]
and I think that's what we need to look at to figure out what to do
17:03:15 [rillianbis]
jesup: there's no guarantee websites will upgrade
17:03:29 [rillianbis]
cullen: e.g. most prevelent jquery is the first one that really worked
17:03:49 [rillianbis]
so many people pick a version and never upgrade
17:04:02 [rillianbis]
Neil: so we need to prove we have no data in the javascript?
17:04:12 [rillianbis]
Cullen: we need to talk about the tradeoffs
17:04:24 [rillianbis]
let's look at a new video codec, because that's the most complicated case
17:04:37 [rillianbis]
justin: I'd like to look at RTP, encryption
17:04:48 [rillianbis]
I like the flexibility this approach provides
17:05:09 [rillianbis]
but I'm concerned it makes it impossible for anyone but experts to do this
17:05:30 [rillianbis]
and if it *is* done in the browser, experts can improve the chances of iteroper
17:06:17 [rillianbis]
My concern is specifically that at the API if we have an opaque blob generated by the browser
17:06:32 [rillianbis]
we'll have a better chance of interoperability than if that blob is generated by a web applicaiton
17:06:41 [rillianbis]
because there are fewer things to test
17:06:51 [francois]
17:07:04 [rillianbis]
Neil: We could just test/certify the js libraries
17:07:27 [rillianbis]
Neil: do browsers support downloadable or 3rd party codecs? that raises the same issue
17:07:42 [rillianbis]
Tim: Safari sort of does, in a limited way, but that's the only one
17:07:56 [rillianbis]
jesup: this has been considered out of scope
17:08:31 [rillianbis]
Cullen: downloading a codec wouldn't be enough, you'd need to also download the negotiation logic for the codec
17:08:54 [rillianbis]
Harald: With the addition of downloaded codecs, we have *three* moving pieces that need to know about each other
17:09:09 [rillianbis]
Tim: Regardless of the intents of this group to make an api for experts only
17:09:14 [rillianbis]
people will use it
17:09:23 [rillianbis]
we've seen with video codecs
17:09:28 [rillianbis]
that users love starship consoles
17:09:38 [rillianbis]
and if you give them knobs to tweak they will tweak them
17:09:51 [rillianbis]
regardless of whether it's a good idea or not
17:10:10 [rillianbis]
Neil: but giving the flexibility to those who want them is a good idea, surely?
17:10:35 [rillianbis]
Cullen: I like that js can do absolutely anything, but I also want things to be as simple as possible
17:10:51 [rillianbis]
someone else: can't do both easy and expert interfaces in the same API
17:11:02 [hta]
someone else = Justin
17:11:22 [rillianbis]
jesup: I don't have a problem with a layered api to do that
17:11:36 [rillianbis]
cullen: if you think the javasscript can't do it with the sdp,
17:11:45 [rillianbis]
I think that's why we say "offer answer"
17:11:57 [rillianbis]
I think it would be hard to find something you couldn't do by modifying the SDP
17:12:29 [rillianbis]
Tim D(?): We think it's safer to manipulate the SDP than to have an actual API?
17:12:36 [rillianbis]
Cullen: well, they'd use a library
17:12:49 [burn]
s/Tim D(?)/Tim Panton/
17:13:00 [rillianbis]
jesup: Anything that exposes the encryption keys to js
17:13:09 [rillianbis]
means your media isn't secure
17:13:20 [rillianbis]
SRTP-DES is a problem because of this
17:13:28 [rillianbis]
Harald: this is covered by the security draft
17:13:44 [rillianbis]
To close up the discussion, we don't have consensus for one or the other here
17:14:10 [rillianbis]
It occurs to me...
17:14:22 [rillianbis]
Can I ask you and Cullen to take the action item
17:14:25 [rillianbis]
to figure out this issue
17:14:38 [rillianbis]
justin: The other thing I'd like to understand is
17:14:40 [Zakim]
17:14:46 [burn]
s/ask you and Cullen/ask Neil and Cullen/
17:15:10 [rillianbis]
sorry, I fell off the call
17:16:26 [francois]
[scribe dropped of the call, some exchanges missed]
17:16:38 [francois]
scribenick: francois
17:17:16 [francois]
Cullen: glad to work with people on this. Doable to do an API on this. It's a trade-off to reach. Complicated cases would need to be mapped to SDP.
17:17:31 [francois]
... You're re-inventing an alternative to SDP here, make no mistake.
17:17:56 [francois]
... Watched this several times, and it's not a good path to follow.
17:18:16 [francois]
DanBurnett: is it reinventing SDP or allowing Web developers who do not know SDP to use it?
17:18:53 [francois]
Cullen: I can't tell how it's different, but I think you're right.
17:19:05 [francois]
??1: In general, the difference is in the intelligence of the client.
17:19:33 [burn]
s/who do not know SDP to use it/who may or may not be experts in codec negotiation to develop alternatives/
17:19:51 [burn]
s/??1/Tim Panton/
17:19:52 [francois]
Harald: let's take the discussion to the list, Neil and Cullen to drive the discussion.
17:20:01 [Zakim]
17:20:24 [rillianbis]
I just want to inform the group of the of the IETF audio working group
17:20:27 [francois]
Topic: Liaison with other WG
17:20:39 [francois]
s/I just want/Stefan: I just want/
17:21:13 [rillianbis]
there was another proposal which was Mozilla proprietary extension to Media streams which could solve this
17:21:23 [rillianbis]
and I think there wasn't good progress on this
17:21:38 [rillianbis]
we are hoping to have a joint session with the audio working group
17:21:43 [rillianbis]
to discuss this furthere
17:21:47 [rillianbis]
any questions?
17:21:55 [rillianbis]
comments on Tim?
17:22:05 [rillianbis]
Tim: That sounds like an accurate summary
17:22:10 [francois]
[Remember to register for TPAC: Deadline 14 October]
17:22:17 [rillianbis]
wrt TPAC, I think the others are relatively open
17:22:25 [rillianbis]
should I plan of sticking around for those?
17:22:35 [rillianbis]
Dan Burnett: depends an what you want to attend
17:22:56 [rillianbis]
??: Is there anything you'd recommend, Dan?
17:23:11 [rillianbis]
Dan B: the plenary on wednesday is a good way to find out what the hot topics are
17:23:29 [rillianbis]
We're doing potentially the html speech working group on Thursday
17:23:58 [francois]
[On Thursday/Friday: HTML WG, DAP, HTML Speech XG are meeting]
17:24:00 [rillianbis]
and ultimately there might be a need to mix Interactive Voice Response applicaitons
17:24:12 [rillianbis]
with this group
17:24:35 [rillianbis]
??: Next liason point
17:24:41 [rillianbis]
Rich: Device apis
17:24:46 [rillianbis]
Media Capture api: no work for a year
17:24:53 [rillianbis]
hope at TPAC we'll prune this
17:24:58 [rillianbis]
and over to WebRTC for getUserMedia
17:25:04 [rillianbis]
still got HTML Media Capture
17:25:08 [rillianbis]
but that's not able getting objects
17:25:13 [rillianbis]
but prerecorded audio vidoe
17:25:19 [rillianbis]
also web intents, discovery
17:25:20 [derf]
17:25:28 [rillianbis]
which may be of interest
17:25:31 [rillianbis]
meeting friday
17:25:41 [rillianbis]
if there's stuff from webrtc which might find a home in dap
17:25:45 [rillianbis]
we'd welcome that
17:25:49 [francois]
s/meeting friday/meeting Thursday and Friday/
17:26:02 [rillianbis]
Harald: we're at the end of the agenda
17:26:04 [francois]
ack me
17:26:05 [rillianbis]
only 1.5 hours
17:26:11 [rillianbis]
any other business
17:26:22 [rillianbis]
francois: anyone planning to attend remotely?
17:26:30 [rillianbis]
need to schedule if we need a polycom
17:26:41 [rillianbis]
justin: I'm hoping to attend in person
17:26:46 [rillianbis]
but if now, I'd like to call in
17:27:00 [rillianbis]
??: I find it very difficult to have remote participants in f2f meetings
17:27:18 [rillianbis]
It's ok to have in the room, but I don't think we should assume that's an option
17:27:27 [burn]
s/??/Dan Burnett/
17:27:27 [francois]
17:27:46 [rillianbis]
jesup: what worked at the last IETF meeting was having someone take comments from IRC and speak them at the mic
17:27:56 [rillianbis]
which helps a lot with those issues
17:28:13 [rillianbis]
francois: If you think you'll attend remotely, let me know by next Wednesday
17:28:38 [rillianbis]
Harald: Let's close the meeting
17:28:41 [rillianbis]
Thanks all!
17:28:41 [Zakim]
17:28:43 [Zakim]
17:28:44 [Zakim]
17:28:44 [Zakim]
17:28:46 [Zakim]
17:28:46 [Zakim]
17:28:46 [Zakim]
17:28:47 [burn]
s/that's an option/that's a good option for participants/
17:28:47 [Zakim]
17:28:48 [Zakim]
17:28:50 [Zakim]
17:28:52 [Zakim]
- +1.610.889.aaoo
17:28:52 [francois]
Zakim, list attendees
17:28:54 [Zakim]
17:28:56 [Zakim]
17:28:58 [Zakim]
17:29:01 [Zakim]
As of this point the attendees have been +47.41.44.aaaa, +1.604.728.aabb, Dan_Burnett, +44.122.375.aacc, Ralph_Giles, Neil_Stratford, +, +1.408.562.aaee,
17:29:03 [Zakim]
... +1.403.244.aaff, Harald_Alvestrand, Stefan_Håkansson, +1.425.580.aagg, +972.3.645.aahh, Tim_Panton, Cullen_Jennings, +34.38.83.aaii, +, Dan_Druta,
17:29:06 [Zakim]
... +44.208.144.aakk, richt, DanRomascanu, +1.314.529.aall, +1.425.894.aamm, Mani_Mahalingam, Adam_Bergkvist, Christophe_Eyrignoux?, Justin_Uberti, Francois_Daoust, Tim_Terriberry,
17:29:09 [Zakim]
... +1.408.421.aann, +1.610.889.aaoo
17:29:11 [Zakim]
- +1.314.529.aall
17:29:13 [Zakim]
17:29:15 [Zakim]
17:29:16 [francois]
RRSAgent, draft minutes
17:29:16 [RRSAgent]
I have made the request to generate francois
17:29:17 [Zakim]
17:29:19 [Zakim]
UW_(WebRTC)12:00PM has ended
17:29:21 [Zakim]
Attendees were +47.41.44.aaaa, +1.604.728.aabb, Dan_Burnett, +44.122.375.aacc, Ralph_Giles, Neil_Stratford, +, +1.408.562.aaee, +1.403.244.aaff, Harald_Alvestrand,
17:29:26 [Zakim]
... Stefan_Håkansson, +1.425.580.aagg, +972.3.645.aahh, Tim_Panton, Cullen_Jennings, +34.38.83.aaii, +, Dan_Druta, +44.208.144.aakk, richt, DanRomascanu,
17:29:33 [Zakim]
... +1.314.529.aall, +1.425.894.aamm, Mani_Mahalingam, Adam_Bergkvist, Christophe_Eyrignoux?, Justin_Uberti, Francois_Daoust, Tim_Terriberry, +1.408.421.aann, +1.610.889.aaoo
17:29:42 [rillianbis]
Sorry about dropping out there at the end.
17:30:17 [rillianbis]
We just moved office and our phones aren't working yet. Ran out of credit on my mobile.
17:30:31 [rillianbis]
francois: thanks for the help with corrections
17:31:44 [Mani]
Mani has left #webrtc
19:32:43 [Zakim]
Zakim has left #webrtc
20:38:14 [francois]
RRSAgent, bye
20:38:14 [RRSAgent]
I see 1 open action item saved in :
20:38:14 [RRSAgent]
ACTION: item to editors to add an abstract before the next draft [1]
20:38:14 [RRSAgent]
recorded in