See also: IRC log
hta: Welcome, Intro parts,
including IPR policy
... going to discuss Issues and PRs. Hope to get webrtc-pc to
CR real soon, but need the spec to stabilize
... for each issue/bug we need to decide if it needs fixing now
(and if so: how) or if it can wait for a later spec
version.
... Going to cover 5 PRs today, hopefully we can decide to
merge as many as possible of them and some Issues where we need
more discussion to determine what to do.
hta: Let's start with PRs.
J-I: PR 1030/Issue 116:
... (see slide 7)
J-I: uses sender and recevier as
selectors rather than track.
... plus a selector algorithm
... described in the slide.
... note that Inbound and Outbound in the slide are mixed up
(may be corrected to a later version of the slides before
making and uploading a pdf)
... was looking for language that associated a sender/receiver
with its stats object, may need better than I have here in the
proposal
hta: trying to remember the name. RTPStream corresponds to an encoding.
J-I: any objections on the
concept? (More details one the next slide)
... Slide 8...
... main value of a selector: some users have up to 50 tracks
for a peer connection, being able to select on track (or
sender/receiver) helps a lot
adambe: Has there been any discussion on deprecating the selector completely and instead have getStats on a sender/receiver?
Cullen: that sounds like a better API to me
hta: Implementation wise it is
easier to add a new API than a new selector
... not speccing a selector would make sense.
J-I: I am open for another API
than using a selector.
... are we talking about sender.getStats etc.?
adambe: yes, essentially?
bernard: how to get ICE stats and so on?
adam: have getStats on PeerConnection would give you ICE stats?
J-I: One way would be to merge this PR and than another to add getStats on sender/receiver.
hta: if we keep track as selector merging this PR makes sense.
bernard: are we adding getStats to other objects (like ICE transport, ... )?
hta: with chairs hat: we don't want to add APIs we do not have requests for.
J-I: filtering in JS is easy.
hta: getStats on new objects would need someone driving it - would be a new a feature.
J-I: if we modify this PR to just get the algorithm in, and merge, would that be OK?
hta: conclusion: merge algorithm, keep track as selector, treat getTrack proposals for other object as new feature request.
Cullen: we also need to fix the selector algorithm to make it correct in terms of SSRC
<scribe> Done with that one.
(jan-ivar had to leave the call after this item)
Taylor: hybrid OAUTH solution.
Taylor: captures the consensus of last meeting
Taylor: 160 bit conflict.
... seems like an Issue
People agree, and proposes this is a bug in 7635
Justin will look into what to do about 7635 and 160 bit
scribe: slide 11
Cullen: we should just decide we need crypto agility
Taylor: we need a standardized way to truncate a key. To be done at IETF side?
Cullen: we should decide in IETF that we truncate, and how.
Justin: we need this written down.
hta: any target at IETF we can ask to sort this?
Action on Taylor and Justin to sort things out with IETF.
<vivien> Action Taylor and Justin to sort crypto things out with IETF regarding RFC 7635.
hta: if the PR can be modified to work regardless of the solution to the truncating problem we can do that and merge.
hta: Taylor, do you think that would be possible?
Taylor: yes, and can put a sentence saying truncation is TBD and the rest should be mergable.
Taylor: DataChannel Id
... proposed solution: id returns null until negotiated.
Randell: sounds like a reasonable solution to me.
Bernard: +1
Cullen: +1
hta: ready to merge, will do tomorrow
Cullen: do we need anything added
to JSEP for datachannel Id? File a bug in that case.
... unverified media
Cullen: can happen in some
cases
... receiving media that is valid in some sense, but unclear
who sends it
... with this flag set, it allows this media to be played even
though the fingerprint has not been verified
... the application knows that the media is unverified
... an atacker would be would need to intercept the signaling
to launch an attack
... and can then do a lot of badder things
... also: I've added a timer, though its value is
doubtful
... we've talked about this before, and decided to write a PR
and look at it and that's where we are
Randell: seems reasonable, not sure we need a timer. Seems simpler to not having to worry about timers
Justin: this is a corner case since most of the time it won't work because you need candidates to puch holes
Randell & Cullen: in some (e.g. corporate) scenarios it works.
Justin: this will add complexity, and is it worth it?
Cullen: NAT pass through will work in many cases
Justin: still unsure (details about ICE and DTLS and stuff)
Cullen: pr_answer will contain
ICE stuff but not correct fingerprint
...correction: you will have a fingerprint of something but not
audio
Justin: you could make this work
with pr_answer with the right fingerprint
... we need a clearer (signaling) example
Cullen: I have presented this several times, and I don't know what would be clearer example
Justin: we need something where the PeerConnection is not killed because wrong fingerprint
Cullen: Ice happens to the gateway
(scribe not keeping up on all details)
Cullen: I can try to draw something more crisp
(lots of discussion on details)
Justin & Peter: would like to see more exact info on the offers and answers
Peter: volonteering to work with Cullen on this.
Cullen: media changes
... what happens? This PR documents what we agreed at
TPAC
... says what to do when you do need to scale the video
... we choose to crop off video over black bars
Randell: I'me fine with this
Bernard: OK to merge?
(no one objects - let's merge)
Taylor: reorder or remove codecs, but not modify
Bernard: Issue 1040
... what do you get on getCapabilities
... MIME type is not sufficient
... does not describe packetization mode
... minimum solution: add stuff according to slide 19
Bernard: but if we add
attributes, can they be set?
... or modified?
... two questions: do we add the attributes, and can they be
modified?
Harald: point of order, back to PR1025: do we accept this?
many: agree.
decided to merge 1025.
back to Issue 1040
(discussion on 1040)
Peter: we can separate two
things: the app can ask the browser what it is capable of, and
set what is used
... how much flexibility do we want to offer in 1.0?
Cullen: maybe it is usable with only the MIME type
Randell: good point, the
application can live with what the browser negotiated
... I doubt the application would fiddle
hta: the one use I have for the
packetization mode is if the application would want to remove
one
... only case it makes sense is if it talks to someone that
supports both but wants to steer which is used
Cullen: SDP munging
Randell: still struggling to find a use use case
Bernard: looking beyond
packetization mode, and look at stereo vs. mono
... do we need additional attributes?
Peter: I think so
Taylor: packetization mode is different
Jesup: for h264 it's a combination of profile and packetization mode
hta: don't forget assymetry allowed
Peter: can someone make it clear to me how bad it is for h264?
Randell: in real world situations I see in the order of single digits
hta: are we saying that capabilities should have one item for everyting the UA would use a new PT for?
Bernard: yes, essentially
Peter: should we have coded specific attributes?
hta: would like to have it completely symmetrical with the codec description
Peter: what is the full set we want?
bernard: proposing to add only clockRate and sdpFmtpLine at the moment
(People seem to like this)
bernard: second question: can we modify/change?
Peter: no, if you want to change it should be done elsewhere
Taylor: can we add number of channels?
bernard: would not add a new line, but we can add it
Taylor: Issue 1022
... can we simplify by adding a dictionary?
Peter: perhaps a list of attributes would be better?
bernard: if we're never going to modify sdpFmtpLines we do not gain much with a dictionary.
skipping to FooError
taylor: just proposing consitent terminology
Many: seems reasonable
Taylor: I can write a PR
Bernard: ptime
... found by Varun
... need to mess with SDP
... question is if Varun talks about ptime or maxptime
Peter: opus supports only certain ptimes
Randell: same in many other
codecs
... who or what actually cares?
... ptime is advisory anyway
(many) when you want longer frames to reduce overhead, and shorter with networked mikes in conf rooms
Peter: I want the app to be able
to pick from ptimes supported
... maybe out of scope for 1.0 and more an ortc thing
hta: sounds to me that this is not for 1.0
Cullen: it seems reasonable to
allow the application to hint what it would want
... same like turning off VAD
Randell: agree
hta: only thing small enough for 1.0 is a hint (single value).
Randell will draft a PR for us!
end of meeting
<vivien> (times up, not discussed today were Issue 526 and Issue 763)