WebRTC Virtual Interim

Agenda

Slides (PDF)

bernard: we're trying to tackle issue clusters in this meeting
... we're still interested in knowing features not on the radar for implementation

Issue 1361 and Issue 1383: offerToReceive

<dom> PR 1430 to address Issue 1383

bernard: PR1430 seems to resolve cullens concerns

bernard: We lost ekr, so we move on and come back to PR 1430 later

PR 1430 resolution: ekr will comment on the PR

Issue 1174: ssrc in RTCRtpEncodingParameters is inconsistent with ORTC

Issue 1174: The issue can make it hard to implement WebRTC on top of ORTC

Issue 1174: Resolution is for Taylor to do a PR to remove the odd behavior

Issue 1178: When IceTransport and DtlsTransport objects are created/changed (Taylor)

Issue 1178: When are *Transport objects created? Resolution: the group agrees with Taylor's suggestion

Taylor will create an PR

Issue 1406: When ICE restart results in connection to a new endpoint (fippo)

bernard: We need to continue to discuss Issue 1406 on github.

peter: Issue is if a new IceTransport is created or not

<mt_____> The problem is whether we make new IceTransport objects, or we mutate the same object somehow during an ICE restart

peter: The change should happen when the answer is applied

<mt_____> For DTLS, we agreed that we would create a new object when a new DTLS association is created (a=tls-id change, for instance)

Issue 1306: Obtaining a list of all DTLS and ICE transports (soareschen)

Agreement is to go with the proposed resolution

Issue 1365: No getStats() for DTLS and ICE transports (fippo)

<mt_____> do we have stats to put on these things?

Resolution is to *not* add getStats() to DTLS and ICE transport objects

Issue 1413: Should even/odd id validation be enforced in RTCDataChannel when negotiated is “true”? (soareschen)

<mt_____> I don't know about this, but can your role change?

<burn> +1 Randal. Id was only added to enable out of band negotiation

Resolution is to ignore the id value when in-band negotiation is used

Taylor will create a PR

Issue 1423: What if a datachannel “OPEN” message uses unknown priority?

Taylor proposes that an arbritary priority value should be mapped to the next valid value

bernard: Taylor will create the PR

Issue 1415: When is the dtmf attribute in RTCRtpSender set? (soareschen)

Resolution is that the dtmf attribute is always set for senders of type audio, but insertDTMF method can fail

Issue 1424: What happens if SRD has two tracks with the same ID?

RESOLUTION: MST ids are not unique

<jib> Btw, there's the note on remote id's not being unique: http://w3c.github.io/webrtc-pc/#id

Issue 1259: What keygenAlgorithm values are supported? (fluffy)

RESOLUTION: Is for Bernard to create a PR based on Tim's suggestion

<mt_____> A sequence of dictionaries that are "recommended" algorithms

Issue 1215: Rollback: Feature “at risk”? (Bernard)

Feature is implemented in firefox

<burn> Feature at risk just means you don't think you'll have at least two implementations

Resolution is that "Rollback" feature is *not* at risk

i.e. close issue 1215

Issue 763 / Issue 1323: Handling of encoding/decoding errors (youennf)

bernard: Currently we don't have error handlers on senders and receivers

RESOLUTION: It's a best effort system