See also: IRC log
<martin_> 936972 ?
<stefanh> last minutes: http://lists.w3.org/Archives/Public/public-webrtc/2013Sep/0018.html
<dom_> ICE Issues slides
<fluffy> on slide 3
<fluffy> EKR asked what the number for pool size should be, Just said app can put any number it wants in and this is the recommended aproach
<martin_> fluffy: many applications won't need this
<martin_> For the record, I'm good with the decision to do nothing special about rtcpmux, requiring it or not.
<martin_> So the conclusion was that this is OK.
<fluffy> dom, it's impossible to scribe on this side either - it's just back and forth too fast
<fluffy> Key point for minutes, as long as PC is alive, it will keep the candidates in the pool "warm" so they work when needed
<martin_> question here was whether the candidates will be kept warm, and Justin says yes, which means heartbeats
juberti: The idea is that this pool is pre-allocation, and everything else remains the same.
<martin_> Browsers will need to maintain a cap
<fluffy> Key point for minutes, might need some sort of cap
<hta> derf will try to scribe
juberti: We probably need to specify some kind of cap, but it's your TURN server and if you want to pound it...
martin_: If you think about the case where you have 100 lines and try to start cold, it's just not going to happen in any reasonable time.
juberti: We should just decide what's a reasonable maximum.
martin_: I think I'd be happy with the browsers doing that.
juberti: But we should provide some recommendations.
fluffy: If it's just something like 50 or 100...
adam: 100 ports on your NAT?
fluffy: Google maps does that all the time.
<jesup> cullen: yes
hta: I have seen the logs from bittorrent...
ekr: TCP has a different set of properties, because it does not need to allocate a port that's shared between every remote guy.
ekr: We specifically advise people to do that on their NATs, so it's not the same.
fluffy: We're just talking about the size of the pool.
martin_: Keeping in mind if the pool is 1, more ports will be allocated when SetLocalDescription is called, it just won't be very fast.
martin_: So why do you need more than 5?
juberti: I'm not sure it buys us anything to have the limit be less than could be allocated by SLD.
ekr: I agree those limits should be the same.
juberti: We should just set some number that's bigger than the largest reasonable use case.
<stefanh> it is difficult to break in from here, but it seems reasonable to have a limit
fluffy: I think it's more in the order of the magnitude of 50 than 5, and certainly not 5,000.
hta: I would suggest that juberti pick a number and we can debate on the list.
juberti: I would like Cullen...
fluffy: I'll take an action to pick a number.
adam: I presume that maximum is per page, per browser...?
ekr: It has to be per browser because of shared origins.
fluffy: There are certainly people who want to use the data channel with hundreds of origins.
juberti: We should take an action to figure out what the security implications are.
<silvia1> make sure to consider multiple cameras connecting to multiple peers and doing call forwarding in the browser, so there may be more than you think
ekr: Is it encouraged for an implementation to start gathering on addStream if they know the number of candidates?
martin_: Do that... the only thing we really need to say is what the measurable outcomes are, which is that candidates get given to you after SLD.
ekr: Uh, no...
martin_: Why?
ekr: Let juberti finish his presentation. It's at the end of this slide.
<ekr> derf: negative, at the end of this slide
juberti: The way the spec is currently written candidate gathering doesn't start until first SLD.
stefanh: How long will these candidates be alive if you create the PC and do nothing with it?
juberti: We'll keep them alive until that PC is garbage collected, because there's no way to know when you'll be done with them.
adam: I have this on my slides. Our proposals are remarkably similar.
ekr: I have two concerns vis a vis CreateOffer and CreateAnswer don't have candidates.
ekr: There are lots of cases where candidates are available---any renegotation---and it's silly to gather new candidates when they're available.
ekr: The other reason is that Firefox does it this way, and I don't see any reason to do it another way.
juberti: If I ask for 10 ports, how do you know there's 10 sitting aroudn?
ekr: We have a list of what's sitting around.
adam: If you ask for 10 and there's 4 sitting around, we return 4 and trickle the rest.
juberti: I have no problem with that. An application MAY return candidates in the initial offer, it also may return zero and trickle them all.
martin_: I have some issue with gathering candidates after SetLocal.
<fluffy> So key thing for minutes, on createOffer, if you have candidates in pool, you use them and return in createOffer but whatever ones you do not have you trickle later
martin_: If you ask for 4 and the browser has 10, is there any reason it can't return more if you really need them?
juberti: I don't think it's a good idea to add TURN candidates the application didn't ask for.
adam: I don't think this is an interoperability issue.
juberti: When you have a very, very good indication that you're going to need this right away, like addStream... but if you did it speculatively then a TURN server load might increase unexpectedly.
fluffy: Given our default posture that you sort of need 4 ports or 5 ports, I wouldn't want to limit the browser to not go ahead and gather those...
juberti: I think our default is 0.
juberti: A certain large social network told us that TURN usage is their largest bottleneck.
juberti: It's not CPU, it's bandwidth.
adam: Holding a port open is not going to consume bandwidth.
jesup: I think there is an advantage to starting to spin those up.
juberti: We can leave it up to browser discretion, but if we provide a knob, we should rely on that instead of trying to make decisions for the application.
hta: That raises another question with a constraint... do you set an upper limit, a lower limit, or both?
juberti: I think you should not be getting more than this. If you set a local description that requires more, then you gather more.
<stefanh> Keeping a port open will not consume BW, but we have the batery issue: on a mobile device it would consume battery
hta: If the browser would normally prefetch 5 just in case, and you set the constraint to 3, should it gather 3 or 5?
adam: I think it should be 3.
adam: Because it indicates the application knows what is about to happen.
juberti: The code works the same way regardless of whether this is implemented or not implemented, it's just faster.
juberti: But it prevents unnecessary TURN server load.
juberti: If you really care about things like this, you'd probably think about having a way to say RTCP-mux only, so you only have to gather 1 candidate.
hta: The way you would specify it would be to give a promise that if you don't get RTCP-mux back, you'll close the connection.
juberti: I don't understand how that follows.
hta: If I say RTCP-mux required and I'm talking to someone who doesn't understand it...
fluffy: Then you just don't sent RTCP.
martin_: As Hadriel has pointed out, you can get this stuff to work.
fluffy: I know, I know...
fluffy: I do think the RTCP-mux issue is completely independent of this one.
fluffy: We should have an argument about it someday, but not now.
<ekr> Travis_MSFT: we're messing with connectivity.
<ekr> Please raise that again in a minute
juberti: Slide 4, candidate pool continued...
juberti: We had a lively debate about what exactly the constraint should do.
juberti: The general things I heard were that this should be, at least for non-host candidates, the maximum number of things to pre-gather.
juberti: But if CreateOffer wanted to return these candidates plus other host candidates, that would be okay.
adam: But if the browser saw the need for other candidates because of addStream calls, etc., it could return more.
juberti: If addStream is called we could add another 1 or 2 because of RTCP-mux then the browser could return more candidates...
adam: If they're available when CreateOffer is called.
martin_: Unless BUNDLE-only is set.
adam: Yeah, then you don't need to add more, but that's simple to do.
burn: We're just talking about pre-gathering, not the final candidates to gather, right?
juberti: I think the boost is fairly nominal, but there's no reason not to do it.
martin_: The other one to think of is OfferToReceiveVideo/OfferToReceiveAudio...
adam: You're reading my slides now, aren't you.
<jesup> +1 to the idea (fluffy also +1'd)
martin_: Pretend that someone had added those candidates as if they'd added a stream.
fluffy: Can we table that?
<ekr> chairs: we need a clearer description of how to offer to receive >1 audio/video
adam: The OfferToReceive?
fluffy: How we extend the constraint beyond being true/false.
<martin_> Adam suggests that OfferToReceive{Audio|Video} be made an integer
adam: Integer.
fluffy: Thumbs up.
martin_: Does anyone have a problem with an integer?
ekr: I'm not sure because of receive-only vs. receive.
hta: Okay, let's add that later in the agenda so we have a little time to think about it.
juberti: On to slide 5...
juberti: When does ICE end up in the completed state?
<rbarnes> the integer represent the number of ...? m= lines?
adambe: I have a question on this new constraint.
juberti: Previously there's no way to change this after you create a PC, and now you can.
juberti: What happens if you change it from 4 to 8, etc., but I think that's probably pretty predicatable.
martin_: What happens if you set it to 8, call CreateOffer so you're using all of the 8, and now you set it to 10.
martin_: Are you asking for 2 more?
juberti: adambe was saying everyhing has this constrainable interface where all of this can be changed on the fly.
adam: Really?
adambe: Did you consider putting this into the options dictionary where we have the ICE URLs which are only set once? Then it would only be set once.
juberti: I understand where you're going with that.
ekr: The notion that you can just change anything that was passed in as a constraint at any time is going to cause huge problems with things like the TURN servers. "Oh, the TURN password just changed..."
juberti: That's kind of what adambe was getting at.
ekr: Sold.
martin_: Do we have any objections to that course of action.
adam: I didn't understand it.
<fluffy> Proposed Action , adam to move the pool size from the constrains but instead put it into the turn server configuration
juberti: There's two parameters to creating the PC, one of which just holds the configuration options for the TURN servers, and we can just stick it in there.
adam: +1
juberti: I assume this will just be a nullable property.
martin_: It's a dictionary, they're always nullable.
fluffy: I'm proposing we don't even need a proposal. If we're all agreed upon here, adambe should do it.
<martin_> BTW, adambe: you need to remove all those '?' characters from the dictionaries.
<hta> ACTION: adam to Move ICE candidate count from constraint to RTCConfiguratoin. [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action01]
<trackbot> Created ACTION-87 - Move ice candidate count from constraint to rtcconfiguratoin. [on Adam Bergkvist - due 2013-11-18].
juberti: Why did we ever think it was a good idea as a constraint?
<martin_> ACTION: adambe to Remove '?' characters from all dictionaries. [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action02]
<trackbot> Created ACTION-88 - Remove '?' characters from all dictionaries. [on Adam Bergkvist - due 2013-11-18].
JimBarnett: I just want to point out that the language of the constrainable interface allows for constraints that can't be changed.
juberti: That's good, because that avoids the issues ekr was concerned about.
hta: If we want constraints to be unchangeable or changeable, we'd better specify that. That's another issue.
JimBarnett: Yes, that would be part of the definition of the property. That cannot be changed.
JimBarnett: There might be many reasons it might not be able to find a value, including that it's already been set and can't be changed.
burn: I don't understand what you mean by a constraint that can't be changed, but the other part of constraints is that you may not get what you ask for.
juberti: I didn't get a sense that the issue of these constraints that can't be changed was resolved.
hta: But it's not an ICE issue, so we should move on.
juberti: When is ICE done?
juberti: <reads the slide>
juberti: When can the controlled side know, if there's no updated offer, that the controlling side is done?
martin_: The easy solution is that when you get the TLS finish message, you know where you're going.
juberti: No, because as soon as you get TURN going you'll be trying to get DTLS up as fast as possible, but you might be trying to get host candidates or STUN candidates up later.
martin_: Or you might change your mind.
juberti: That's what I want to get to in the next slide. Why do we care?
juberti: There's a couple of answer.
juberti: On the controlling side, it may want to send the updated offer with the real candidates.
juberti: The controlled side doesn't need that, it just needs to know when to release candidates that aren't going to be used.
juberti: And it can just wait.
martin_: Consent.
juberti: Consent is not going to be on every single candidate pair.
martin_: You just stop doing the refresh stuff and consent will expire after 30 seconds of not getting packets from the other side.
juberti: It's up to the implementation to decide which connection to use, and it should already do interface prioritization.
juberti: The interesting case is the reverse, where you'd have to use something like RTT...
martin_: Or PCP, but that's an IETF issue.
juberti: Or something that has a low RTT until you start using it and then it has a high RTT.
fluffy: See connection to China right now.
juberti: We're familiar with that.
fluffy: There's no great win here.
juberti: This is just an implementation issue.
fluffy: Every implementation I've seen, at some level or other, at the bottom there's a timeout.
adam: In most browser-to-browser cases it's the same application on both sides, so if it really cares, it sends a message that says it's done.
<Zakim> AndyF, you wanted to say what happens when you have multiple local interfaces
<rbarnes> the IETF has a whole working group on Multiple Interfaces <http://tools.ietf.org/wg/mif/>
hta: That's an ICE question.
juberti: I think there's two different things being discussed there.
juberti: One is the size of the candidate pool, and one is the number interfaces.
<martin_> And ICE already deals with local interface prioritization effectively
juberti: And there isn't really any limit to the number of interfaces.
juberti: This is the number of candidate sets to pre-gather, but it will pre-gather for every single interface that you have.
martin_: The point that I was going to make was that the controlling side can simply stop sending on candidate pairs that it doesn't want to keep warm, which would mean that consent would expire on the controlled side over time.
martin_: 30 seconds... allowing it to clean up most of them, there's some ambiguity there...
martin_: But if the controlled side is just keeping candidates that have consent warm, then at some point it will clean them up.
juberti: That's like what I was thinking, but I'm not sure that consent is the right thing, because you're not going to be getting consent on every pair.
juberti: I'm just thinking maybe we're using the word consent in different ways.
juberti: As the process moves forwards you're going to be sending connectivity checks, and at some point stop doing them.
juberti: But I don't think that's the same thing as consent.
martin_: We need to talk about consent.
hta: Who's got the token on consent because I think it's an IETF issue.
martin_: It is an IETF issue. I think there's enough information on the controlled side for it to release the pairs.
juberti: If you ping on something other than the active one, does that establish consent?
fluffy: On that one.
juberti: So it's consent per 5-tuple?
hta: The consent for STUN draft has 4 editors from Cisco. Can you make sure they're told they'd better specify on what pairs consent should be sent?
fluffy: I think there's a much better solution to this problem of four editors from Cisco.
martin_: I've been talking to Dan and this document is going to get a rewrite.
juberti: I volunteer to help with that document.
martin_: I've already made that offer as well.
fluffy: Sync up with me and I will facilitate a change of editors.
ekr: It's using a binary request, still?
juberti: Yes.
ekr: From the recipient side there's no way to distinguish between a continued one and a regular one.
ekr: Any candidate pair that you have not received any STUN check on for some period of time, you assume it will be dead.
martin_: The controlling side will stop responding, and at that point it no longer has consent.
martin_: If you want to open that again you need a new ufrag and password.
fluffy: That time is 30 seconds?
juberti: That's the exact value we use.
ekr: <detailed discussion I missed>
martin_: Let's take this offline.
hta: I definitely think this is an IETF issue.
fluffy: Who are the people we think know the answer to that issue?
<hta> martin, ekr, justin, dan will sort it out.
martin_: Myself and juberti.
ekr: The same people who failed to address this last time.
ekr: This time we'll assign martin_ to do it.
juberti: The controlling side there's no question.
<hta> ACTION: martin to Drive IETF discussion to decide where consent will be sent. [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action04]
<trackbot> Created ACTION-89 - Drive ietf discussion to decide where consent will be sent. [on Martin Thomson - due 2013-11-18].
juberti: On the controlled side, if there's an updated offer, it will move from connected to completed, but that's not that interesting. The application could also send a message, but that wouldn't move the state machine forward, or we could do this implicitly, using these timeouts.
ekr: That sounds provisionally okay but I'd like to hear the outcome of martin_'s proposal.
juberti: Moving on to the next slide.
<robin> I would like to be involved in the ICE discussion
juberti: I think the next slide is going to be uncontroversial... I've said that many times before.
juberti: ICE restart.
juberti: ICE restart is in the current editors' draft.
juberti: The basic mechanism is that if you specify the IceRestart constraint to CreateOffer, the returned description has new ICE credentials.
juberti: Similarly if you receive a description with new credentials, this forces a restart.
juberti: The actual restart is triggered by setLocalDescription.
ekr: If I call createOffer _twice_ with the same constraint inbetween, do I get the same ufrag and password or a new one?
juberti: createOffer isn't supposed to change anything.
ekr: But I don't want to keep a stack of these.
juberti: I'm not sure I'd be happy with saying there'd only be one outstanding offer ever.
ekr: I'd agree with that generally, but this is a special case, because I need to validate that these values are valid.
ekr: Generally, if I call createOffer repeatedly with no other actions inbetween, I'd expect to get the same answer back.
ekr: But if one possibility is to create a new set of values every time, then I'd have to look backwards to see if they're valid.
juberti: As long as they're different from the current state, then it's fine.
juberti: We start with ufrag 0...
fluffy: Just type it into the minutes because everyone's going to agree with you.
<ekr> CreateOffer() --> A
adam: If I've given you different ufrags each time, I want you to forget about all the ones I've given you and only use the most recent ones.
juberti: In this particular case I think that'd probably be fine.
juberti: Generally it seems kind of ugly.
ekr: I'm not making a general statement.
juberti: I'm thinking we could generate some kind of HMAC...
ekr: We could do that too, and allow any previous ones to be acceptable...
<ekr> resolved: setLocalDescription() only succeed with the result of the most recent CreateOffer()
juberti: And if someday it turns out there's a scenario where this matters, then it's trivially fixable.
<ekr> implementatons may generate the same ufrag/password repeatedly with multiple CreateOffers as long as there is no SetLocalDescription() has been called repeatedly
stefanh: How could you know if SetLocal comes from that CreateOffer or it's something you just generated.
ekr: Because we memorize it.
ekr: It's an ICE security requirement to only accept ufrags and passwords that were generated interally.
stefanh: But you could also change lots of other stuff in the SDP.
ekr: Lots of stuff, but not this.
martin_: Passwords, maybe, but ufrags...
martin_: Ufrags, you can't change them, but passwords, maybe...
fluffy: What you're really getting at here is that we should use DTLS and not ICE for consent.
martin_: You're about 3 seconds too slow, I'm about to hit send on the e-mail.
ekr: Heartbeat?
martin_: Yeah.
<ekr> ACTION: erescorl to sit down with Justin and Martin and work through whether ICE ufrag/passwords need to be internally generated in the face of DTLS [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action05]
<trackbot> Created ACTION-90 - Sit down with justin and martin and work through whether ice ufrag/passwords need to be internally generated in the face of dtls [on Eric Rescorla - due 2013-11-18].
adam: JSEP currently has this as a big open issue.
juberti: So, we just talked through the behavior if you call createOffer with ICE restart multiple times, sounds like we got that mostly figured out.
juberti: The other thing is that ICE restart restarts for all m-lines.
juberti: There's no way to restart for all m-sections, and not just one m-section, but since ICE restart is harmless to existing media streams, I don't see this as a problem.
ekr: If it fails, what are the O/A implications?
juberti: The ICE restart? I'm going to talk about that.
<fluffy> we are now on slide "ICE Restart Cutover"
juberti: The general way ICE restart works is that it's make-before-break, which means you keep your current candidate pair hot until you have a new candidate pair ready to move over.
ekr: What about partial success? One m-line's on the new candidates, and one m-lines on the old candidates.
juberti: That's an interesting point, I was sort of assuming it would happen on a per-component level, that the ICE restart wouldn't complete until it could cut them alll over...
martin_: The reporting of that is interesting...
juberti: Yeah, I talk about that here.
fluffy: Walk me though the use case were this happens.
juberti: The main use case is you're in a call and some NAT falls over and some packet timer expires at 5 seconds.
juberti: Then you make a new createOffer and stuff it into setLocal and are now gather new candidates.
juberti: The remote side calls createAnswer which starts gathering new candidates in setLocal, and as soon as that completes we can start sending media on the new set.
martin_: And this might only apply to some paths.
fluffy: My general strategy on this is you have a valid O/A pair and you send a new offer, then you have to be willing to keep receiving on the old ones, and this is very consistent with that.
jesup: You might also invoke this if the current path degrades to find a better path.
juberti: Yup, this could happen in IP handover situations to, you walk out the front door and now you're on 3G.
ekr: This sounds generally sound to me, but we need to walk through the various edge cases.
ekr: The videos on candidate pairs from the first handshake and the audio's on pairs from the second handshake and vice vesa.
ekr: What happens if things fail?
ekr: In the simple case the whole thing fails. What happens if one component fails and one does not, how do I back out?
hta: This sounds like something that's really IETF protocol, and I think we're more or less ready for a coffee break.
juberti: Let me go over the last bullet.
juberti: If you do the ICE restart and it doesn't get you back to the completed state, it's really up to the app.
juberti: Since it's make-before-break you might still be partying on.
juberti: So it's really up to the app, and if you don't get to the completed state, it might decide I don't know what to do here, I'm just going to end the call, but that generally puts it in the app's hand.
juberti: Are there any salient points we want to capture for a sidebar?
hta: The important thing for the W3C state machine is that gathering-state changes back to gathering, connected-state goes from completed back to connected.
ekr: How does the controlled side know that he's completed?
martin_: Because he's going to receive an updated offer...
ekr: That's a reach.
juberti: The point is that you are the controlled side, you didn't get an updated offer originally, now you get an ICE restart, the only way you know is that the gathering state went back to gathering.
ekr: If you end up with default candidates you never get an updated offer.
juberti: Even if the candidates would match the defaults candidates, there's still a recommendation you send this offer for the benefit of middle boxes.
juberti: Though if someone told me there was something in the ICE spec that wasn't actually used for anything...
juberti: I think the main thing is that if the gathering state changes that means you must be doing an ICE restart.
<rbarnes> hi, i will be your scribe for this session
adam: first part of slides are OBE, due to discussion of justin's material
<adam> http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf
slide: Other Resource Reservation (Codecs, Hardware)
<fluffy> and it is slide #8
adam: input resources, trying to cover all the resources you might need here
... this get freed on the indicated conditions, not when the PC ends
ekr: well, if the PC is GCed
... also if the MediaStreamTrack gets GCed
fluffy: say you have a track assigned to a global variable, not to any PC
... so you're going to attach the video codec to the track, not to the PC
adam: talking about input resources (camera), not codecs
ekr: as long as any handle is available, and stop() has not been called, its' reserved
adam: exactly
adam: start the resource reservation when you addStream...
juberti: don't know at that point what resolutions, etc. you need
hta: may also need to differentiate encode/decode
ekr: suppose i have a hardware limit, when should the failure appear
juberti: createOffer
ekr: then it will not really be a recoverable error. if it occurs at addStream, then greater chance of being able to recover
jesup: there are always be constraints on capability
juberti: you could easily have an encoder that could do 2 streams, but only at certain resolutions
fluffy: suspect we're going to have a set of objects that map this stuff together
adam: on setRemoteDescription, they're telling us that we're going to receive a certain stuff...
ekr: think the implication is that creatOffer/createAnswer is where the reservation happens
adam: (summarizing) reservation lasts to the end of the callback closure
<ekr> here is the relevant text
<ekr> "Session descriptions generated by createAnswer must be immediately usable by setLocalDescription without generating an error if setLocalDescription is called from the successCallback function. Like createOffer, the returned description should reflect the current state of the system. The session descriptions must remain usable by setLocalDescription without causing an error until at least the end of the successCallback function. Calling this method is needed to g[CUT]
<ekr> ICE user name fragment and password."
... conclusion whether we're doing something with addStream?
burn: why did we get to that conclusion?
ekr: there are cases where createOffer will fail that cannot be detected at addStream
<fluffy> note that we might not want reservation to last beyond the minimal time otherwise JS will work on software stuff were the reservation lasts longer and same JS program will fail on hardware based devices that do not extent the life of the reservation beyond the minimal time
... therefore we need to handle errors at createOffer/createAnswer-time, not useful to also have it at addStream time
<ekr> fluffy: would propose that we actually forbid the reservation to last beyon g the minimal time
<ekr> because it encourages safe programming idioms
burn: conceptually, addStream just sets an internal variable, not until createOffer/Answer or setLocal/Remote that something interesting happens
juberti: adam mentioned there might be some other interesting uses, but those don't affect the application
adam: these resources are freed at the end of the closure
ekr: how do we get to closure on this question?
juberti: write up the case you just described, and look at where the errors get handled
fluffy: suggest adding this to the agenda for later
adam: strike "RemoveStream" from "freed by" bullet
<ekr> The proposal is that Stefan add an agenda item to figure out what kind of error handling we need to detect/react to failure to CreateOffer due to insufficient resources
<ekr> … said agenda item should be in the error handling part of the agenda
<ekr> ACTION: stefan to add to agenda: Way to have the error handling for createOffer be able to report what had happened when all the resources could not be reserved for codecs [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action06]
<trackbot> Created ACTION-91 - Add to agenda: way to have the error handling for createoffer be able to report what had happened when all the resources could not be reserved for codecs [on Stefan Håkansson - due 2013-11-18].
juberti: createOffer/setRemote is doing the reservation
... but if a stream goes away, you might need to create a new offer
adam: planning to propose adding a "negotiation needed"
juberti: not sure getting the codec back 50ms earlier is a big advantage
adam: you're saying the stop() doesn't really help, since your'e just going to re-negotiate
... and possible h/w issues are not in scope
... stop triggers negotiationNeeded, and the negotiation triggers releases / frees
juberti: reservations happen on create*, frees on set*Description
ekr: is this sufficiently clear in the spec?
adam: last slide
slide: Media Transmission and Reception
juberti: this is covered in JSEP
fluffy: +1
slide: Local Session State Rollback
adam: AFAICT, this is the only case where rollback is useful
... current version of JSEP says we do this with rollback, but doesn't say anything about the body
juberti: the proposal on this slide was what i had in mind
<rbarnes> "Proposal: Use type of "rollback", sdp string ignored"
fluffy: do you have to pass the previous sdp
adam: no
fluffy: as long as you can only roll back once
ekr: can i roll back from stable?
adam: no, only from partial state
fluffy: and only roll back to the previous stable state
adambe: aren't we kind of abusing setLocalDescription by doing this? even in this group there's confusion about what to do here?
adam: could add a rollback() method...
juberti: but rollback has to happen for both local and remote
ekr: i argued for this design because the other side can force you into rollback
juberti: i came to the same conclusion, that this was better than having separate rollback methods
jesup: the primary argument is what eke said, since you could send them the string and they would just do it
andybe: how about a more generalized "reset to prior state" mechanism
hta: no
... the more generalized the mechanism, the harder to tell what will happen
juberti: there's less validation that needs to occur
... harder to figure that out more generally
adambe: only use valid states
... if you lose a state, how do you know the past state is valid
fluffy: you have to be ready to receive both the last and the new valid
adam: so the rollback just deletes the future state
jesup: making an API that implies that you can roll back to anywhere will promise something you can't do
fluffy: and you'll never map it to SIP
adam: if you're in stable, and someone tries to roll back, it will fail
fluffy: i think a better way to think about is to discard any changes since previous stable
rbarnes: abort the negotiation
juberti: adam's proposal is the cleanest option
... being able to roll back a remote offer is a good idea
jesup: call setRemoteDescription, but you're unhappy with the new streams
martin_: setLocal is the tranition point
burn: one of the reasons this is good is that a peer can send you this supposed SDP blob
... are there cases where createOffer or createAnswer would create rollback?
fluffy: could arise with a gateway, e.g, if you got a 400/500-class error on the SIP side, map it to rollback on this side
adam: that's not the question
ekr: suggested case: what happens if i do setRemote, and i can't process all the stuff you want to send
adam: there's an error callback for that
<fluffy> did you guys get an answer to the question you asked ?
burn: fine without it being that way
jesup: we talked about rollback after a setRemote, because you have to make the other side do it
adam: that's an application-level thing
... ignore next slide
ekr: what happens now if you send me a description i cannot possibly process
adam: you get an error callback
juberti: yes
ekr: so it's not just malformed that triggers the error, can also be "i can't process that"
ekr: probably need a class of error for "i can't process that"
ekr: but unrecognized codecs might be different from codecs you know, but can't process
jesup: but in that case, should it fail, or succeed partially
adam: in the latter case, the app could decide to roll back
stefan: could succeed, and app could use stats to detect that no packets are flowing
... added a topic for error handling discussion
juberti: added a state here, "might be less than you wanted"
<fluffy> Moving on to slide "Requesting Partial Offers" - slide # 14
<adambe> spec says: The setLocalDescription() method instructs the RTCPeerConnection to apply the supplied RTCSessionDescription as the local description."
<adambe> that's not true anymore then
slide: requesting partial offers
proposal: add "partial:true" constraint to createOffer
... if changes are more than can be done with partial, then send back a full offer
fluffy: is there a way in the initial O/A for both sides to indicate support for partial O/A?
burn: this is less about making a partial offer than accepting a partial offer
fluffy: find it scary not to provide some standardized way to negotiate partial O/A
adam: thought this was an application layer thing
fluffy: do you have a better solution? this is a substantial mod to O/A, we should negotiate it in O/A
hta: negotiations to O/A should be negotiated above O/A
adam: that's how we do bundle
... so this is an IETF level suggestion, the POF/PAN draft needs to do this
... then if it hasn't been negotiated, a request with "partial: true" will just never produce partial
hta: should be clear that the constraint can be ignored by the browser
jesup: if you take this and use it with current browsers, they'll ignore it anyway
burn: why does the application need to ask for the partial
... if they negotiate needing to send partials, great. but then why does the app need to request it at any point?
adam: it's necessary if you negotiate it in the application layer
jesup: suggest by default negotiated in the SDP, let partial==true be the default, partial==false if you overwrite it
... if the application wants the full SDP, it can get it by forcing partial==false
juberti: having the output of createOffer be dependent on previous SDP makes me sad from an API perspective
adam: how would you discover this?
juberti: some property on the PC
jesup: why does the app need to care
juberti: might not be doing full SDP, might be munging diffs in JS
burn: what are the use cases, why does the app need to have partial or non-partial
adambe: do you have to handle glare in both cases?
adam: yes
juberti: concerned that if the app things it's going to get a partial and doesn't, that's bad
... likewise in the reverse
adam: you have apps right now that are doing SDP scraping, so if they get something not-SDP, they'll break
... they need to have a way to say "i'm willing to deal with partials"
jesup: that's only based on a need for backward compatibility with apps that scrape SDP
... but it does impose that request forevermore
adam: perhaps we could pass this into the PC constructor
juberti: if you expect a partial, you can get a full, but not vice versa
jesup: when i see something that will eventually be cruft, i want to get rid of them
juberti: this is way down on the list of potential cruft
adam: propose to put this in the PC constructor, not have something per createOffer
jesup: that would only impact things that need to change per message
burn: you're *never* guaranteed to get a partial anyway, so you're just saying "i know how to deal with partial"
jesup: if you want to retain the capability, you can either leave it on createOffer, or leave it on PC and allow it to be overridden
adam: sort of back to what's on the slide
juberti: constructor constraint might be workable if we have a way to get the full offer
... case is you get an offerless SDP...
adam: (summarizing) if you really want a full one of these, you can do [that], but it gives you a list of everything you *could* do
juberti: kind of feel like this is the cleanest way to go
ekr: what is the impact of POF/PAN on local/remoteDescription
adam: you get the full thing
stefan: what's the resolution?
adam: agreement that we will have a signal for this, put it in the POF/PAN draft
<hta> ACTION: adambe to put initial negotiation of pof/pan support into the pof/pan draft [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action07]
<trackbot> Created ACTION-92 - Put initial negotiation of pof/pan support into the pof/pan draft [on Adam Bergkvist - due 2013-11-18].
juberti: is this global per PC, or local per message, or both?
... if we're going to have the fullFull constraint, would prefer to have it at the same level
... how do you know you can use this with the remote peer?
adam: if that attribute is absent, and someone asks for partial, then the browser just won't generate it
juberti: that's fine
<rbarnes> [[ unanimous consent ]]
<martin_> consent that it's on the createOffer
slide: Processing partial offers
martin_: and this will blow up if it gets something full?
... "this is not an answer for the offer i sent"
juberti: what about the case where there's enough changes that you need a full offer?
adam: then you trigger re-negotiation
martin_: not sure when you'll see a partial exchange trigger some consequences
<ekr> scribenick: ekr
<fluffy> http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf
<fluffy> slide 17
<fluffy> slide with title "Stream Pause/Unpause/Rejection/
<fluffy> Removal"
abr: we used to think we could defer, unpause, etc.
… implementors want it
… can just be clearer about API
abr: slide 18
… to pause, set enabled=false, this paused media and starts renegotaition
juberti: we have three states, ended, paused, muted, but just two api points
agreement that mute just turns off mic
discussion of events. is muted a response to an external button?
hta: muted is outside application control and enabled is inside application control
jesup: where should this be tied to?
fluffy: what about a track going to two places?
general consensus we need more knobs
jesup lists some
fluffy draws diagram
1. Camera with hardware control to go black
2. Application control to do (black, silence, frozen frame)
3. Stop sending packets
[stopping transcription]
Topic 1: hw mute button
This is read-only
Topic 2: freeze/black from the application. consensus that black/silence was fine
dom: apparently not
mt: what about removing the stream?
fluffy: permanent vs. temporary stream removal
various comments about how much you need to send dummy data even when not sending content in order to keep bandwidth estimation working
abr: people with gateways want to tell the gatewy stream is going inactive
… they want signaling to indicate it
ekr got lost
and cullen has agreed to write down his view
<fluffy> RTP RTCP m-line
<fluffy> Send Black Black yes yes
<fluffy> no RTP no yes yes
<fluffy> end no yes zero
<fluffy> take two
<fluffy> RTP RTCP m-line
<fluffy> Send Black Black yes yes
<fluffy> no RTP no yes yes
<fluffy> end no no zero
<fluffy> Need to turn the audio on and off immediately, and no RTP can not happen super quick
proposal. enabled --> send black but still send RTP
"The muted/unmuted state of a track reflects if the source provides any media at this moment. The enabled/disabled state is under application control and determines if the track outputs media (to its consumers). Hence, media from the source only flows when a MediaStreamTrack object is both unmuted and enabled."
<fluffy> slides are http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf
<fluffy> slide number 18
<scribe> <new thing> --> stop sending RTP
<scribe> <new thing> also causes onnegotiationneeded on the sender side
on the receiver side, .enabled = false causes the output to be black
if the other side stops sending RTP, the track gets mute set
juberti: the names are messed up but not clear we can fix it
<martin_> I know for sure that removing a stream or ending it have the same net effect
<martin_> conclusion there was that removing or ending the track will cause the msid to disappear from signaling
<fluffy> http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf slide 20
<martin_> One way of dealing with all these cases is to look at transmitting the set of tracks that are attached to all streams on a RTCPeerConnection
<martin_> If you then treat the stream association for each track as a property of each track, easy.
<fluffy> http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf slide 23
<fluffy> we need action to do what was on the above slide 23 - it seems people agree with thqt
<scribe> ACTION: fluffy to make addIceCandidate queued [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action08]
<trackbot> Created ACTION-93 - Make addicecandidate queued [on Cullen Jennings - due 2013-11-18].
<hta> ACTION: justin to prepare slides for Tuesday on Stop() versus Removestream() [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action09]
<trackbot> Created ACTION-94 - Prepare slides for tuesday on stop() versus removestream() [on Justin Uberti - due 2013-11-18].
<fluffy> http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0005.html
<dom> ScribeNick: adambe
burn: you might want to look at the webrtc spec as we walk through the email
<rbarnes> drumbeat.stop()
<dom> WebRTC editors draft
<dom> Aug 30 draft
burn: we're ready here
... I've gone throgh the document and noted where we have
"throw a TBD error" or where an error is reported
... on topic RTCPeerConnection, section 4.3.1
... action to remove bullet 5
... that is bullet 5 in the third algorithm
... additional actions: remove bullet 4 in the some algorithm
as well as "issue 1"
... next topic: addIceCandidate(), section 4.3.2.3
... proposed solution: the addIceCandidate() method should
throw "InvalidCandidate" and "InvalidMediaIndex" depending on
the error
... "InvalidMediaIndex" should be "InvalidMidIndex"
... the method should fire the error callback instead of
throwing
... the line about "SyntaxError" should also be removed
... the "SyntaxError" should be moved the the RTCIceCandidate()
constructor
... next topic: addStream(), section 4.3.2.3
... I think the exception is fine
... the WebRTC document needs to be updated to use the new
Constrainable concepts
... we need to go through the "argument constraints" in the
webrtc spec and see if they really are constraints or if they
could be replaced with plain settings
<dom> ACTION: adambe to Go through all usage of constraints in WebRTC and figure out how to deal with them (or find someone else to do that) [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action11]
<trackbot> Created ACTION-95 - go through all usage of constraints in webrtc and figure out how to deal with them (or find someone else to do that) [on Adam Bergkvist - due 2013-11-18].
burn: next topic: close(),
section 4.3.2.3
... conclusion, remove the throw
... on topic addStream(), section 4.3.2.3, remove issue 3
<scribe> ... new topic: createAnswer(), section 4.3.2.3
burn: let's skip the
issues with Constrainable
... conclusion: if the SDP generation process fails, the error
callback should be called with "GenericFailure"
... next topic: createOffer(), section 4.3.2.3
... same conclusion as createAnswer()
... next topic: removeStream(), section 4.3.2.3
<hta> Suggestion for generic failure: Let's use "AbortError", since it's already defined in DOM, and has a meaning of "I stopped trying to do this because it didn't work".
burn: conclusion: keep the exception
burn: next topic:
setLocalDescription() , section 4.3.2.3
... conclusion: keep the exception
<juberti> For IceRestart:
<juberti> When ICE restarts, the gathering state will be changed back to "gathering", if it was not already gathering. If the IceConnectionState was "completed", it will be changed back to "connected".
burn: conclusion (cont.): juberti
will send text on the ice part (paragraph 2)
... conclusion (cont.): lets keep
InvalidSessionDescriptionError
... conclusion (paragraph 4): needs more discussion
<ekr> ACTION: fluffy to do s/roll back/rollback/g [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action12]
<trackbot> Created ACTION-96 - Do s/roll back/rollback/g [on Cullen Jennings - due 2013-11-18].
burn: next topic:
setRemoteDescription(), section 4.3.2.3
... conclusion: fluffy will fix the reference
... conclusion (cont.): martin_ will write a proposal
martin_: proposal is "send black"
burn: next topic: updateIce(),
section 4.3.2.3
... skip the constrainable part (we've already got an action on
that)
... conclusion: the method does not have to be queued
... are we done with updateIce?
<martin_> Adding ice servers takes effect right away
<martin_> removing doesn't come into effect until the next time candidate gathering commences (i.e., ICE restart)
<martin_> the candidate filter can't be made more restrictive
<martin_> attempting to make the filter more restrictive generates an error (exception)
<martin_> justin suggested that this could be silent and the restriction could be applied at the next restart
<martin_> ekr points out that this is a security feature and suppressing what is bad behaviour would be not good
<martin_> if you want to make more restrictive filters on candidates, create a new RTCPeerConnection
<stefanh> actions: https://www.w3.org/2011/04/webrtc/track/actions/open
<dom> Today's action items
<martin_> ACTION: EKR to create a proposal for how to report the case where a given MediaStreamTrack cannot be assigned to an m=section due to being unable to obtain codecs [recorded in http://www.w3.org/2013/11/11-webrtc-minutes.html#action13]
<trackbot> Created ACTION-97 - Create a proposal for how to report the case where a given mediastreamtrack cannot be assigned to an m=section due to being unable to obtain codecs [on Eric Rescorla - due 2013-11-18].