WebRTC Working Group Virtual Interim

09 Nov 2016



See also: IRC log


Dominique_Hazael-Massieux, Bernard_Aboba, Cullen_Jennings, Mihaly_Mzszaros, StefanH, TaylorB, TimPanton, Dan_Burnett, Patrick_Rockhill, Harald_Alvestrand, Vivien_Lacourba, Maire_Reavy, Randell_Jesup, Roland_Hedberg, AlexG, Jan-Ivar, Justin_Uberti, Peter, Shijun_Sun
Harald, StefanH
DanB, StefanH



stefan: welcome. Editor resources are short through January, so everyone please submit PRs if possible in addition to issues.

WebRTC PC Pull Requests

aboba: (Reviewing slide 6 list of discussion topics)

Issue 871/PR 901: What happens when transceiver.stop is called (Bernard)

aboba: (explaining slide 8)
... (explaining slide 9)
... Note that PR 926 clarifies receiver behavior
... (explains slide 10) This is the proposed text, straight from JSEP.
... does this match everyone's understanding? (silence)
... any objections? (silence)
... so agreement.

Issue 908/Issue 917/PR 916/PR 918: “Stopped” (Bernard)

aboba: (slide 11 and 12) Given some of these confusing statements, we are trying to figure out what we want
... (slide 13) This is the recommendation in PRs 916/918. There is an issue with this. if direction is "inactive" sending might still be happening. Will get to this later.

hta: it should be that removing the track you don't send data anymore.

aboba: is it reversible?

hta: you can do addTrack where you've done removeTrack.

aboba: so it's not a stop

hta: but you could end up with "inactive"

aboba: so are these actions, or the immediate state? Taylor will discuss this more later.
... harald, please note these issues
... (slide 14) on replaceTrack, is this right?

hta: yes

fluffy: agree with last bullet on slide

aboba: (slide 15)
... This has similar issues. Again Taylor will address. Thoughts about whether insertDTMF should throw?

cullen: it needs to be possible to find out if it worked. That depends on media flow, not signaling flow

aboba: right. insert should not appear successful even if it failed.

stefanh: to stop sender/receiver now what do you do?

aboba: transceiver.stop is permanent. setdirection doesn't take effect immediately. for a sender, can setParameters with active to 'false'. Not permanent

Issue 714/PR 776: STUN/TURN OAuth Token Parameter (misi)

misi: (explains slide 16)
... (slide 17)
... Note that not all info is used. Only access_token, kid, and key need to be passed to ICE Agent.
... (slide 18) Shows what info is needed and where in the process.
... Key is that there is a gap between RFC 7635 and the WebRTC APIs.
... this should be addressed somewhere. Perhaps an Informational RFC?
... (slide 19)

justin: can you explain more about why HMAC alg needs to be known during auth phase?

cullen: we need more clarity. should oauth server be getting info about supported algs from TURN server.

misi: needs to get the longest key length supported.
... eg if HMAC-256 it gives that key

cullen: if TURN supported, eg. SHA-10000. Then auth server could generate material that is long enough. Still missing something. Doesn't matter what the client supports since it's only what the TURN server supports that matters.

misi: There are only two today.

cullen: this is about crypto agility for the future. how do we design this to add a new crypto alg later.

misi: (didnt' catch properly)

cullen: which should tell the auth server the size of the key? The web server or the TURN server? We thnk of the auth server being tied to the TURN server so it knows what to do

misi: but in auth server the key is not connected with the turn server. The key is not shared.

cullen: auth and turn servers need to share info already anyway. They must at least be configured together anyway.

hta: does the browser have to execute these MAC algs?

misi: yes, for every message. normally SHA-1

justin: the TURN server could do this. What we need is for the key to be long enoguh for the algs the browser supports. Today a 256 bit key would be plenty. So how do we get the key into the PeerConnection?
... this could be handled later between turn server and auth server.

misi: (slide 20)
... This is my proposal -- a new iceSupportedHMACAlgs attribute on PCs.
... the other part is on the next slide (21), extending RTCIceServer with new accessToken attribute.
... (slide 22) if we make RTCIceServer a sequence we can express preference ordering
... (slide 23) we would also need to adjust the error conditions
... Also, what happens if STUN/TURN is not configured through app and is discovered somehow. How would the PC signal what is has descovered?

hta: no preference for how we address this. We should probably accept this.

Justin: wolud rather see an object than a parameter for future flexibility

misi: such as what other info?
... I don't think there is anything else.

justin: there may be a new alg in the future that needs different info

misi: okay. but would need to change credential type as well

justin: yes. the type would tell you what kind of object to expect
... that way we don't pack too much into a top-level dictionary

cullen: yes. let's make sure we call the token the type it is as well rather than just "token"

justin: only a minor change to make this an object

hta: i think misi has a prior PR with the object syntax

misi: yes. i think it is not simple to implement, so I don't prefer that approach.

hta: if you put in a union in a dictionary it gets complicated to add more variants. adding more attributes migth be slightly better.

misi: i welcome help in this.

stefanh: do we want to be able to read out this info as well?

justin: no

cullen: we would need more explanation of how it works

hta: need to say that oauth will proived enough material for whatever alg we need

justin: today we can just return 256-bit key but in fututre need to understand how auth and turn servers will communicate.

cullen: agreed.

hta: who has action item?

<scribe> ACTION: misi to do this with Cullen's help [recorded in http://www.w3.org/2016/11/09-webrtc-minutes.html#action01]

misi: about the RFC proposal, should we do this as well? Wrtiting down how this works in WebRTC? The current RFC doesn't talk about the STUN client and auth client interactionts.

cullen: The webrtc doc should have informative text explaining this.
... we can discuss which doc is the right place.

justin: yes, let's write it now as a PR, then we can decide where it should go.

Issue 822/PR 850: Error Handling (Fluffy)

Cullen: will go through error handling slides 24 and on
... did a PR with Dan B's help
... slide 25
... Issue 1. SDP parsing error. Report line # where parsing broke.
... hta asked if the line # info was for humans or machines
... when that happens it is usaul to remove the line/attribute or whole m-line when you get this type of errors

hta: this explanation made a bit of sense. Reasonable to me, and sorts out what line number to report.

Cullen: slide 26
... Identity. Deals with what happens if the browser is not logged into the identity server
... the info needs to be passed back to the user, who needs to log in
... question is how to get back once the user has logged in
... question is if there can be more than one identity provider configured at the same time or not. Spec is vague on this topic.
... the way things are moving is that we would want to support multiple id providers.
... if we're to support that we need to pass info on what id provider to log on to - thus return the url in the error
... did explanation make sense?

hta, bernard, stefanh (more): we understood the explanation

hta: need to make sure this is consisten across browsers

cullen: should I open a separate issue on whether we allow more than one identity provider

tim panton: we need to separate that out, there is a lot of complexity associated to multiple id providers

cullen: my proposal to move forward: remove the url string from the PR, open a new Issue to sort if we should support several Id providers,

and await resolution of that issue.

Issue 859/PR 895: Need steps for rollback removing a transceiver (Taylor)

moving on to taylor, slide 27, Issue 859/PR 895

Taylor: about rollback. Mainly editorial.
... already defined in JSEP
... PR already merged in fact. Any objection? -- silence
... note this is the only way a transceiver is removed.

Issue 803/PR 913: Rules for negotiation-needed flag need to be updated for transceivers (Taylor)

Taylor: Issue803/PR913 neg needed flag update for transceivers
... cleaning up and rewriting in term of transceivers
... e.g. creating and Answer does not clear flag any more
... next slide 29
... Issue803/PR913
... see slide for details
... slide 30 - here it gets a little complicated
... direction does not fire negotiation needed event

DanB: Question: say next offer is sendrecv, which is in line with the tranceiver, but not with the answer that would trig a neg-needed event?
... oh, realising this is fine.
... but what happens if the offerer changes his mind?

hta: no need to wait for a neg needed to renegotiate

taylor: any more comments?

Issue 801/PR 920: Revise ICE Agent/User Agent interactions (Taylor)

taylor: Slide 31 Issue801/PR920: mostly editorial
... updating since we've introduced ICE-transport object
... and relying on state definitions
... slide 32 shows the PR example
... any comments? --silence

bernard: sounds good!
... on to issues

WebRTC PC Issues

Issue 902: Does setLocal/setRemoteDescription modify transceiver.direction? (Taylor)

taylor: issue902

taylor: should SL/SR change transceiver.direction?

taylor: that is slide 34
...continued on slide 35

taylor: consider adding "negotiatedDirection"

<burn> instead of direction and negotiatedDirection, consider pendingDirection and currentDirection

taylor: slide 36: my rec is that direction is not changed by SL/SR
... and perhaps add an extra attribute

<burn> +1 for two attributes in any case

bernard: is negotiated direction possible to detect by examining sender/receiver encoding.active?

taylor: no, I don't think so
... would we like an extra attribute?

Many: we would like the extra attribute

Justin: agree, and direction should be updated by addTrack

taylor: I will take the action to create a PR

Issue 927: What happens when setDirection is called? (Bernard)

bernard, slide 37 Issue 927:

taylor: strawman proposal described
... looks ok?

hta: clarify last step to talk about update neg needed flag

Issue 760/Issue 726: Adding ufrag to candidates, and ufrag+mid to end-of-candidates

taylor slide 38

Taylor: isue760&726
... ufrag+mid and end-of-candidates

Taylor: slide 39
... describing earlier attempts to address this
... that have been abandoned
... slide 40: proposal to use "ICE action" event instead

<burn> yes, this is nicer and more future-proof.

Taylor: slide 41 outlines rest of proposal
... slide 42 - how it would be used
... do we want to go ahead with this?

Jan-Ivar: why do we have a getCand method instead of an attribute?

taylor: don't remeber the details, the crux is to add a new event
... we can work details out

hta: I like this

petert: +1

jan-ivar: why do we need new methods?

timp: you might not be bundling, trying to catch up if we address this?

taylor: this proposal is addressing that

justin: (scribe missed)

danb: we discussed this long at TPAC, I like this proposal (and it is futureproof as well)

taylor: slide 43: question is if need to make cands not being a black box

hta: other problem with 757 is you get a problem with end-of-candidates
... impossible to tell which transport it was for
... legacy apps are waiting for a null candidate

jan-ivar: I push for PR757, it seems to solve everything except for advanced usages

(a lot of echo, hard to hear)

Issue 849: AllowUnverifiedMedia RTCConfiguration Property

Item postponed to a future meeting due to lack of time.

end of call.

thanks all for coming

Summary of Action Items

[NEW] ACTION: misi to do this with Cullen's help [recorded in http://www.w3.org/2016/11/09-webrtc-minutes.html#action01]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/11/10 15:10:20 $