- From: Francois Daoust <fd@w3.org>
- Date: Thu, 06 Oct 2011 18:52:37 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi all,
The minutes of yesterday's WebRTC call are available at:
http://www.w3.org/2011/10/05-webrtc-minutes.html
... and copied as raw text below.
I may have missed a couple of people present at the call. Let me know if you're not on the present list and should be.
Thanks,
Francois.
-----
Web Real Time Communications Working Group
05 Oct 2011
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0099.html
See also: [3]IRC log
[3] http://www.w3.org/2011/10/05-webrtc-irc
Attendees
Present
Harald_Alvestrand, Adam_Bergkvist, Dan_Burnett,
Francois_Daoust, Dan_Druta, Christophe_Eyrignoux,
Ralph_Giles, Stefan_Håkansson, Cullen_Jennings,
Randell_Jesup, Mani_Mahalingam, Tim_Panton, Dan_Romascanu,
Neil_Stratford, Tim_Terriberry, Rich_Tibbett, Justin_Uberti
Regrets
Chair
Harald
Scribe
Ralph_Giles
Contents
* [4]Topics
1. [5]Changes made to the editors draft
2. [6]MediaStream inheritance
3. [7]Data channel API
4. [8]Glare resolution
5. [9]Changes to getUserMedia
6. [10]Plans for moving to FPWD by Oct 18
7. [11]Plans to move to FPWD
8. [12]low level api
9. [13]Liaison with other WG
* [14]Summary of Action Items
_________________________________________________________
Harald: Agenda sent out on the 27th
... reviewing items
since then, we've added low-level javascript api proposal
Changes made to the editors draft
cullen: Overview of the changes to the draft
... primary set of changes was around separating the ICE state
machine a bit
... Want feedback on the overall model
... ICE state machine checks candidates, and can start using some
while still waiting for other candidates at the same time you have
have the negotiation with the other endpoint going on
... codecs, ICE parameters, etc
... separated those two aparet
... and tried to update the text and semantics around when things
change state
Cullen: second change:
... want to redo how we do the data channel and the data api
... commented out what was in the previous draft
... since it didn't have agreement
... will replace it based on discussion today and on the list going
forward
... those are the major changes
MediaStream inheritance
Adam: had a discussion on the mailing list about confusing text
... about how you can create a stream from another stream, and if
you disable tracks in the parent they affect the derived streams
... the usecase was to clone streams e.g. to send a copy of a stream
somehwere else
... but you might want different attributes, e.g. to mute the copy
you're uploading
... 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
... this is easier to understand
... that was teh first step
... the second was to be able to create a new stream that contained
components gathered from multiple other streams
... e.g. to combine all the audio tracks from multiple incoming
streams and record a single file with all the conversation audio
... has implications wrt sync, but we'll take that as a separate
discussion
Data channel API
harald: next item, assuming people are ok with non-inherentance
... shall we talk about the data channel api for a moment
... the main thing going on is the deletion of that part of the spec
... but the part that has been happening is that eric (sp?)
... has suggested how you could define a protocol for this
... and multiplex multiple streams over the channel
... most of this is happening at the IETF, but what implication does
this have for the API
justin: there is a need to have multiple channels
... so it's nice not to do that at the application level
... and also signal reliable vs unreliable
cullen: can we just have a data channel, which you add like an audio
or video stream
... regardless of whether it's reliable or not, I care about
realtime/low-latency data transmission
... that's the important distinction
... of course if the library does that form me, that's great
... but can always build something
justin: agree
randell: also agree
someone else: requirements address low latency, reliability
harald: requirements are strict on congestion control
... that means we have to throw data away
... so a tradeoff we have to be aware of is that reliable will be
slow
tim terriberry: we can't assume the endpoint supports data
... so adding a data stream needs to be able to fail, we should
reuse the a/v stream api for that
someone else: you don't even know if the other side supports data
right now
harald: in the absence of a draft
... the group is drifting to having a data channel you can add just
like a media stream
justin: yes, the other side has a data stream show up just like a/v
... and you can have multiple such data streams with different
properties
<fluffy> +1 what Justin said
question: thoughts on peer streams vs peer tracks
cullen: just make them exactly like a mediastream as much as
possible
... one issue is that tracks are SSRC identified, and demuxed that
way
... while the data stream my have internal muxing
... the lowest unit of a/v transmission is the track, which is an
assymmetry
question: how do you create data streams?
it's strange if the peerconnection is the factory?
harald: could have an .addData() method
... right now we don't have a method of having tracks in a media
stream
... so we don't have a symmetric operation of creating data tracks
... right now getUserMedia just make a stream appear
... and we can add streams to that
... it would be something similar to it
... getUserMedia must be async
... but getDataStream could be sync
Harald: people have argued, we should just have what's effectively
capture keyboard and have that be a stream
Next agenda point.
Glare resolution
Cullen: Basic issue is that if we're using browsers with SDP to
negotiate
... ignore SIP, etc. for now
... if we're using offer/answer
... and if you and the other side both send offers at the same time
(glare)
... SDP doesn't have a way to resolve that
... both sides need to retry
... the way I characterized glare in sip on the IETF thread was sort
of wrong but the issue is if we're using SDP we need to handle glare
... 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 and the way sip does it
isn't necessarily optimal
... one question here is, will the sip approach change?
... will we invent a backwards-compatibile glare resolution which
can be used for any SDP protocol
... the other question is if we want to be able to gateway to SIP
wrt to glare handling
... either way we have to deal with glare somewhere.
... So, that sets the stage for discussion
Tim Terriberry: what API implications are there?
... your glare resolution had a magic number, do we need to expose
that?
cullen: I don't think that has api implications
... the only implication is that things might take longer than you
think
... adding a stream will always be async because there's some back
and forth there
someone else: if you throw these SDP messages away
... if you find a glare, it would be better to reuse the message
... just a thought
cullen: I think that would be an attempt to resolve this in in a
better way
... one side backs down, and that would be a faster way to do that
but I don't think it affects the api
... 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.
... it's not as bad as I originally made it sound
harald: no specific comments?
one question for cullen: if we go with this number thing to do
faster resolution, would that still work with sip?
cullen: yes. this problem exists in sip as well, so anyone using SDP
offer/answer would move to this
... it would have to be an mmusic draft in the IETF
... if you didn't have the number, you'd fall back to something
which was compatible with the way older sip devices did it
... but if you had the number it would resolve the glare faster
... maybe even if only one side uses the new resolution it might go
faster
... 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
I wonder if this is premature optimization
jesup: I wonder if we lock ourselves in to glare when we're
switching modes, or if there's been an interface changes which
affects bandwidth
cullen: good questions
... interfaces changes tend to be one sided, so they don't result in
glare
... changes to network are more of a problem
... e.g. congestion causes them to drop video
... we need to design algorithms so both sides don't try to do that
at the same time
... cisco telepresense is designed so the two ends aren't likely to
switch within a few 100 ms
... that's by design, but so far it hasn't been a issue
Harald: Cullen will work more on the glare problem
Changes to getUserMedia
Harald: we have implementation feedback
... js argument to getUserMedia
... tim's note on json hints for mediastreams
... seems to me these are all reasonable things to do
... modulo suggested modifications
... want to keep getusermedia async
... any other comments?
jesup: As far as the async nature of getUserMedia, it's still async
in anant's proposal
... but it's async in a different way
... you get a stream right away but it's inactive until you get an
event
tommy and anant were talking about and forth about what the most
appropriate design is
Harald: Tommy and Anant will work out a proposal
Adam: I also got into that discussion
... So I think that will continue on the mailing list
... xit's a good discussion
Harald: the proposal will actually change the interface to the
mediastreamevent and will require that you have a listener on that
... before it was possible to use MediaStreams without using an
event listener
Adam: Right, you'll have a stream in a state where you can't use it
... if we make the track list immutable it will help us in the
future
... It will make it a lot easier
Harald: you might not get away with that
... in the case of remote streams, you'll have tracks popping up
which weren't there before
Adam: right now you have all the tracks, but they're empty
Harald: how is that communicated?
Adam: with addStream signalling
harald: but what you're connecting to doesn't use addStream, they
just appear
... Need some kind of gateway to make them look like a
peerconnection
Harald: The change to getUserMedia is non-controversial
... but the change to MediaStream is controversial
Tim: I think the issue harald is describing is that if we want to
make the mediastream a representation of an RTP CNAME, we have to
account for the possibility that a new track is added
Cullen: I don't think we have a very good definition of a track
... Can't have everything in a peerconnection be synchronized
jesup: can't have that; they might come from different sources
... the feeds could be coming from five different devices
Cullen: if you have a gateway
... it may want to tell you that the five streams aren't
synchronized
jesup: those streams are inherently unsynchronized
cullen: trying to synchronize them introduces latency and delays
them all if one loses a packet
someone else: application asks for video and audio at the same time
with getUserMedia, so it can add video later if it wants to
jesup: User may have accepted audio only, so escalating to video
requires asking the user again so you can't assume you don't have to
call getuserMedia again.
Harald: we're running out of time, can someone take an action item
to write down what the media stream is and write to the list
Tim Terriberry: I can do that
Harald: Ok, you got it then
Plans for moving to FPWD by Oct 18
francois: It's a good signal to the rest of the community
... to other groups that we're making progress
... it doesn't have to be complete
... it's a good idea to flag sections which we're still discussion
... apart from that the only thing missing is an abstract
<scribe> ACTION: editors to add an abstract before the next draft
[recorded in
[15]http://www.w3.org/2011/10/05-webrtc-minutes.html#action01]
francois: we need a resolution that the group agrees to publish a
draft
Dan Burnett: can do that on the list
francois: yes, it just has to be recorded somewhere and archived.
Harald: I think it's a good idea
[No objection heard]
Harald: I'll send a note to the list
Inserted agenda point (3 minutes left)
Are some people ok to stay late
(some people are)
Low level API
Neil: based on our experince with phono, we'd like to see the bare
minimum in the browser and do the rest of sdp in javascript
Cullen: I think the only thing it would take to convince me this was
a good thing
... is a clear idea that this was mapping to an existing signaling
only gateway
... my concerns would be the complexity of the js and getting that
right
... if it were just audio, I'd be for that but the complexity of the
parameters with video are complicated
... e.g. the number of macroblock per second the decoder can process
... there are a bunch of different variables you have to negotiate
and many codec-specific constraints
... where's the best place to do that negotiation, browser, or
javascript?
... next year, if a better video codec comes out
... I want websites written in a basic way to be able to take
advantage of that
jesup: since the parameters are codec-specific
... some of them map to each other
... but when a new codec comes out, there's not prebuilt mapping js
can use
cullen: the last time I looked at this, this was the part which was
hard and I think that's what we need to look at to figure out what
to do
jesup: there's no guarantee websites will upgrade
cullen: e.g. most prevelent jquery is the first one that really
worked
... so many people pick a version and never upgrade
Neil: so we need to prove we have no data in the javascript?
Cullen: we need to talk about the tradeoffs
... let's look at a new video codec, because that's the most
complicated case
justin: I'd like to look at RTP, encryption
... I like the flexibility this approach provides
... but I'm concerned it makes it impossible for anyone but experts
to do this
... and if it *is* done in the browser, experts can improve the
chances of iteroperate
... My concern is specifically that at the API if we have an opaque
blob generated by the browser
... we'll have a better chance of interoperability than if that blob
is generated by a web application because there are fewer things to
test
Neil: We could just test/certify the js libraries
... do browsers support downloadable or 3rd party codecs? that
raises the same issue
Tim: Safari sort of does, in a limited way, but that's the only one
jesup: this has been considered out of scope
Cullen: downloading a codec wouldn't be enough, you'd need to also
download the negotiation logic for the codec
Harald: With the addition of downloaded codecs, we have *three*
moving pieces that need to know about each other
Tim: Regardless of the intents of this group to make an api for
experts only
... people will use it
... we've seen with video codecs
... that users love starship consoles
... and if you give them knobs to tweak they will tweak them
... regardless of whether it's a good idea or not
Neil: but giving the flexibility to those who want them is a good
idea, surely?
Cullen: I like that js can do absolutely anything, but I also want
things to be as simple as possible
Justin: can't do both easy and expert interfaces in the same API
jesup: I don't have a problem with a layered api to do that
cullen: if you think the javasscript can't do it with the sdp, I
think that's why we say "offer answer"
... I think it would be hard to find something you couldn't do by
modifying the SDP
Tim Panton: We think it's safer to manipulate the SDP than to have
an actual API?
Cullen: well, they'd use a library
jesup: Anything that exposes the encryption keys to js means your
media isn't secure
... SRTP-DES is a problem because of this
Harald: this is covered by the security draft
... To close up the discussion, we don't have consensus for one or
the other here
... It occurs to me...
... Can I ask Neil and Cullen to take the action item to figure out
this issue?
justin: The other thing I'd like to understand is
<francois> [scribe dropped of the call, some exchanges missed]
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.
... You're re-inventing an alternative to SDP here, make no mistake.
... Watched this several times, and it's not a good path to follow.
DanBurnett: is it reinventing SDP or allowing Web developers who may
or may not be experts in codec negotiation to develop alternatives?
Cullen: I can't tell how it's different, but I think you're right.
Tim Panton: In general, the difference is in the intelligence of the
client.
Harald: let's take the discussion to the list, Neil and Cullen to
drive the discussion.
Liaison with other WG
Stefan: I just want to inform the group of the of the IETF audio
working group
... there was another proposal which was Mozilla proprietary
extension to Media streams which could solve this
... and I think there wasn't good progress on this
... we are hoping to have a joint session with the audio working
group
... to discuss this further, any questions?
Tim: That sounds like an accurate summary
[Remember to register for TPAC:
[16]http://www.w3.org/2002/09/wbs/35125/TPAC2011/ Deadline 14
October]
[16] http://www.w3.org/2002/09/wbs/35125/TPAC2011/
Cullen: wrt TPAC, I think the other meetings are relatively open
... should I plan of sticking around for those?
DanBurnett: depends on what you want to attend
Cullen: Is there anything you'd recommend, Dan?
DanBurnett: the plenary on wednesday is a good way to find out what
the hot topics are
... We're doing potentially the html speech working group on
Thursday
... and ultimately there might be a need to mix Interactive Voice
Response applications with this group>
[On Thursday/Friday: HTML WG, DAP, HTML Speech XG are meeting]
Stefan: Next liason point with DAP
Rich Device apis
... Media Capture api: no work for a year
... hope at TPAC we'll prune this and hand over to WebRTC for
getUserMedia
... still got HTML Media Capture but that's not about getting
objects but prerecorded audio video
... also web intents, discovery which may be of interest
... meeting Thursday and Friday
... if there's stuff from webrtc which might find a home in dap,
we'd welcome that
Harald: we're at the end of the agenda
... only 1.5 hours
... any other business?
Francois: anyone planning to attend remotely? need to schedule if we
need a polycom
Justin: I'm hoping to attend in person
... but if now, I'd like to call in
Dan Burnett: I find it very difficult to have remote participants in
f2f meetings
... It's ok to have in the room, but I don't think we should assume
that's a good option for participants
jesup: what worked at the last IETF meeting was having someone take
comments from IRC and speak them at the mic
... which helps a lot with those issues
Francois: If you think you'll attend remotely, let me know by next
Wednesday
Harald: Let's close the meeting
... Thanks all!
Summary of Action Items
[NEW] ACTION: editors to add an abstract before the next draft
[recorded in
[17]http://www.w3.org/2011/10/05-webrtc-minutes.html#action01]
[End of minutes]
Received on Thursday, 6 October 2011 16:53:09 UTC