Web Real-Time Communications Working Group Teleconference

<stefanh> agenda proposal: http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0044.html

<dom> ScribeNick: adambe

hta: there's one more agenda item
... we should officially aprove the minutes from the last meeting
... no objections

Action Items review

<stefanh> http://www.w3.org/2011/04/webrtc/track/actions/open

stefanh: first three open ones 11, 12 and 13

<dom> ACTION-11?

<trackbot> ACTION-11 -- Daniel Burnett to add Hints API to API spec -- due 2012-01-12 -- OPEN

<trackbot> http://www.w3.org/2011/04/webrtc/track/actions/11

<dom> ACTION-12?

<trackbot> ACTION-12 -- Daniel Burnett to add Stats API to API spec -- due 2012-01-20 -- OPEN

<trackbot> http://www.w3.org/2011/04/webrtc/track/actions/12

<dom> ACTION-13?

<trackbot> ACTION-13 -- Daniel Burnett to add Capabilities API to API spec -- due 2011-12-12 -- OPEN

<trackbot> http://www.w3.org/2011/04/webrtc/track/actions/13

stefanh: the three APs are on Dan
... We have discussed the capabilities/contraints proposal in the media capture TF
... next task is on Dan Druta

<dom> close ACTION-15

<trackbot> ACTION-15 Look into mechanisms to handle incoming notifications, and report to WG closed

DanD: stefanh initiated a mail thread on webapps saying that the webrtc group is interested in push notifications and the work shold be done in webapps

<dom> Regarding app notification and wake up thread on public-webapps

<dom> ACTION-15: see public-webapps thread http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1077.html

<trackbot> ACTION-15 Look into mechanisms to handle incoming notifications, and report to WG notes added

stefanh: next item is on ekr
... it has been discussed in the IETF group

<hta> Rescorla's draft: draft-rescorla-rtcweb-generic-idp-01

hta: ekr's draft just came out in a new version

stefanh: I think we sholud close this action

<fluffy> just got discconned - will dial back in

stefanh: and open a new one if we need to do further work

hta: yes, close it

stefanh: next action 18, is on me

<hta> Randell, you're already identified.

stefanh: It's about contacting the Web & TV interest group
... It's not done yet
... next one is on me (21)

<dom> ACTION-21?

<trackbot> ACTION-21 -- Stefan Håkansson to ensure that Randell get the echo cancellation into the spec -- due 2011-12-22 -- OPEN

<trackbot> http://www.w3.org/2011/04/webrtc/track/actions/21

stefanh: ensure that Randall gets echo cancellation into the spec

<jesup> me

<dom> Echo cancellation API bug in Bugzilla

jesup: I've created an issue in the bug tracker

stefanh: should we give fluffy the responsibility for the task previously assigned to jesup
... next task is on hta

<dom> ACTION: fluffy to incorporate echo cancellation API based on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747 [recorded in http://www.w3.org/2012/03/13-webrtc-minutes.html#action01]

<trackbot> Sorry, couldn't find user - fluffy

<dom> ACTION: cullen to incorporate echo cancellation API based on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747 [recorded in http://www.w3.org/2012/03/13-webrtc-minutes.html#action02]

<trackbot> Created ACTION-34 - Incorporate echo cancellation API based on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747 [on Cullen Jennings - due 2012-03-20].

<dom> close ACTION-21

<trackbot> ACTION-21 Ensure that Randell get the echo cancellation into the spec closed

stefanh: Task to change numeric constants to strings is on burn

<dom> ACTION-21: see follow-up in ACTION-34

<trackbot> ACTION-21 Ensure that Randell get the echo cancellation into the spec notes added

stefanh: we skip actions 30 and 31 (jsep and Data API)
... action 32 is a followup on DanD's task

<dom> close ACTION-32

<trackbot> ACTION-32 Contact webapps regarding push and notifications, saying it is important for webrtc and ask for webapps' plans closed

stefanh: it was on me and it's done, I propose we close it

<dom> ACTION-32: see http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1077.html

<trackbot> ACTION-32 Contact webapps regarding push and notifications, saying it is important for webrtc and ask for webapps' plans notes added

stefanh: ok, I guess we're done with the action

actions

fluffy: can we talk about the echo cancelation
... this is being incoperated in burn's contraints work

<jesup> Ok, good, thanks

stefanh: I'll add a note about it into the bug

fluffy: ok
... I'll help dan with it

burn: I will discuss it with fluffy

stefanh: next item is the API document
... I'll leave the floor to the editors
... we need a new scribe

(silence)

<hta> harald offers to scribe.

Data API

<dom> scribenick: juberti

<jesup> Thanks

he is

cullen: New changes to spec - Data API and JSEP
... data API is the main set of changes, going public this week
... JSEP changes not going into main document, going into separate document

someone: Data API, is it what was discussed on list, i.e. alignment with WebSockets?

adambe: Does it work exactly as WebSockets, with bufferedAmount

<hta> draft-jesup-rtcweb-data-protocol-00.txt

randell: New channels don't need to be negotiated in SDP

<dom> WebRTC Data Channel Protocol

thanks stefan

randell: no signaling is needed for data channel opens, but signaling needed to indicate the existence of the overall data channel

hta: Michael Tuexen has a draft for SDP desriptions of data channels

randell: Salvatore Loreto has a draft for SCTP over DTLS

<dom> so the data channel API will be incorporated in the main spec? or as a separate one?

hta: there are enough drafts for the data part of the channel, and Adam has proposed a viable API for the data channel
... is that a proper summary?

group: yes

<stefanh> in the main draft Dom

adambe: once we get data channel to certain level of maturity, can we use the bug tracker to advance the work?

<jesup> http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-channel-00.txt

cullen: can't log into bug tracker, we need to fix that first

<jesup> cullen++

cullen: we need to have a discussion about what tools we are going to use and discuss on the list, pick one way of how we are going to do things

dom: How will the data channel API be integrated into the WebRTC spec?
... planning to go to last call by end of 2Q 2012
... what is timeline for moving forward with all of these documents?
... Is the data API part of the main spec, or a separate doc?

someone: part of main spec

dom: will this inhibit our ability to move forward with the main spec?

hta: It's part of our regular work.
... Whether we're ready for last call, is another topic.

dom: If we can do modular specs, we can have less dependencies

cullen: There's not even an IETF WG document for how the signaling for data works
... It's a long way from done.

randell: We have reasonable consensus on what should be done, but there's still a bunch of work to do.

hta: Next topic

adambe: We mentioned JSEP briefly (JSEP was 3.2, data was 3.3)
... We're not going on to 4 yet.

hta: Dan Burnett isn't here

dan: I am here.

JSEP support

dan: I'm about to send a draft to the list for caps/hints

cullen: Taking current IETF JSEP draft and mapping it as closely as possible into a new WebRTC API document
... I've branched the existing doc for the spec
... Haven't gotten it done yet, but will be out by the end of the weekend
... This will be a proposal that we can compare against the current draft and we can see if we think this is acceptable
... if so, we can move it into the main doc, which should be simple since it's a standard branch
... nothing surprising in this doc, since it's mainly the same thing as the IETF doc
... there is a second branch that adam has created; adam, please describe

<dom> jspep_easy1 (adambe's) branch on webrtc editors draft

adambe: I thought that the new API (JSEP) made things harder. So I took some of the things from the old API, and tried to use JSEP from this API
... It hasn't been communicated that we are working on 2 different branches
... I think this is a problem, at some point we need to figure this out
... There are specific operations you need to do in a specific order, and we could combine those into building blocks

cullen: We need to get these drafts done and out to the lists
... Then we can compare and figure out what we want the editor draft to look like
... That's the next major set of work that we need to get done

adambe: We should have entier API IDLs and have examples in place

cullen: We need the baselines so that we can compare and the WG can provide feedback

hta: that was a long 2 minutes
... Does anyone else have comments on what was discussed?

stefanh: I would like a time estimate

cullen: by end of weekend
... by Sunday

adambe: I can publish something tomorrow (Wednesday)
... Fewer changes than Cullen's
... Do you see a problem if I present that one first?
... We can't compare until Cullen's work is done

cullen: THe sooner the better

hta: Send it out
... There is some skepticism, so let's see it as soon as possible

[silence]

hta: any more comments on JSEP?
... hearing done, Dan, are you ready?

<scribe> done=none

Constraints and hints

<dom> Constraints and Capabilities API for getUserMedia: more detailed proposal

<dom>

<dom> New draft-burnett-rtcweb-constraints-registry-00

<dom> IANA Registry for RTCWeb Media Constraints

dan: Registry is a very basic drat
... used by GetUserMedia and WebRTC
... constraints are for audio and video
... page 4, media types are audio and video

<dom> RTCWeb Media Constraints

dan: currently the only constraint types are min, max, and enum
... contraints need to begin with an alpha character
... the only requirements that IANA needs to follow is a name and a reference or lst of refs
... Need for expert review, instructions for designated expert
... Names must be < 80 chars long
... Names should be human readable
... requirement that if you have a tpe of audio, must be relevant for audio streams, same for video
... 2 pieces for constraints - how they can be used when requesting a stream, and how they can be used as capabilites informations

[dan] min constraint type indicates the min value an author is willing to accept

dan: could be width, height, bandwidth
... just because you have a minwidth and a minheight, doesn't mean you can get both of those together
... max is similar to min
... enum example - audio is either 'voice' or 'generic'
... not defining this now, but this is an example
... some other words in here - that the constraint is understandable
... everything we've come up with so far has fallen into the 3 categories (min/max/enum)

cullen: Combining height/width and aspect ratio allowed us to solve all the use cases that have been brought up

dan: are there any questions about the registry?

dom: will we seed the registry with pre-existing constraints?

dan: these documents will register constraints

dom: aspect ratio is a constraint - is that an enum?

dan: I sent a link with an example to the list

<fluffy> example at http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html

dan: we can look at that example now
... aspect is a flaoting-point min/max
... 4:3 can be represented (imperfectly) as floating point
... any other questions?
... dom, did that answer your question?

dom: will using an approximation cause problems down the line?

dan: I don't think it will be a problem for most apps
... The approximation is close enough

cullen: You need to specify enough digits so that multiplying aspect times height gives you the right width.

dan: work will be in precisely definining this

juberti: need to find a new room

<dom> scribenick: fluffy

<dom> Constraints and Capabilities API for getUserMedia: more detailed proposal

dan: Moving off the registry topic and on to the topic of email at http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html

richt: Looking at proposal and use cases. Would be nice to have use cases for local capture and local media.

<juberti> back

hta: There are some uses cases. HTA will try and post link.

<hta> https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#find-the-ball-assignment--video-effects-and-upload-requirements

<hta> the specific requirement is "Set the webcam into a low-resolution (320x200 or as supported by the hardware) capture mode"

<dom> ACTION-25?

<trackbot> ACTION-25 -- Harald Alvestrand to action Travis to Draft a setup of initial requirements based on the WebRTC and the Scenarios document -- due 2012-03-06 -- OPEN

<trackbot> http://www.w3.org/2011/04/webrtc/track/actions/25

stefanh: Requirements are not spelled out in use case document - Travis is going to start requirements document that derives the requirements from the scenario documents.

richt: Was looking at IETF requirements document but want to see how it maps to the local use cases.

dan: will look at requirements document and make sure it aligns with this proposal
... not sure of status of current link or connection but will investigate
... Constraint replaces old hint
... Constraint has an mandatory list and an optional list
... Constraint is a key value pair

<dom> Example from Dan's message:

<dom> Example:

<dom> navigator.getUserMedia(

<dom> {mandatory:[video-min-height:600, video-max-bandwidth:500],

<dom> optional:[

<dom> video-max-aspectratio:1.333333333333,

dan: May want to come up with more restrictions on things like lengths of values

<dom> video-min-timebetweenrefframes:20,

<dom> video-min-framerate:30,

<dom> video-autowhitebalance:on]},

<dom> gotStream, didntGetStream);

dan: There was a questions for algorithm to process these constraints. This time there is a write up of the algorithm.
... look at the example, after the algorithm, this shows what it might look like

<dom> how would you specify whether you want audio (or not) at all? is "audio" a constraint itself?

dan: two lists, and the lists are ordered

<dom> (I'm not sure I understand how I would do echo cancellation with that approach)

dan: In this case, the intent is they get a video stream with a min hight of 600 pixels, and max bandwidth of 500 (whatever the units are) . These are absolute and if they don't get this they want an error if both of these are not satisfied. Additional, they have some optional things they hope can satisfied in priority order. They would like aspect ration of 4/3.
... video-autowhitebalance:on should be video-enum-autowhitebalance:on
... If browser can do video-min-timebetweenrefframes:20, and als could do video-min-framerate:30, but not both, then the browser should do the video-min-timebetweenrefframes:20,
... When talking about mandatory constraints, order does not matter. For optional, needed to sperate audio and video
... Basis is a set and algorithm is removing some streams from it
... want to make sure never remove all audio or all video stream
... could end up with all stream remvoed

<juberti> Dropping off

dan: In the cases of optional for two different type of media constraint, does optional mean eliminate all of one type, is that OK, or is there implicit assumption they want at lease one video and one audio. As an app developer, I would want one of both
... Moving to Capabilities
... having challenges with webild
... In the trusted cases, for each device, we get the constraints with values.

<dom> I think that rather than {camera001:...,camera002:...} it would be more logical to have {cameras:[{...}, {...}]}

dan: So when we get video-max-width: 1024, this means there is no video stream this camera can provide with a width greater than 1023
... did not deal with ENUM values yet - not sure that this is information we need. Will add if this is needed

<dom> I think enums would be logically mapped to array of values?

hta: Can imagine a case where one is using values and would want to know all values. For example camera supports b/w , color, and infrared

dan: LIke some uses cases where need to return more than one value. In this case will need to discuss the syntax
... Most of work is in defining the constraints

hta: Should make sure the first constraints we do are mapped back to requirements and use cases

stefanh: this is what was proposed in TF and got a lot of support

hta: Thank you very much, continue discussion on list

stefanh: Most important action are for Cullen and Adam to get the JSEP like API proposal out

<Tim> Is there likely to be JSEP supporting implemenation in the near future ?

dan: Plan for next Telco ?

hta: Some time after IETF

<hta> action stefanh create doodle for next meeting

<trackbot> Sorry, couldn't find user - stefanh

stefanh: Stephan has action to set up next telco

<jesup> ta!

hta: End of meeting - Bye

<dom> ACTION: stefan create doodle for next meeting [recorded in http://www.w3.org/2012/03/13-webrtc-minutes.html#action03]

<trackbot> Created ACTION-35 - Create doodle for next meeting [on Stefan Håkansson - due 2012-03-20].

<Josh_Soref> trackbot, end meeting