00:37:48 RRSAgent has joined #webrtc 00:37:48 logging to http://www.w3.org/2013/11/11-webrtc-irc 00:37:50 RRSAgent, make logs world 00:37:50 Zakim has joined #webrtc 00:37:52 Zakim, this will be RTC 00:37:52 ok, trackbot; I see UW_WebRTC()7:00PM scheduled to start 37 minutes ago 00:37:53 Meeting: Web Real-Time Communications Working Group Teleconference 00:37:53 Date: 11 November 2013 00:38:22 fluffy has joined #webrtc 00:38:31 Zakim, call Wuzhou_Middle 00:38:31 ok, dom_web; the call is being made 00:38:33 UW_WebRTC()7:00PM has now started 00:38:33 +Wuzhou_Middle 00:39:04 Meeting: WebRTC TPAC F2F Day 1 00:39:12 Chair: stefanh, hta 00:39:33 Agenda: http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013 00:41:08 frodek has joined #webrtc 00:45:11 dom has joined #webrtc 00:45:32 adam has joined #webrtc 00:47:12 adam are you in the room here ? 00:47:22 Or dan ? 00:47:27 Which Adam? 00:47:37 Bergkvist 00:47:48 I am not Adam Bergkvist. 00:47:54 ack 00:48:33 dom_ has joined #webrtc 00:48:34 If someone see Adam Bergkvist, or Dan Burnet, can you get them to ping me - thanks Cullen 00:49:07 rbarnes has joined #webrtc 00:49:27 Zakim, who's on the call? 00:49:27 On the phone I see Wuzhou_Middle 00:49:49 martin_ has joined #webrtc 00:50:02 thanks dom 00:50:12 burn has joined #webrtc 00:50:54 ekr has joined #webrtc 00:53:13 elagerway has joined #webrtc 00:53:46 robinraymond has joined #webrtc 00:54:19 hta has joined #webrtc 00:58:57 +??P3 00:59:22 silvia1 has joined #webrtc 00:59:24 dom has joined #webrtc 00:59:54 you guys do not sound good 01:00:21 -Wuzhou_Middle 01:02:04 dom_web_ has joined #webrtc 01:02:09 stephane has joined #webrtc 01:02:45 Zakim, call wuzhou_middle 01:02:45 ok, dom_web_; the call is being made 01:02:46 we are not hearing anything , is someone talking into polycom ? 01:02:47 +Wuzhou_middle 01:03:09 -Wuzhou_middle 01:03:14 Zakim, call wuzhou_middle 01:03:14 ok, dom_web_; the call is being made 01:03:15 ok 01:03:16 +Wuzhou_middle 01:03:46 Zakim, call wuzhou_middle 01:03:46 ok, dom_web_; the call is being made 01:03:47 +Wuzhou_middle.a 01:04:21 can you keep talking for abit 01:04:31 we are getting audio, but it's ugly 01:04:37 -Wuzhou_middle 01:04:56 ok - how is poly com connected to PSTN 01:05:09 it's not good at this end 01:05:33 burn: you sound fine 01:06:51 the gap between 1 and 2 was about 8 seconds 01:07:05 and then the room burst out laughing. 01:07:54 stefanh has joined #webrtc 01:08:12 so if you give us the actual phone# for the room, we can dial that into the hangouts. 01:08:33 can you get us the phone number for polycom 01:08:48 now we go here -> hangouts -> zakim -> polycom 01:09:40 Marcus_Altman has joined #webrtc 01:09:41 dom has joined #webrtc 01:10:00 http://xkcd.com/257/ 01:10:27 droh has joined #webrtc 01:10:48 adambe has joined #webrtc 01:12:02 jesup|laptop has joined #webrtc 01:12:09 kotakagi has joined #webrtc 01:12:14 jinkyu_seong has joined #webrtc 01:13:52 936972 ? 01:13:54 juberti has joined #webrtc 01:14:29 mreavy has joined #webrtc 01:14:33 last minutes: http://lists.w3.org/Archives/Public/public-webrtc/2013Sep/0018.html 01:15:20 http://www.w3.org/2011/04/webrtc/wiki/images/8/8c/W3C_TPAC_2013_ICE_Issues.pdf 01:15:46 dom_ has joined #webrtc 01:15:50 stephane_ has joined #webrtc 01:15:50 juberti has joined #webrtc 01:16:00 DanD has joined #webrtc 01:16:12 RRSAgent, draft minutes 01:16:12 I have made the request to generate http://www.w3.org/2013/11/11-webrtc-minutes.html dom_ 01:16:23 Topic: ICE 01:17:22 Dan has joined #webrtc 01:17:34 -> http://www.w3.org/2011/04/webrtc/wiki/images/8/8c/W3C_TPAC_2013_ICE_Issues.pdf ICE Issues slides 01:18:18 yahui has joined #webrtc 01:18:19 on slide 3 01:18:52 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 01:19:31 fluffy: many applications won't need this 01:19:39 AndyF has joined #webrtc 01:19:52 we're not locally chitchatting, we're discussing the question 01:19:56 richt has joined #webrtc 01:20:26 bo_hu_ChinaUnicom has joined #webrtc 01:20:38 richt_ has joined #webrtc 01:20:42 OK 01:21:50 q? 01:22:00 q+ 01:22:01 please no local chitchat in shenzhen 01:22:56 For the record, I'm good with the decision to do nothing special about rtcpmux, requiring it or not. 01:23:12 So the conclusion was that this is OK. 01:23:12 richt__ has joined #webrtc 01:23:28 dom, it's impossible to scribe on this side either - it's just back and forth too fast 01:24:54 alexG has joined #webrtc 01:25:33 Key point for minutes, as long as PC is alive, it will keep the candidates in the pool "warm" so they work when needed 01:25:33 question here was whether the candidates will be kept warm, and Justin says yes, which means heartbeats 01:25:42 juberti: The idea is that this pool is pre-allocation, and everything else remains the same. 01:25:44 Browsers will need to maintain a cap 01:25:47 Key point for minutes, might need some sort of cap 01:26:03 derf will try to scribe 01:26:07 juberti: We probably need to specify some kind of cap, but it's your TURN server and if you want to pound it... 01:26:25 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. 01:26:35 juberti: We should just decide what's a reasonable maximum. 01:26:43 martin_: I think I'd be happy with the browsers doing that. 01:26:50 juberti: But we should provide some recommendations. 01:27:07 fluffy: If it's just something like 50 or 100... 01:27:13 adam: 100 ports on your NAT? 01:27:18 fluffy: Google maps does that all the time. 01:27:19 cullen: yes 01:27:32 hta: I have seen the logs from bittorrent... 01:27:49 ekr: TCP has a different set of properties, because it does not need to allocate a port that's shared between every remote guy. 01:28:01 ekr: We specifically advise people to do that on their NATs, so it's not the same. 01:28:05 derf: do you want help scribing? 01:28:14 fluffy: We're just talking about the size of the pool. 01:28:21 GangL has joined #webrtc 01:28:30 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. 01:28:31 jeromemarcon has joined #webrtc 01:28:34 martin_: So why do you need more than 5? 01:28:36 dopi has joined #webrtc 01:29:04 juberti: I'm not sure it buys us anything to have the limit be less than could be allocated by SLD. 01:29:14 ekr: I agree those limits should be the same. 01:29:25 juberti: We should just set some number that's bigger than the largest reasonable use case. 01:29:27 it is difficult to break in from here, but it seems reasonable to have a limit 01:29:41 we can institute queue discipline if needed 01:29:43 fluffy: I think it's more in the order of the magnitude of 50 than 5, and certainly not 5,000. 01:29:53 hta: I would suggest that juberti pick a number and we can debate on the list. 01:30:00 juberti: I would like Cullen... 01:30:05 fluffy: I'll take an action to pick a number. 01:30:15 tcai has joined #webrtc 01:30:24 adam: I presume that maximum is per page, per browser...? 01:30:30 ekr: It has to be per browser because of shared origins. 01:30:46 fluffy: There are certainly people who want to use the data channel with hundreds of origins. 01:30:46 Wuyan has joined #Webrtc 01:31:05 juberti: We should take an action to figure out what the security implications are. 01:31:09 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 01:31:50 ekr: Is it encouraged for an implementation to start gathering on addStream if they know the number of candidates? 01:32:25 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. 01:32:28 ekr: Uh, no... 01:32:30 martin_: Why? 01:32:36 +[IPcaller] 01:32:42 ekr: Let juberti finish his presentation. It's on the last slide. 01:32:44 -[IPcaller] 01:32:54 derf: negative, at the end of this slide 01:33:08 s/on the last/at the end of this/ 01:33:34 juberti: The way the spec is currently written candidate gathering doesn't start until first SLD. 01:34:14 JimBarnett has joined #webrtc 01:34:20 stefanh: How long will these candidates be alive if you create the PC and do nothing with it? 01:34:35 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. 01:34:45 adam: I have this on my slides. Our proposals are remarkably similar. 01:34:59 ekr: I have two concerns vis a vis CreateOffer and CreateAnswer don't have candidates. 01:35:20 ekr: There are lots of cases where candidates are available---any renegotation---and it's silly to gather new candidates when they're available. 01:35:36 +Jim_Barnett 01:35:39 ekr: The other reason is that Firefox does it this way, and I don't see any reason to do it another way. 01:35:52 juberti: If I ask for 10 ports, how do you know there's 10 sitting aroudn? 01:36:00 ekr: We have a list of what's sitting around. 01:36:12 adam: If you ask for 10 and there's 4 sitting around, we return 4 and trickle the rest. 01:36:32 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. 01:36:43 martin_: I have some issue with gathering candidates after SetLocal. 01:36:55 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 01:37:33 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? 01:37:47 juberti: I don't think it's a good idea to add TURN candidates the application didn't ask for. 01:37:55 adam: I don't think this is an interoperability issue. 01:38:22 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. 01:38:48 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... 01:38:54 juberti: I think our default is 0. 01:39:16 juberti: A certain large social network told us that TURN usage is their largest bottleneck. 01:39:22 juberti: It's not CPU, it's bandwidth. 01:39:32 adam: Holding a port open is not going to consume bandwidth. 01:39:41 jesup: I think there is an advantage to starting to spin those up. 01:39:59 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. 01:40:01 BaopingCheng_CMCC has joined #webrtc 01:40:14 hta: That raises another question with a constraint... do you set an upper limit, a lower limit, or both? 01:40:28 juberti: I think you should not be getting more than this. If you set a local description that requires more, then you gather more. 01:40:41 Keeping a port open will not consume BW, but we have the batery issue: on a mobile device it would consume battery 01:40:44 hta: If the browser would normally prefetch 5 just in case, and you set the constraint to 3, should it gather 3 or 5? 01:40:49 adam: I think it should be 3. 01:41:03 adam: Because it indicates the application knows what is about to happen. 01:41:08 yusuke_ has joined #webrtc 01:41:25 juberti: The code works the same way regardless of whether this is implemented or not implemented, it's just faster. 01:41:33 juberti: But it prevents unnecessary TURN server load. 01:41:53 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. 01:42:10 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. 01:42:17 juberti: I don't understand how that follows. 01:42:35 hta: If I say RTCP-mux required and I'm talking to someone who doesn't understand it... 01:42:42 fluffy: Then you just don't sent RTCP. 01:42:52 martin_: As Hadriel has pointed out, you can get this stuff to work. 01:42:55 fluffy: I know, I know... 01:43:44 We have muted the phone here and are experimenting with adding hangoutns 01:43:45 fluffy: I do think the RTCP-mux issue is completely independent of this one. 01:43:52 fluffy: We should have an argument about it someday, but not now. 01:44:19 goodbye 01:45:30 Travis_MSFT has joined #webrtc 01:47:57 ok 01:48:05 Travis_MSFT: we're messing with connectivity. 01:48:12 -??P3 01:48:16 Please raise that again in a minute 01:49:08 dom, you have to unmute 01:51:29 Seattle, could you back one Zakim? 01:51:38 That seems like better for the audio 01:51:47 We don't hear you now 01:51:51 +??P3 01:52:00 jeff has joined #webrtc 01:53:27 leckie has joined #webrtc 01:54:13 Are we ready to continue? 01:54:58 juberti: Slide 4, candidate pool continued... 01:55:07 juberti: We had a lively debate about what exactly the constraint should do. 01:55:24 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. 01:55:43 juberti: But if CreateOffer wanted to return these candidates plus other host candidates, that would be okay. 01:56:02 adam: But if the browser saw the need for other candidates because of addStream calls, etc., it could return more. 01:56:24 juberti: If addStream is called we could add another 1 or 2 because of RTCP-mux then the browser could return more candidates... 01:56:41 adam: If they're available when CreateOffer is called. 01:56:49 martin_: Unless BUNDLE-only is set. 01:57:02 adam: Yeah, then you don't need to add more, but that's simple to do. 01:57:18 burn: We're just talking about pre-gathering, not the final candidates to gather, right? 01:57:34 juberti: I think the boost is fairly nominal, but there's no reason not to do it. 01:57:38 DanD has joined #webrtc 01:57:46 martin_: The other one to think of is OfferToReceiveVideo/OfferToReceiveAudio... 01:57:51 adam: You're reading my slides now, aren't you. 01:58:06 ken_ has joined #webrtc 01:58:07 +1 to the idea (fluffy also +1'd) 01:58:14 martin_: Pretend that someone had added those candidates as if they'd added a stream. 01:58:25 fluffy: Can we table that? 01:58:32 chairs: we need a clearer description of how to offer to receive >1 audio/video 01:58:33 adam: The OfferToReceive? 01:58:45 fluffy: How we extend the constraint beyond being true/false. 01:58:49 Adam suggests that OfferToReceive{Audio|Video} be made an integer 01:58:49 adam: Integer. 01:58:52 fluffy: Thumbs up. 01:59:04 martin_: Does anyone have a problem with an integer? 01:59:17 ekr: I'm not sure because of receive-only vs. receive. 01:59:26 hta: Okay, let's add that later in the agenda so we have a little time to think about it. 01:59:30 juberti: On to slide 5... 01:59:35 juberti: When does ICE end up in the completed state? 01:59:38 the integer represent the number of ...? m= lines? 01:59:47 adambe: I have a question on this new constraint. 02:00:33 juberti: Previously there's no way to change this after you create a PC, and now you can. 02:00:47 juberti: What happens if you change it from 4 to 8, etc., but I think that's probably pretty predicatable. 02:01:03 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. 02:01:08 martin_: Are you asking for 2 more? 02:01:41 juberti: adambe was saying everyhing has this constrainable interface where all of this can be changed on the fly. 02:01:44 adam: Really? 02:02:05 q+ 02:02:08 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. 02:02:13 juberti: I understand where you're going with that. 02:02:15 Q+ 02:02:39 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..." 02:02:48 juberti: That's kind of what adambe was getting at. 02:02:53 ekr: Sold. 02:03:07 martin_: Do we have any objections to that course of action. 02:03:13 adam: I didn't understand it. 02:03:37 Proposed Action , adam to move the pool size from the constrains but instead put it into the turn server configuration 02:03:38 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. 02:03:41 adam: +1 02:03:53 juberti: I assume this will just be a nullable property. 02:04:00 martin_: It's a dictionary, they're always nullable. 02:04:12 fluffy: I'm proposing we don't even need a proposal. If we're all agreed upon here, adambe should do it. 02:04:33 BTW, adambe: you need to remove all those '?' characters from the dictionaries. 02:04:33 Action adam: Move ICE candidate count from constraint to RTCConfiguratoin. 02:04:34 Created ACTION-87 - Move ice candidate count from constraint to rtcconfiguratoin. [on Adam Bergkvist - due 2013-11-18]. 02:04:40 juberti: Why did we ever think it was a good idea as a constraint? 02:05:01 Action adambe: Remove '?' characters from all dictionaries. 02:05:01 Created ACTION-88 - Remove '?' characters from all dictionaries. [on Adam Bergkvist - due 2013-11-18]. 02:05:11 JimBarnett: I just want to point out that the language of the constrainable interface allows for constraints that can't be changed. 02:05:21 juberti: That's good, because that avoids the issues ekr was concerned about. 02:05:36 hta: If we want constraints to be unchangeable or changeable, we'd better specify that. That's another issue. 02:05:47 JimBarnett: Yes, that would be part of the definition of the property. That cannot be changed. 02:06:11 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. 02:06:30 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. 02:06:45 juberti: I didn't get a sense that the issue of these constraints that can't be changed was resolved. 02:06:53 hta: But it's not an ICE issue, so we should move on. 02:07:03 juberti: When is ICE done? 02:07:30 juberti: 02:07:33 AndyF has joined #webRTC 02:08:15 juberti: When can the controlled side know, if there's no updated offer, that the controlling side is done? 02:08:27 martin_: The easy solution is that when you get the TLS finish message, you know where you're going. 02:08:49 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. 02:08:51 q+ what would happend if you had a device with a slow wireless connection and a fast wired connection? 02:08:58 martin_: Or you might change your mind. 02:09:05 juberti: That's what I want to get to in the next slide. Why do we care? 02:09:12 juberti: There's a couple of answer. 02:09:23 juberti: On the controlling side, it may want to send the updated offer with the real candidates. 02:09:36 q+ what would happen if you had multiple local interfaces? 02:09:36 juberti: The controlled side doesn't need that, it just needs to know when to release candidates that aren't going to be used. 02:09:39 juberti: And it can just wait. 02:09:42 martin_: Consent. 02:09:50 juberti: Consent is not going to be on every single candidate pair. 02:10:07 martin_: You just stop doing the refresh stuff and consent will expire after 30 seconds of not getting packets from the other side. 02:10:07 chris has joined #webrtc 02:10:19 q+ 02:10:22 q? 02:10:24 q- 02:10:27 q- 02:10:28 q- 02:10:37 juberti: It's up to the implementation to decide which connection to use, and it should already do interface prioritization. 02:10:51 juberti: The interesting case is the reverse, where you'd have to use something like RTT... 02:10:56 martin_: Or PCP, but that's an IETF issue. 02:11:08 juberti: Or something that has a low RTT until you start using it and then it has a high RTT. 02:11:13 fluffy: See connection to China right now. 02:11:16 juberti: We're familiar with that. 02:11:21 fluffy: There's no great win here. 02:11:27 juberti: This is just an implementation issue. 02:11:38 fluffy: Every implementation I've seen, at some level or other, at the bottom there's a timeout. 02:11:51 q+ to say what happens when you have multiple local interfaces 02:11:57 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. 02:12:02 Marcus_Altman has joined #webrtc 02:12:02 q+ 02:12:33 q+ 02:12:38 ack andyF 02:12:38 AndyF, you wanted to say what happens when you have multiple local interfaces 02:12:41 q- 02:14:04 DanD has joined #webrtc 02:14:18 the IETF has a whole working group on Multiple Interfaces 02:14:19 hta: That's an ICE question. 02:14:26 juberti: I think there's two different things being discussed there. 02:14:36 juberti: One is the size of the candidate pool, and one is the number interfaces. 02:14:43 And ICE already deals with local interface prioritization effectively 02:14:47 juberti: And there isn't really any limit to the number of interfaces. 02:15:07 juberti: This is the number of candidate sets to pre-gather, but it will pre-gather for every single interface that you have. 02:15:16 TonyKuo has joined #Webrtc 02:15:17 q? 02:15:31 ack martin_ 02:15:51 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. 02:16:04 Qiuling has joined #webrtc 02:16:05 martin_: 30 seconds... allowing it to clean up most of them, there's some ambiguity there... 02:16:22 martin_: But if the controlled side is just keeping candidates that have consent warm, then at some point it will clean them up. 02:16:47 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. 02:16:50 taocai has joined #webrtc 02:17:04 juberti: I'm just thinking maybe we're using the word consent in different ways. 02:17:21 juberti: As the process moves forwards you're going to be sending connectivity checks, and at some point stop doing them. 02:17:28 juberti: But I don't think that's the same thing as consent. 02:17:32 martin_: We need to talk about consent. 02:17:32 q+ 02:17:41 hta: Who's got the token on consent because I think it's an IETF issue. 02:17:59 martin_: It is an IETF issue. I think there's enough information on the controlled side for it to release the pairs. 02:18:03 q- 02:18:16 juberti: If you ping on something other than the active one, does that establish consent? 02:18:20 fluffy: On that one. 02:18:25 q- 02:18:25 juberti: So it's consent per 5-tuple? 02:18:38 jeff_ has joined #webrtc 02:18:47 hta: The consent for STUN draft has 4 editors from Cisco. Can you make sure they're told they'd better specify where this threshold lies? 02:18:57 fluffy: I think there's a much better solution to this problem of four editors from Cisco. 02:19:09 martin_: I've been talking to Dan and this document is going to get a rewrite. 02:19:14 juberti: I volunteer to help with that document. 02:19:19 martin_: I've already made that offer as well. 02:19:28 fluffy: Sync up with me and I will facilitate a change of editors. 02:19:29 s/where this threshold lies/on what pairs consent should be sent/ 02:19:33 ekr: It's using a binary request, still? 02:19:35 juberti: Yes. 02:19:49 ekr: From the recipient side there's no way to distinguish between a continued one and a regular one. 02:20:06 ekr: Any candidate pair that you have not received any STUN check on for some period of time, you assume it will be dead. 02:20:23 martin_: The controlling side will stop responding, and at that point it no longer has consent. 02:20:34 martin_: If you want to open that again you need a new ufrag and password. 02:20:40 fluffy: That time is 30 seconds? 02:20:47 juberti: That's the exact value we use. 02:21:20 ekr: 02:21:24 martin_: Let's take this offline. 02:21:29 derf: chicken chicken chicken 02:21:30 hta: I definitely think this is an IETF issue. 02:21:41 fluffy: Who are the people we think know the answer to that issue? 02:21:44 martin, ekr, justin, dan will sort it out. 02:21:48 martin_: Myself and juberti. 02:21:56 ekr: The same people who failed to address this last time. 02:22:02 ekr: This time we'll assign martin_ to do it. 02:22:08 juberti: The controlling side there's no question. 02:22:08 action martin_: Drive IETF discussion to decide where consent will be sent. 02:22:09 Error finding 'martin_'. You can review and register nicknames at . 02:22:31 action martin: Drive IETF discussion to decide where consent will be sent. 02:22:32 Created ACTION-89 - Drive ietf discussion to decide where consent will be sent. [on Martin Thomson - due 2013-11-18]. 02:22:49 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. 02:22:58 ekr: That sounds provisionally okay but I'd like to hear the outcome of martin_'s proposal. 02:23:06 juberti: Moving on to the next slide. 02:23:20 I would like to be involved in the ICE discussion 02:23:51 juberti: I think the next slide is going to be uncontroversial... I've said that many times before. 02:23:55 juberti: ICE restart. 02:24:20 juberti: ICE restart is in the current editors' draft. 02:24:45 juberti: The basic mechanism is that if you specify the IceRestart constraint to CreateOffer, the returned description has new ICE credentials. 02:25:07 juberti: Similarly if you receive a description with new credentials, this forces a restart. 02:25:18 juberti: The actual restart is triggered by setLocalDescription. 02:25:50 ekr: If I call createOffer _twice_ with the same constraint inbetween, do I get the same ufrag and password or a new one? 02:26:06 juberti: createOffer isn't supposed to change anything. 02:26:13 ekr: But I don't want to keep a stack of these. 02:26:33