IRC log of webrtc on 2013-11-11

Timestamps are in UTC.

00:37:48 [RRSAgent]
RRSAgent has joined #webrtc
00:37:48 [RRSAgent]
logging to http://www.w3.org/2013/11/11-webrtc-irc
00:37:50 [trackbot]
RRSAgent, make logs world
00:37:50 [Zakim]
Zakim has joined #webrtc
00:37:52 [trackbot]
Zakim, this will be RTC
00:37:52 [Zakim]
ok, trackbot; I see UW_WebRTC()7:00PM scheduled to start 37 minutes ago
00:37:53 [trackbot]
Meeting: Web Real-Time Communications Working Group Teleconference
00:37:53 [trackbot]
Date: 11 November 2013
00:38:22 [fluffy]
fluffy has joined #webrtc
00:38:31 [dom_web]
Zakim, call Wuzhou_Middle
00:38:31 [Zakim]
ok, dom_web; the call is being made
00:38:33 [Zakim]
UW_WebRTC()7:00PM has now started
00:38:33 [Zakim]
+Wuzhou_Middle
00:39:04 [dom_web]
Meeting: WebRTC TPAC F2F Day 1
00:39:12 [dom_web]
Chair: stefanh, hta
00:39:33 [dom_web]
Agenda: http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013
00:41:08 [frodek]
frodek has joined #webrtc
00:45:11 [dom]
dom has joined #webrtc
00:45:32 [adam]
adam has joined #webrtc
00:47:12 [fluffy]
adam are you in the room here ?
00:47:22 [fluffy]
Or dan ?
00:47:27 [adam]
Which Adam?
00:47:37 [fluffy]
Bergkvist
00:47:48 [adam]
I am not Adam Bergkvist.
00:47:54 [fluffy]
ack
00:48:33 [dom_]
dom_ has joined #webrtc
00:48:34 [fluffy]
If someone see Adam Bergkvist, or Dan Burnet, can you get them to ping me - thanks Cullen
00:49:07 [rbarnes]
rbarnes has joined #webrtc
00:49:27 [dom_]
Zakim, who's on the call?
00:49:27 [Zakim]
On the phone I see Wuzhou_Middle
00:49:49 [martin_]
martin_ has joined #webrtc
00:50:02 [fluffy]
thanks dom
00:50:12 [burn]
burn has joined #webrtc
00:50:54 [ekr]
ekr has joined #webrtc
00:53:13 [elagerway]
elagerway has joined #webrtc
00:53:46 [robinraymond]
robinraymond has joined #webrtc
00:54:19 [hta]
hta has joined #webrtc
00:58:57 [Zakim]
+??P3
00:59:22 [silvia1]
silvia1 has joined #webrtc
00:59:24 [dom]
dom has joined #webrtc
00:59:54 [ekr]
you guys do not sound good
01:00:21 [Zakim]
-Wuzhou_Middle
01:02:04 [dom_web_]
dom_web_ has joined #webrtc
01:02:09 [stephane]
stephane has joined #webrtc
01:02:45 [dom_web_]
Zakim, call wuzhou_middle
01:02:45 [Zakim]
ok, dom_web_; the call is being made
01:02:46 [fluffy]
we are not hearing anything , is someone talking into polycom ?
01:02:47 [Zakim]
+Wuzhou_middle
01:03:09 [Zakim]
-Wuzhou_middle
01:03:14 [dom_web_]
Zakim, call wuzhou_middle
01:03:14 [Zakim]
ok, dom_web_; the call is being made
01:03:15 [fluffy]
ok
01:03:16 [Zakim]
+Wuzhou_middle
01:03:46 [dom_web_]
Zakim, call wuzhou_middle
01:03:46 [Zakim]
ok, dom_web_; the call is being made
01:03:47 [Zakim]
+Wuzhou_middle.a
01:04:21 [fluffy]
can you keep talking for abit
01:04:31 [martin_]
we are getting audio, but it's ugly
01:04:37 [Zakim]
-Wuzhou_middle
01:04:56 [fluffy]
ok - how is poly com connected to PSTN
01:05:09 [fluffy]
it's not good at this end
01:05:33 [ekr]
burn: you sound fine
01:06:51 [martin_]
the gap between 1 and 2 was about 8 seconds
01:07:05 [hta]
and then the room burst out laughing.
01:07:54 [stefanh]
stefanh has joined #webrtc
01:08:12 [hta]
so if you give us the actual phone# for the room, we can dial that into the hangouts.
01:08:33 [fluffy]
can you get us the phone number for polycom
01:08:48 [hta]
now we go here -> hangouts -> zakim -> polycom
01:09:40 [Marcus_Altman]
Marcus_Altman has joined #webrtc
01:09:41 [dom]
dom has joined #webrtc
01:10:00 [rbarnes]
http://xkcd.com/257/
01:10:27 [droh]
droh has joined #webrtc
01:10:48 [adambe]
adambe has joined #webrtc
01:12:02 [jesup|laptop]
jesup|laptop has joined #webrtc
01:12:09 [kotakagi]
kotakagi has joined #webrtc
01:12:14 [jinkyu_seong]
jinkyu_seong has joined #webrtc
01:13:52 [martin_]
936972 ?
01:13:54 [juberti]
juberti has joined #webrtc
01:14:29 [mreavy]
mreavy has joined #webrtc
01:14:33 [stefanh]
last minutes: http://lists.w3.org/Archives/Public/public-webrtc/2013Sep/0018.html
01:15:20 [fluffy]
http://www.w3.org/2011/04/webrtc/wiki/images/8/8c/W3C_TPAC_2013_ICE_Issues.pdf
01:15:46 [dom_]
dom_ has joined #webrtc
01:15:50 [stephane_]
stephane_ has joined #webrtc
01:15:50 [juberti]
juberti has joined #webrtc
01:16:00 [DanD]
DanD has joined #webrtc
01:16:12 [dom_]
RRSAgent, draft minutes
01:16:12 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/11/11-webrtc-minutes.html dom_
01:16:23 [dom_]
Topic: ICE
01:17:22 [Dan]
Dan has joined #webrtc
01:17:34 [dom_]
-> http://www.w3.org/2011/04/webrtc/wiki/images/8/8c/W3C_TPAC_2013_ICE_Issues.pdf ICE Issues slides
01:18:18 [yahui]
yahui has joined #webrtc
01:18:19 [fluffy]
on slide 3
01:18:52 [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
01:19:31 [martin_]
fluffy: many applications won't need this
01:19:39 [AndyF]
AndyF has joined #webrtc
01:19:52 [ekr]
we're not locally chitchatting, we're discussing the question
01:19:56 [richt]
richt has joined #webrtc
01:20:26 [bo_hu_ChinaUnicom]
bo_hu_ChinaUnicom has joined #webrtc
01:20:38 [richt_]
richt_ has joined #webrtc
01:20:42 [ekr]
OK
01:21:50 [fluffy]
q?
01:22:00 [ekr]
q+
01:22:01 [rbarnes]
please no local chitchat in shenzhen
01:22:56 [martin_]
For the record, I'm good with the decision to do nothing special about rtcpmux, requiring it or not.
01:23:12 [martin_]
So the conclusion was that this is OK.
01:23:12 [richt__]
richt__ has joined #webrtc
01:23:28 [fluffy]
dom, it's impossible to scribe on this side either - it's just back and forth too fast
01:24:54 [alexG]
alexG has joined #webrtc
01:25:33 [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
01:25:33 [martin_]
question here was whether the candidates will be kept warm, and Justin says yes, which means heartbeats
01:25:42 [derf]
juberti: The idea is that this pool is pre-allocation, and everything else remains the same.
01:25:44 [martin_]
Browsers will need to maintain a cap
01:25:47 [fluffy]
Key point for minutes, might need some sort of cap
01:26:03 [hta]
derf will try to scribe
01:26:07 [derf]
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 [derf]
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 [derf]
juberti: We should just decide what's a reasonable maximum.
01:26:43 [derf]
martin_: I think I'd be happy with the browsers doing that.
01:26:50 [derf]
juberti: But we should provide some recommendations.
01:27:07 [derf]
fluffy: If it's just something like 50 or 100...
01:27:13 [derf]
adam: 100 ports on your NAT?
01:27:18 [derf]
fluffy: Google maps does that all the time.
01:27:19 [jesup]
cullen: yes
01:27:32 [derf]
hta: I have seen the logs from bittorrent...
01:27:49 [derf]
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 [derf]
ekr: We specifically advise people to do that on their NATs, so it's not the same.
01:28:05 [jesup]
derf: do you want help scribing?
01:28:14 [derf]
fluffy: We're just talking about the size of the pool.
01:28:21 [GangL]
GangL has joined #webrtc
01:28:30 [derf]
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]
jeromemarcon has joined #webrtc
01:28:34 [derf]
martin_: So why do you need more than 5?
01:28:36 [dopi]
dopi has joined #webrtc
01:29:04 [derf]
juberti: I'm not sure it buys us anything to have the limit be less than could be allocated by SLD.
01:29:14 [derf]
ekr: I agree those limits should be the same.
01:29:25 [derf]
juberti: We should just set some number that's bigger than the largest reasonable use case.
01:29:27 [stefanh]
it is difficult to break in from here, but it seems reasonable to have a limit
01:29:41 [ekr]
we can institute queue discipline if needed
01:29:43 [derf]
fluffy: I think it's more in the order of the magnitude of 50 than 5, and certainly not 5,000.
01:29:53 [derf]
hta: I would suggest that juberti pick a number and we can debate on the list.
01:30:00 [derf]
juberti: I would like Cullen...
01:30:05 [derf]
fluffy: I'll take an action to pick a number.
01:30:15 [tcai]
tcai has joined #webrtc
01:30:24 [derf]
adam: I presume that maximum is per page, per browser...?
01:30:30 [derf]
ekr: It has to be per browser because of shared origins.
01:30:46 [derf]
fluffy: There are certainly people who want to use the data channel with hundreds of origins.
01:30:46 [Wuyan]
Wuyan has joined #Webrtc
01:31:05 [derf]
juberti: We should take an action to figure out what the security implications are.
01:31:09 [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
01:31:50 [derf]
ekr: Is it encouraged for an implementation to start gathering on addStream if they know the number of candidates?
01:32:25 [derf]
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 [derf]
ekr: Uh, no...
01:32:30 [derf]
martin_: Why?
01:32:36 [Zakim]
+[IPcaller]
01:32:42 [derf]
ekr: Let juberti finish his presentation. It's on the last slide.
01:32:44 [Zakim]
-[IPcaller]
01:32:54 [ekr]
derf: negative, at the end of this slide
01:33:08 [derf]
s/on the last/at the end of this/
01:33:34 [derf]
juberti: The way the spec is currently written candidate gathering doesn't start until first SLD.
01:34:14 [JimBarnett]
JimBarnett has joined #webrtc
01:34:20 [derf]
stefanh: How long will these candidates be alive if you create the PC and do nothing with it?
01:34:35 [derf]
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 [derf]
adam: I have this on my slides. Our proposals are remarkably similar.
01:34:59 [derf]
ekr: I have two concerns vis a vis CreateOffer and CreateAnswer don't have candidates.
01:35:20 [derf]
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 [Zakim]
+Jim_Barnett
01:35:39 [derf]
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 [derf]
juberti: If I ask for 10 ports, how do you know there's 10 sitting aroudn?
01:36:00 [derf]
ekr: We have a list of what's sitting around.
01:36:12 [derf]
adam: If you ask for 10 and there's 4 sitting around, we return 4 and trickle the rest.
01:36:32 [derf]
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 [derf]
martin_: I have some issue with gathering candidates after SetLocal.
01:36:55 [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
01:37:33 [derf]
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 [derf]
juberti: I don't think it's a good idea to add TURN candidates the application didn't ask for.
01:37:55 [derf]
adam: I don't think this is an interoperability issue.
01:38:22 [derf]
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 [derf]
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 [derf]
juberti: I think our default is 0.
01:39:16 [derf]
juberti: A certain large social network told us that TURN usage is their largest bottleneck.
01:39:22 [derf]
juberti: It's not CPU, it's bandwidth.
01:39:32 [derf]
adam: Holding a port open is not going to consume bandwidth.
01:39:41 [derf]
jesup: I think there is an advantage to starting to spin those up.
01:39:59 [derf]
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]
BaopingCheng_CMCC has joined #webrtc
01:40:14 [derf]
hta: That raises another question with a constraint... do you set an upper limit, a lower limit, or both?
01:40:28 [derf]
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 [stefanh]
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 [derf]
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 [derf]
adam: I think it should be 3.
01:41:03 [derf]
adam: Because it indicates the application knows what is about to happen.
01:41:08 [yusuke_]
yusuke_ has joined #webrtc
01:41:25 [derf]
juberti: The code works the same way regardless of whether this is implemented or not implemented, it's just faster.
01:41:33 [derf]
juberti: But it prevents unnecessary TURN server load.
01:41:53 [derf]
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 [derf]
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 [derf]
juberti: I don't understand how that follows.
01:42:35 [derf]
hta: If I say RTCP-mux required and I'm talking to someone who doesn't understand it...
01:42:42 [derf]
fluffy: Then you just don't sent RTCP.
01:42:52 [derf]
martin_: As Hadriel has pointed out, you can get this stuff to work.
01:42:55 [derf]
fluffy: I know, I know...
01:43:44 [burn]
We have muted the phone here and are experimenting with adding hangoutns
01:43:45 [derf]
fluffy: I do think the RTCP-mux issue is completely independent of this one.
01:43:52 [derf]
fluffy: We should have an argument about it someday, but not now.
01:44:19 [ekr]
goodbye
01:45:30 [Travis_MSFT]
Travis_MSFT has joined #webrtc
01:47:57 [fluffy]
ok
01:48:05 [ekr]
Travis_MSFT: we're messing with connectivity.
01:48:12 [Zakim]
-??P3
01:48:16 [ekr]
Please raise that again in a minute
01:49:08 [hta]
dom, you have to unmute
01:51:29 [stefanh]
Seattle, could you back one Zakim?
01:51:38 [stefanh]
That seems like better for the audio
01:51:47 [stefanh]
We don't hear you now
01:51:51 [Zakim]
+??P3
01:52:00 [jeff]
jeff has joined #webrtc
01:53:27 [leckie]
leckie has joined #webrtc
01:54:13 [stefanh]
Are we ready to continue?
01:54:58 [derf]
juberti: Slide 4, candidate pool continued...
01:55:07 [derf]
juberti: We had a lively debate about what exactly the constraint should do.
01:55:24 [derf]
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 [derf]
juberti: But if CreateOffer wanted to return these candidates plus other host candidates, that would be okay.
01:56:02 [derf]
adam: But if the browser saw the need for other candidates because of addStream calls, etc., it could return more.
01:56:24 [derf]
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 [derf]
adam: If they're available when CreateOffer is called.
01:56:49 [derf]
martin_: Unless BUNDLE-only is set.
01:57:02 [derf]
adam: Yeah, then you don't need to add more, but that's simple to do.
01:57:18 [derf]
burn: We're just talking about pre-gathering, not the final candidates to gather, right?
01:57:34 [derf]
juberti: I think the boost is fairly nominal, but there's no reason not to do it.
01:57:38 [DanD]
DanD has joined #webrtc
01:57:46 [derf]
martin_: The other one to think of is OfferToReceiveVideo/OfferToReceiveAudio...
01:57:51 [derf]
adam: You're reading my slides now, aren't you.
01:58:06 [ken_]
ken_ has joined #webrtc
01:58:07 [jesup]
+1 to the idea (fluffy also +1'd)
01:58:14 [derf]
martin_: Pretend that someone had added those candidates as if they'd added a stream.
01:58:25 [derf]
fluffy: Can we table that?
01:58:32 [ekr]
chairs: we need a clearer description of how to offer to receive >1 audio/video
01:58:33 [derf]
adam: The OfferToReceive?
01:58:45 [derf]
fluffy: How we extend the constraint beyond being true/false.
01:58:49 [martin_]
Adam suggests that OfferToReceive{Audio|Video} be made an integer
01:58:49 [derf]
adam: Integer.
01:58:52 [derf]
fluffy: Thumbs up.
01:59:04 [derf]
martin_: Does anyone have a problem with an integer?
01:59:17 [derf]
ekr: I'm not sure because of receive-only vs. receive.
01:59:26 [derf]
hta: Okay, let's add that later in the agenda so we have a little time to think about it.
01:59:30 [derf]
juberti: On to slide 5...
01:59:35 [derf]
juberti: When does ICE end up in the completed state?
01:59:38 [rbarnes]
the integer represent the number of ...? m= lines?
01:59:47 [derf]
adambe: I have a question on this new constraint.
02:00:33 [derf]
juberti: Previously there's no way to change this after you create a PC, and now you can.
02:00:47 [derf]
juberti: What happens if you change it from 4 to 8, etc., but I think that's probably pretty predicatable.
02:01:03 [derf]
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 [derf]
martin_: Are you asking for 2 more?
02:01:41 [derf]
juberti: adambe was saying everyhing has this constrainable interface where all of this can be changed on the fly.
02:01:44 [derf]
adam: Really?
02:02:05 [ekr]
q+
02:02:08 [derf]
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 [derf]
juberti: I understand where you're going with that.
02:02:15 [JimBarnett]
Q+
02:02:39 [derf]
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 [derf]
juberti: That's kind of what adambe was getting at.
02:02:53 [derf]
ekr: Sold.
02:03:07 [derf]
martin_: Do we have any objections to that course of action.
02:03:13 [derf]
adam: I didn't understand it.
02:03:37 [fluffy]
Proposed Action , adam to move the pool size from the constrains but instead put it into the turn server configuration
02:03:38 [derf]
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 [derf]
adam: +1
02:03:53 [derf]
juberti: I assume this will just be a nullable property.
02:04:00 [derf]
martin_: It's a dictionary, they're always nullable.
02:04:12 [derf]
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 [martin_]
BTW, adambe: you need to remove all those '?' characters from the dictionaries.
02:04:33 [hta]
Action adam: Move ICE candidate count from constraint to RTCConfiguratoin.
02:04:34 [trackbot]
Created ACTION-87 - Move ice candidate count from constraint to rtcconfiguratoin. [on Adam Bergkvist - due 2013-11-18].
02:04:40 [derf]
juberti: Why did we ever think it was a good idea as a constraint?
02:05:01 [martin_]
Action adambe: Remove '?' characters from all dictionaries.
02:05:01 [trackbot]
Created ACTION-88 - Remove '?' characters from all dictionaries. [on Adam Bergkvist - due 2013-11-18].
02:05:11 [derf]
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 [derf]
juberti: That's good, because that avoids the issues ekr was concerned about.
02:05:36 [derf]
hta: If we want constraints to be unchangeable or changeable, we'd better specify that. That's another issue.
02:05:47 [derf]
JimBarnett: Yes, that would be part of the definition of the property. That cannot be changed.
02:06:11 [derf]
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 [derf]
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 [derf]
juberti: I didn't get a sense that the issue of these constraints that can't be changed was resolved.
02:06:53 [derf]
hta: But it's not an ICE issue, so we should move on.
02:07:03 [derf]
juberti: When is ICE done?
02:07:30 [derf]
juberti: <reads the slide>
02:07:33 [AndyF]
AndyF has joined #webRTC
02:08:15 [derf]
juberti: When can the controlled side know, if there's no updated offer, that the controlling side is done?
02:08:27 [derf]
martin_: The easy solution is that when you get the TLS finish message, you know where you're going.
02:08:49 [derf]
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 [AndyF]
q+ what would happend if you had a device with a slow wireless connection and a fast wired connection?
02:08:58 [derf]
martin_: Or you might change your mind.
02:09:05 [derf]
juberti: That's what I want to get to in the next slide. Why do we care?
02:09:12 [derf]
juberti: There's a couple of answer.
02:09:23 [derf]
juberti: On the controlling side, it may want to send the updated offer with the real candidates.
02:09:36 [AndyF]
q+ what would happen if you had multiple local interfaces?
02:09:36 [derf]
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 [derf]
juberti: And it can just wait.
02:09:42 [derf]
martin_: Consent.
02:09:50 [derf]
juberti: Consent is not going to be on every single candidate pair.
02:10:07 [derf]
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]
chris has joined #webrtc
02:10:19 [hta]
q+
02:10:22 [hta]
q?
02:10:24 [hta]
q-
02:10:27 [ekr]
q-
02:10:28 [JimBarnett]
q-
02:10:37 [derf]
juberti: It's up to the implementation to decide which connection to use, and it should already do interface prioritization.
02:10:51 [derf]
juberti: The interesting case is the reverse, where you'd have to use something like RTT...
02:10:56 [derf]
martin_: Or PCP, but that's an IETF issue.
02:11:08 [derf]
juberti: Or something that has a low RTT until you start using it and then it has a high RTT.
02:11:13 [derf]
fluffy: See connection to China right now.
02:11:16 [derf]
juberti: We're familiar with that.
02:11:21 [derf]
fluffy: There's no great win here.
02:11:27 [derf]
juberti: This is just an implementation issue.
02:11:38 [derf]
fluffy: Every implementation I've seen, at some level or other, at the bottom there's a timeout.
02:11:51 [AndyF]
q+ to say what happens when you have multiple local interfaces
02:11:57 [derf]
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]
Marcus_Altman has joined #webrtc
02:12:02 [martin_]
q+
02:12:33 [fluffy]
q+
02:12:38 [hta]
ack andyF
02:12:38 [Zakim]
AndyF, you wanted to say what happens when you have multiple local interfaces
02:12:41 [fluffy]
q-
02:14:04 [DanD]
DanD has joined #webrtc
02:14:18 [rbarnes]
the IETF has a whole working group on Multiple Interfaces <http://tools.ietf.org/wg/mif/>
02:14:19 [derf]
hta: That's an ICE question.
02:14:26 [derf]
juberti: I think there's two different things being discussed there.
02:14:36 [derf]
juberti: One is the size of the candidate pool, and one is the number interfaces.
02:14:43 [martin_]
And ICE already deals with local interface prioritization effectively
02:14:47 [derf]
juberti: And there isn't really any limit to the number of interfaces.
02:15:07 [derf]
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]
TonyKuo has joined #Webrtc
02:15:17 [hta]
q?
02:15:31 [hta]
ack martin_
02:15:51 [derf]
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]
Qiuling has joined #webrtc
02:16:05 [derf]
martin_: 30 seconds... allowing it to clean up most of them, there's some ambiguity there...
02:16:22 [derf]
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 [derf]
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]
taocai has joined #webrtc
02:17:04 [derf]
juberti: I'm just thinking maybe we're using the word consent in different ways.
02:17:21 [derf]
juberti: As the process moves forwards you're going to be sending connectivity checks, and at some point stop doing them.
02:17:28 [derf]
juberti: But I don't think that's the same thing as consent.
02:17:32 [derf]
martin_: We need to talk about consent.
02:17:32 [ekr]
q+
02:17:41 [derf]
hta: Who's got the token on consent because I think it's an IETF issue.
02:17:59 [derf]
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 [ekr]
q-
02:18:16 [derf]
juberti: If you ping on something other than the active one, does that establish consent?
02:18:20 [derf]
fluffy: On that one.
02:18:25 [martin_]
q-
02:18:25 [derf]
juberti: So it's consent per 5-tuple?
02:18:38 [jeff_]
jeff_ has joined #webrtc
02:18:47 [derf]
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 [derf]
fluffy: I think there's a much better solution to this problem of four editors from Cisco.
02:19:09 [derf]
martin_: I've been talking to Dan and this document is going to get a rewrite.
02:19:14 [derf]
juberti: I volunteer to help with that document.
02:19:19 [derf]
martin_: I've already made that offer as well.
02:19:28 [derf]
fluffy: Sync up with me and I will facilitate a change of editors.
02:19:29 [hta]
s/where this threshold lies/on what pairs consent should be sent/
02:19:33 [derf]
ekr: It's using a binary request, still?
02:19:35 [derf]
juberti: Yes.
02:19:49 [derf]
ekr: From the recipient side there's no way to distinguish between a continued one and a regular one.
02:20:06 [derf]
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 [derf]
martin_: The controlling side will stop responding, and at that point it no longer has consent.
02:20:34 [derf]
martin_: If you want to open that again you need a new ufrag and password.
02:20:40 [derf]
fluffy: That time is 30 seconds?
02:20:47 [derf]
juberti: That's the exact value we use.
02:21:20 [derf]
ekr: <detailed discussion I missed>
02:21:24 [derf]
martin_: Let's take this offline.
02:21:29 [ekr]
derf: chicken chicken chicken
02:21:30 [derf]
hta: I definitely think this is an IETF issue.
02:21:41 [derf]
fluffy: Who are the people we think know the answer to that issue?
02:21:44 [hta]
martin, ekr, justin, dan will sort it out.
02:21:48 [derf]
martin_: Myself and juberti.
02:21:56 [derf]
ekr: The same people who failed to address this last time.
02:22:02 [derf]
ekr: This time we'll assign martin_ to do it.
02:22:08 [derf]
juberti: The controlling side there's no question.
02:22:08 [hta]
action martin_: Drive IETF discussion to decide where consent will be sent.
02:22:09 [trackbot]
Error finding 'martin_'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
02:22:31 [hta]
action martin: Drive IETF discussion to decide where consent will be sent.
02:22:32 [trackbot]
Created ACTION-89 - Drive ietf discussion to decide where consent will be sent. [on Martin Thomson - due 2013-11-18].
02:22:49 [derf]
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 [derf]
ekr: That sounds provisionally okay but I'd like to hear the outcome of martin_'s proposal.
02:23:06 [derf]
juberti: Moving on to the next slide.
02:23:20 [robin]
I would like to be involved in the ICE discussion
02:23:51 [derf]
juberti: I think the next slide is going to be uncontroversial... I've said that many times before.
02:23:55 [derf]
juberti: ICE restart.
02:24:20 [derf]
juberti: ICE restart is in the current editors' draft.
02:24:45 [derf]
juberti: The basic mechanism is that if you specify the IceRestart constraint to CreateOffer, the returned description has new ICE credentials.
02:25:07 [derf]
juberti: Similarly if you receive a description with new credentials, this forces a restart.
02:25:18 [derf]
juberti: The actual restart is triggered by setLocalDescription.
02:25:50 [derf]
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 [derf]
juberti: createOffer isn't supposed to change anything.
02:26:13 [derf]
ekr: But I don't want to keep a stack of these.
02:26:33 [derf]
juberti: I'm not sure I'd be happy with saying there'd only be one outstanding offer ever.
02:26:50 [derf]
ekr: I'd agree with that generally, but this is a special case, because I need to validate that these values are valid.
02:27:05 [derf]
ekr: Generally, if I call createOffer repeatedly with no other actions inbetween, I'd expect to get the same answer back.
02:27:20 [derf]
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.
02:27:29 [derf]
juberti: As long as they're different from the current state, then it's fine.
02:28:04 [derf]
juberti: We start with ufrag 0...
02:28:14 [derf]
fluffy: Just type it into the minutes because everyone's going to agree with you.
02:28:38 [ekr]
CreateOffer() --> A
02:28:56 [derf]
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.
02:29:04 [derf]
juberti: In this particular case I think that'd probably be fine.
02:29:08 [derf]
juberti: Generally it seems kind of ugly.
02:29:18 [derf]
ekr: I'm not making a general statement.
02:29:28 [derf]
juberti: I'm thinking we could generate some kind of HMAC...
02:29:40 [derf]
ekr: We could do that too, and allow any previous ones to be acceptable...
02:29:53 [ekr]
resolved: setLocalDescription() only succeed with the result of the most recent CreateOffer()
02:30:03 [ken]
ken has joined #webrtc
02:30:16 [derf]
juberti: And if someday it turns out there's a scenario where this matters, then it's trivially fixable.
02:30:24 [ekr]
implementatons may generate the same ufrag/password repeatedly with multiple CreateOffers as long as there is no SetLocalDescription() has been called repeatedly
02:30:31 [derf]
stefanh: How could you know if SetLocal comes from that CreateOffer or it's something you just generated.
02:30:35 [derf]
ekr: Because we memorize it.
02:30:49 [derf]
ekr: It's an ICE security requirement to only accept ufrags and passwords that were generated interally.
02:30:57 [derf]
stefanh: But you could also change lots of other stuff in the SDP.
02:31:01 [derf]
ekr: Lots of stuff, but not this.
02:31:11 [derf]
martin_: Passwords, maybe not, but ufrags...
02:31:21 [derf]
martin_: Ufrags, you can't change them, but passwords, maybe...
02:31:29 [adam]
s/maybe not/maybe/
02:31:49 [derf]
fluffy: What you're really getting at here is that we should use DTLS and not ICE for consent.
02:31:57 [derf]
martin_: You're about 3 seconds too slow, I'm about to hit send on the e-mail.
02:32:00 [derf]
ekr: Heartbeat?
02:32:01 [derf]
martin_: Yeah.
02:32:08 [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
02:32:08 [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].
02:32:17 [derf]
adam: JSEP currently has this as a big open issue.
02:32:48 [derf]
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.
02:33:05 [derf]
juberti: The other thing is that ICE restart restarts for all m-lines.
02:33:27 [derf]
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.
02:33:33 [derf]
ekr: If it fails, what are the O/A implications?
02:33:40 [derf]
juberti: The ICE restart? I'm going to talk about that.
02:33:56 [fluffy]
we are not on slide "ICE Restart Cutover"
02:34:02 [derf]
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.
02:34:03 [fluffy]
s/not/now/
02:34:22 [derf]
ekr: What about partial success? One m-line's on the new candidates, and one m-lines on the old candidates.
02:34:41 [derf]
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...
02:34:56 [derf]
martin_: The reporting of that is interesting...
02:35:03 [derf]
juberti: Yeah, I talk about that here.
02:35:13 [derf]
fluffy: Walk me though the use case were this happens.
02:35:33 [derf]
juberti: The main use case is you're in a call and some NAT falls over and some packet timer expires at 5 seconds.
02:35:50 [derf]
juberti: Then you make a new createOffer and stuff it into setLocal and are now gather new candidates.
02:36:23 [derf]
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.
02:36:30 [derf]
martin_: And this might only apply to some paths.
02:36:59 [derf]
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.
02:37:11 [derf]
jesup: You might also invoke this if the current path degrades to find a better path.
02:37:25 [derf]
juberti: Yup, this could happen in IP handover situations to, you walk out the front door and now you're on 3G.
02:37:38 [derf]
ekr: This sounds generally sound to me, but we need to walk through the various edge cases.
02:37:58 [derf]
ekr: The videos on candidate pairs from the first handshake and the audio's on pairs from the second handshake and vice vesa.
02:38:03 [derf]
ekr: What happens if things fail?
02:38:19 [derf]
ekr: In the simple case the whole thing fails. What happens if one component fails and one does not, how do I back out?
02:38:39 [derf]
hta: This sounds like something that's really IETF protocol, and I think we're more or less ready for a coffee break.
02:38:44 [derf]
juberti: Let me go over the last bullet.
02:38:58 [derf]
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.
02:39:08 [derf]
juberti: Since it's make-before-break you might still be partying on.
02:39:34 [derf]
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.
02:39:45 [derf]
juberti: Are there any salient points we want to capture for a sidebar?
02:40:10 [derf]
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.
02:40:19 [derf]
ekr: How does the controlled side know that he's completed?
02:40:29 [derf]
martin_: Because he's going to receive an updated offer...
02:40:33 [derf]
ekr: That's a reach.
02:40:59 [derf]
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.
02:41:09 [derf]
ekr: If you end up with default candidates you never get an updated offer.
02:41:30 [TonyKuo]
TonyKuo has joined #webrtc
02:41:32 [derf]
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.
02:41:45 [richt]
richt has joined #webrtc
02:41:49 [derf]
juberti: Though if someone told me there was something in the ICE spec that wasn't actually used for anything...
02:42:04 [derf]
juberti: I think the main thing is that if the gathering state changes that means you must be doing an ICE restart.
02:46:22 [kotakagi]
kotakagi has joined #webrtc
02:51:42 [Zakim]
-??P3
02:53:16 [chris]
chris has joined #webrtc
02:56:45 [Marcus_Altman]
Marcus_Altman has joined #webrtc
02:59:35 [rbarnes]
rbarnes has joined #webrtc
03:02:54 [fluffy]
we are ready to start
03:03:32 [yusuke_]
yusuke_ has joined #webrtc
03:03:36 [hta]
zakim, who is talking?
03:03:49 [Zakim]
-Wuzhou_middle.a
03:03:56 [Zakim]
hta, listening for 11 seconds I could not identify any sounds
03:05:10 [dom]
Zakim, call Wuzhou_middle
03:05:10 [Zakim]
ok, dom; the call is being made
03:05:11 [Zakim]
+Wuzhou_middle
03:05:49 [Zakim]
-Wuzhou_middle
03:07:10 [hta]
done.
03:07:18 [hta]
I don't hear anything, though.
03:07:37 [droh_]
droh_ has joined #webrtc
03:09:49 [Marcus_Altman]
Marcus_Altman has joined #webrtc
03:15:39 [JimBarnett]
zakim is silent
03:16:58 [ekr]
zakim, who is here?
03:16:58 [Zakim]
On the phone I see Jim_Barnett
03:16:59 [Zakim]
On IRC I see Marcus_Altman, droh_, yusuke_, rbarnes, chris, taocai, Travis_MSFT, JimBarnett, alexG, yahui, juberti, dom, mreavy, jinkyu_seong, jesup, adambe, stefanh, silvia1, hta,
03:16:59 [Zakim]
... robin, elagerway, ekr, burn, martin_, adam, frodek, fluffy
03:17:19 [ekr]
yes, but you are still echoing
03:18:37 [fluffy]
we will get zakim in
03:19:07 [Zakim]
+??P8
03:19:26 [stefanh]
Jim,
03:19:31 [stefanh]
do you hear us now
03:20:30 [rbarnes]
hi, i will be your scribe for this session
03:20:51 [rbarnes]
adam: first part of slides are OBE, due to discussion of justin's material
03:21:01 [adam]
http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf
03:21:21 [TonyKuo]
TonyKuo has joined #webrtc
03:21:24 [rbarnes]
slide: Other Resource Reservation (Codecs, Hardware)
03:21:29 [DanD]
DanD has joined #webrtc
03:21:52 [fluffy]
and it is slide #8
03:22:02 [rbarnes]
adam: input resources, trying to cover all the resources you might need here
03:22:35 [rbarnes]
... this get freed on the indicated conditions, not when the PC ends
03:22:42 [AndyF]
AndyF has joined #webRTC
03:22:45 [rbarnes]
ekr: well, if the PC is GCed
03:23:06 [rbarnes]
... also if the MediaStreamTrack gets GCed
03:23:21 [ken]
ken has joined #webrtc
03:23:36 [stephane]
stephane has joined #webrtc
03:23:39 [rbarnes]
fluffy: say you have a track assigned to a global variable, not to any PC
03:23:48 [rbarnes]
... so you're going to attach the video codec to the track, not to the PC
03:23:59 [rbarnes]
adam: talking about input resources (camera), not codecs
03:24:14 [rbarnes]
ekr: as long as any handle is available, and stop() has not been called, its' reserved
03:24:18 [rbarnes]
adam: exactly
03:24:34 [wuyan]
wuyan has joined #webrtc
03:24:59 [rbarnes]
adam: start the resource reservation when you addStream...
03:25:13 [rbarnes]
juberti: don't know at that point what resolutions, etc. you need
03:25:29 [rbarnes]
hta: may also need to differentiate encode/decode
03:25:33 [kotakagi]
kotakagi has joined #webrtc
03:25:38 [bo_hu]
bo_hu has joined #webrtc
03:25:44 [rbarnes]
ekr: suppose i have a hardware limit, when should the failure appear
03:25:49 [rbarnes]
juberti: createOffer
03:26:15 [rbarnes]
ekr: then it will not really be a recoverable error. if it occurs at addStream, then greater chance of being able to recover
03:27:02 [rbarnes]
jesup: there are always be constraints on capability
03:27:14 [Dan_Sun]
Dan_Sun has joined #webrtc
03:27:33 [rbarnes]
juberti: you could easily have an encoder that could do 2 streams, but only at certain resolutions
03:27:51 [rbarnes]
fluffy: suspect we're going to have a set of objects that map this stuff together
03:28:53 [Qiuling]
Qiuling has joined #webrtc
03:29:08 [rbarnes]
adam: on setRemoteDescription, they're telling us that we're going to receive a certain stuff...
03:29:29 [rbarnes]
ekr: think the implication is that creatOffer/createAnswer is where the reservation happens
03:30:08 [richt]
richt has joined #webrtc
03:30:23 [rbarnes]
adam: (summarizing) reservation lasts to the end of the callback closure
03:30:27 [richt]
richt has joined #webrtc
03:30:41 [ekr]
here is the relevant text
03:30:42 [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]
03:30:42 [ekr]
ICE user name fragment and password."
03:30:46 [rbarnes]
... conclusion whether we're doing something with addStream?
03:31:01 [rbarnes]
burn: why did we get to that conclusion?
03:31:14 [rbarnes]
ekr: there are cases where createOffer will fail that cannot be detected at addStream
03:31:27 [DanD]
DanD has joined #webrtc
03:31:29 [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
03:31:34 [rbarnes]
... therefore we need to handle errors at createOffer/createAnswer-time, not useful to also have it at addStream time
03:31:41 [gangLiang]
gangLiang has joined #webrtc
03:31:49 [ekr]
fluffy: would propose that we actually forbid the reservation to last beyon g the minimal time
03:32:00 [ekr]
because it encourages safe programming idioms
03:32:06 [rbarnes]
burn: conceptually, addStream just sets an internal variable, not until createOffer/Answer or setLocal/Remote that something interesting happens
03:32:22 [rbarnes]
juberti: adam mentioned there might be some other interesting uses, but those don't affect the application
03:32:34 [rbarnes]
adam: these resources are freed at the end of the closure
03:32:52 [rbarnes]
ekr: how do we get to closure on this question?
03:33:07 [rbarnes]
juberti: write up the case you just described, and look at where the errors get handled
03:33:16 [rbarnes]
fluffy: suggest adding this to the agenda for later
03:33:43 [rbarnes]
adam: strike "RemoveStream" from "freed by" bullet
03:33:48 [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
03:33:57 [fluffy]
action 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
03:33:57 [trackbot]
Error finding 'to'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
03:34:10 [ekr]
… said agenda item should be in the error handling part of the agenda
03:34:26 [ekr]
action stefan: 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
03:34:29 [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].
03:34:30 [rbarnes]
juberti: createOffer/setRemote is doing the reservation
03:34:52 [rbarnes]
... but if a stream goes away, you might need to create a new offer
03:35:07 [rbarnes]
adam: planning to propose adding a "negotiation needed"
03:35:19 [rbarnes]
juberti: not sure getting the codec back 50ms earlier is a big advantage
03:35:33 [rbarnes]
adam: you're saying the stop() doesn't really help, since your'e just going to re-negotiate
03:35:50 [rbarnes]
... and possible h/w issues are not in scope
03:36:19 [rbarnes]
... stop triggers negotiationNeeded, and the negotiation triggers releases / frees
03:36:37 [rbarnes]
juberti: reservations happen on create*, frees on set*Description
03:36:42 [rbarnes]
ekr: is this sufficiently clear in the spec?
03:36:46 [rbarnes]
adam: last slide
03:37:18 [rbarnes]
slide: Media Transmission and Reception
03:37:27 [rbarnes]
juberti: this is covered in JSEP
03:37:31 [rbarnes]
fluffy: +1
03:38:02 [rbarnes]
slide: Local Session State Rollback
03:38:19 [rbarnes]
adam: AFAICT, this is the only case where rollback is useful
03:38:52 [rbarnes]
... current version of JSEP says we do this with rollback, but doesn't say anything about the body
03:39:17 [rbarnes]
juberti: the proposal on this slide was what i had in mind
03:39:25 [richt]
richt has joined #webrtc
03:39:38 [rbarnes]
"Proposal: Use type of "rollback", sdp string ignored"
03:39:54 [rbarnes]
fluffy: do you have to pass the previous sdp
03:39:57 [rbarnes]
adam: no
03:40:06 [rbarnes]
fluffy: as long as you can only roll back once
03:40:23 [rbarnes]
ekr: can i roll back from stable?
03:40:28 [rbarnes]
adam: no, only from partial state
03:40:36 [rbarnes]
fluffy: and only roll back to the previous stable state
03:40:45 [jeff]
jeff has joined #webrtc
03:41:05 [rbarnes]
adambe: aren't we kind of abusing setLocalDescription by doing this? even in this group there's confusion about what to do here?
03:41:16 [rbarnes]
adam: could add a rollback() method...
03:41:25 [rbarnes]
juberti: but rollback has to happen for both local and remote
03:41:42 [rbarnes]
ekr: i argued for this design because the other side can force you into rollback
03:42:11 [rbarnes]
juberti: i came to the same conclusion, that this was better than having separate rollback methods
03:42:46 [AndyF]
q+ to say how about just doing suing a prior SDP and doing a state reset
03:42:59 [rbarnes]
jesup: the primary argument is what eke said, since you could send them the string and they would just do it
03:43:25 [rbarnes]
andybe: how about a more generalized "reset to prior state" mechanism
03:43:29 [rbarnes]
hta: no
03:43:43 [rbarnes]
... the more generalized the mechanism, the harder to tell what will happen
03:43:56 [rbarnes]
juberti: there's less validation that needs to occur
03:44:00 [tao_mobile]
tao_mobile has joined #webrtc
03:44:34 [rbarnes]
... harder to figure that out more generally
03:44:41 [rbarnes]
adambe: only use valid states
03:45:45 [rbarnes]
... if you lose a state, how do you know the past state is valid
03:45:53 [rbarnes]
fluffy: you have to be ready to receive both the last and the new valid
03:46:00 [rbarnes]
adam: so the rollback just deletes the future state
03:46:25 [rbarnes]
jesup: making an API that implies that you can roll back to anywhere will promise something you can't do
03:46:32 [rbarnes]
fluffy: and you'll never map it to SIP
03:46:49 [rbarnes]
adam: if you're in stable, and someone tries to roll back, it will fail
03:47:33 [rbarnes]
fluffy: i think a better way to think about is to discard any changes since previous stable
03:47:38 [rbarnes]
rbarnes: abort the negotiation
03:47:45 [rbarnes]
juberti: adam's proposal is the cleanest option
03:48:01 [rbarnes]
... being able to roll back a remote offer is a good ida
03:48:05 [rbarnes]
s/ida/idea
03:48:21 [rbarnes]
jesup: call setRemoteDescription, but you're unhappy with the new streams
03:49:10 [rbarnes]
martin_: setLocal is the tranition point
03:49:42 [rbarnes]
burn: one of the reasons this is good is that a peer can send you this supposed SDP blob
03:49:54 [rbarnes]
... are there cases where createOffer or createAnswer would create rollback?
03:50:30 [rbarnes]
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
03:50:53 [rbarnes]
adam: that's not the question
03:51:31 [rbarnes]
ekr: suggested case: what happens if i do setRemote, and i can't process all the stuff you want to send
03:51:41 [rbarnes]
adam: there's an error callback for that
03:52:07 [fluffy]
did you guys get an answer to the question you asked ?
03:52:43 [rbarnes]
burn: fine without it being that way
03:53:03 [rbarnes]
jesup: we talked about rollback after a setRemote, because you have to make the other side do it
03:53:12 [rbarnes]
adam: that's an application-level thing
03:53:36 [rbarnes]
... ignore next slide
03:53:52 [rbarnes]
ekr: what happens now if you send me a description i cannot possibly process
03:53:59 [rbarnes]
adam: you get an error callback
03:54:00 [rbarnes]
juberti: yes
03:54:14 [rbarnes]
ekr: so it's not just malformed that triggers the error, can also be "i can't process that"
03:54:26 [rbarnes]
adam: probably need a class of error for "i can't process that"
03:54:42 [rbarnes]
s/adam/ekr/
03:54:46 [Yan]
Yan has joined #Webrtc
03:55:05 [rbarnes]
ekr: but unrecognized codecs might be different from codecs you know, but can't proess
03:55:15 [rbarnes]
s/proess/process
03:55:30 [TonyKuo_]
TonyKuo_ has joined #webrtc
03:55:33 [rbarnes]
jesup: but in that case, should it fail, or succeed partially
03:55:41 [rbarnes]
adam: in the latter case, the app could decide to roll back
03:56:10 [rbarnes]
stefan: could succeed, and app could use stats to detect that no packets are flowing
03:56:32 [rbarnes]
... added a topic for error handling discussion
03:56:46 [rbarnes]
juberti: added a state here, "might be less than you wanted"
03:57:01 [feross]
feross has joined #webrtc
03:57:05 [fluffy]
Moving on to slide "Requesting Partial Offers" - slide # 14
03:57:29 [adambe]
spec says: The setLocalDescription() method instructs the RTCPeerConnection to apply the supplied RTCSessionDescription as the local description."
03:57:37 [adambe]
that's not true anymore then
03:57:49 [rbarnes]
slide: requesting partial offers
03:58:19 [rbarnes]
proposal: add "partial:true" constraint to createOffer
03:58:32 [rbarnes]
... if changes are more than can be done with partial, then send back a full offer
03:58:52 [rbarnes]
fluffy: is there a way in the initial O/A for both sides to indicate support for partial O/A
03:58:53 [rbarnes]
?
03:59:05 [rbarnes]
burn: this is less about making a partial offer than accepting a partial offer
03:59:09 [richt]
richt has joined #webrtc
03:59:21 [rbarnes]
fluffy: find it scary not to provide some standardized way to negotiate partial O/A
03:59:29 [rbarnes]
adam: thought this was an application layer thing
04:00:07 [rbarnes]
fluffy: do you have a better solution? this is a substantial mod to O/A, we should negotiate it in O/A
04:00:19 [rbarnes]
hta: negotiations to O/A should be negotiated above O/A
04:00:23 [TonyKuo__]
TonyKuo__ has joined #webrtc
04:00:24 [rbarnes]
adam: that's how we do bundle
04:00:44 [rbarnes]
... so this is an IETF level suggestion, the POF/PAN draft needs to do this
04:01:10 [rbarnes]
... then if it hasn't been negotiated, a request with "partial: true" will just never produce partial
04:01:20 [rbarnes]
hta: should be clear that the constraint can be ignored by the browser
04:01:36 [rbarnes]
jesup: if you take this and use it with current browsers, they'll ignore it anyway
04:01:44 [rbarnes]
burn: why does the application need to ask for the partial
04:01:49 [DanD_]
DanD_ has joined #webrtc
04:02:03 [rbarnes]
... if they negotiate needing to send partials, great. but then why does the app need to request it at any point?
04:02:16 [rbarnes]
adam: it's necessary if you negotiate it in the application layer
04:02:46 [rbarnes]
jesup: suggest by default negotiated in the SDP, let partial==true be the default, partial==false if you overwrite it
04:02:52 [richt]
richt has joined #webrtc
04:03:08 [rbarnes]
... if the application wants the full SDP, it can get it by forcing partial==false
04:03:28 [rbarnes]
juberti: having the output of createOffer be dependent on previous SDP makes me sad from an API perspective
04:03:36 [rbarnes]
adam: how would you discover this?
04:03:40 [rbarnes]
juberti: some property on the PC
04:03:41 [richt]
richt has joined #webrtc
04:03:58 [rbarnes]
jesup: why does the app need to care
04:04:12 [rbarnes]
juberti: might not be doing full SDP, might be munging diffs in JS
04:04:41 [rbarnes]
burn: what are the use cases, why does the app need to have partial or non-partial
04:04:52 [rbarnes]
adambe: do you have to handle glare in both cases?
04:04:54 [rbarnes]
adam: yes
04:05:15 [rbarnes]
juberti: concerned that if the app things it's going to get a partial and doesn't, that's bad
04:05:30 [rbarnes]
... likewise in the reverse
04:05:50 [rbarnes]
adam: you have apps right now that are doing SDP scraping, so if they get something not-SDP, they'll break
04:06:03 [rbarnes]
... they need to have a way to say "i'm willing to deal with partials"
04:06:25 [DanS]
DanS has joined #webrtc
04:06:26 [rbarnes]
jesup: that's only based on a need for backward compatibility with apps that scrape SDP
04:06:38 [rbarnes]
... but it does impose that request forevermore
04:06:41 [yan]
yan has joined #webrtc
04:06:52 [rbarnes]
adam: perhaps we could pass this into the PC constructor
04:07:06 [rbarnes]
juberti: if you expect a partial, you can get a full, but not vice versa
04:07:30 [rbarnes]
jesup: when i see something that will eventually be cruft, i want to get rid of them
04:07:38 [rbarnes]
juberti: this is way down on the list of potential cruft
04:08:05 [rbarnes]
adam: propose to put this in the PC constructor, not have something per createOffer
04:08:21 [rbarnes]
jesup: that would only impact things that need to change per message
04:08:41 [rbarnes]
burn: you're *never* guaranteed to get a partial anyway, so you're just saying "i know how to deal with partial"
04:08:45 [fluffy]
Dan , you boas our ears out in this room when you talk - any chance of getting a bit further from mic
04:09:19 [rbarnes]
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
04:09:27 [rbarnes]
adam: sort of back to what's on the slide
04:09:57 [rbarnes]
juberti: constructor constraint might be workable if we have a way to get the full offer
04:10:25 [rbarnes]
... case is you get an offerless SDP...
04:10:53 [richt]
richt has joined #webrtc
04:11:15 [TonyKuo]
TonyKuo has joined #webrtc
04:11:20 [rbarnes]
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
04:11:58 [rbarnes]
juberti: kind of feel like this is the cleanest way to go
04:12:07 [richt]
richt has joined #webrtc
04:12:10 [rbarnes]
ekr: what is the impact of POF/PAN on local/remoteDescription
04:12:14 [rbarnes]
adam: you get the full thing
04:13:03 [rbarnes]
stefan: what's the resolution?
04:13:28 [rbarnes]
adam: agreement that we will have a signal for this, put it in the POF/PAN draft
04:13:37 [rbarnes]
ACTION to adam to make the change to POF/PAN
04:13:37 [trackbot]
Error finding 'to'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
04:13:38 [hta]
action adambe: put initial negotiation of pof/pan support into the pof/pan draft
04:13:38 [trackbot]
Created ACTION-92 - Put initial negotiation of pof/pan support into the pof/pan draft [on Adam Bergkvist - due 2013-11-18].
04:14:28 [rbarnes]
juberti: is this global per PC, or local per message, or both?
04:14:31 [tao]
tao has joined #webrtc
04:14:52 [rbarnes]
... if we're going to have the fullFull constraint, would prefer to have it at the same level
04:15:01 [rbarnes]
... how do you know you can use this with the remote peer?
04:15:33 [rbarnes]
adam: if that attribute is absent, and someone asks for partial, then the browser just won't generate it
04:15:39 [rbarnes]
juberti: that's fine
04:15:50 [rbarnes]
[[ unanimous consent ]]
04:15:59 [martin_]
consent that it's on the createOffer
04:16:15 [rbarnes]
slide: Processing partial offers
04:16:47 [rbarnes]
martin_: and this will blow up if it gets something full?
04:17:23 [rbarnes]
... "this is not an answer for the offer i sent"
04:17:55 [rbarnes]
juberti: what about the case where there's enough changes that you need a full offer?
04:18:02 [rbarnes]
adam: then you trigger re-negotiation
04:18:15 [rbarnes]
martin_: not sure when you'll see a partial exchange trigger some consequences
04:18:18 [TonyKuo_]
TonyKuo_ has joined #Webrtc
04:18:58 [Zakim]
-??P8
04:19:41 [Zakim]
-Jim_Barnett
04:19:42 [Zakim]
UW_WebRTC()7:00PM has ended
04:19:42 [Zakim]
Attendees were Wuzhou_Middle, Wuzhou_middle.a, [IPcaller], Jim_Barnett
04:21:49 [richt]
richt has joined #webrtc
04:22:08 [richt]
richt has joined #webrtc
04:30:01 [richt]
richt has joined #webrtc
04:31:11 [ken]
ken has joined #webrtc
04:54:00 [kotakagi]
kotakagi has joined #webrtc
05:04:30 [kotakagi_]
kotakagi_ has joined #webrtc
05:29:40 [stefanh]
stefanh has joined #webrtc
05:31:34 [kotakagi]
kotakagi has joined #webrtc
05:32:54 [ken]
ken has joined #webrtc
05:34:21 [ken]
ken has joined #webrtc
05:36:16 [jinkyu_seong]
jinkyu_seong has joined #webrtc
05:37:19 [silvia]
silvia has joined #webrtc
05:38:33 [dom]
dom has joined #webrtc
05:45:13 [ken_]
ken_ has joined #webrtc
05:47:07 [alexG]
alexG has joined #webrtc
05:47:12 [stefanh]
start up after lunch was supposed to happen now - but there will be some delay FYI
05:47:25 [frodek]
frodek has joined #webrtc
05:52:47 [fluffy]
fluffy has joined #webrtc
05:52:47 [burn]
burn has joined #webrtc
05:53:24 [adambe]
adambe has joined #webrtc
05:53:26 [ekr]
ekr has joined #webrtc
05:53:30 [hta]
we have called in, but we are only hearing echo from ourselves
05:54:53 [fluffy]
can you guys at that end mute ?
05:55:18 [stefanh]
we're muted now
05:56:17 [fluffy]
thanks
05:56:22 [rbarnes]
rbarnes has joined #webrtc
05:56:45 [mreavy]
mreavy has joined #webrtc
06:00:23 [Marcus_Altman_]
Marcus_Altman_ has joined #webrtc
06:00:37 [juberti]
juberti has joined #webrtc
06:01:17 [hta]
dom, done.
06:01:38 [hta]
zakim says "this conference is restricted at this time.
06:02:13 [droh]
droh has joined #webrtc
06:02:49 [ken]
ken has joined #webrtc
06:03:27 [ken]
ken has joined #webrtc
06:04:08 [jcverdie_]
jcverdie_ has joined #webrtc
06:04:40 [ekr]
scribenick: ekr
06:04:51 [ekr]
zakim: who is here?
06:04:56 [fluffy]
http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf
06:04:57 [fluffy]
slide 17
06:04:59 [TonyKuo]
TonyKuo has joined #webrtc
06:05:30 [DanD]
DanD has joined #webrtc
06:05:31 [ekr]
rrsagent, draft minutes
06:05:31 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/11/11-webrtc-minutes.html ekr
06:05:46 [gangLiang]
gangLiang has joined #webrtc
06:06:07 [fluffy]
slide with title "Stream Pause/Unpause/Rejection/
06:06:08 [Leon]
Leon has joined #webrtc
06:06:08 [fluffy]
Removal"
06:06:34 [Leon]
Leon has joined #webrtc
06:06:44 [ekr]
abr: we used to think we could defer, unpause, etc.
06:06:51 [ekr]
… implementors want it
06:07:08 [ekr]
… can just be clearer about API
06:07:27 [taocai]
taocai has joined #webrtc
06:07:34 [ekr]
abr: slide 18
06:07:46 [bo_hu]
bo_hu has joined #webrtc
06:08:03 [ekr]
… to pause, set enabled=false, this paused media and starts renegotaition
06:08:16 [jy]
jy has joined #webrtc
06:08:22 [yw]
yw has joined #webrtc
06:08:32 [ekr]
juberti: we have three states, ended, paused, muted, but just two api points
06:08:33 [Zakim]
Zakim has left #webrtc
06:09:11 [dwshim]
dwshim has joined #webrtc
06:09:13 [ekr]
agreement that mute just turns off mic
06:10:16 [ekr]
discussion of events. is muted a response to an external button?
06:10:52 [ekr]
hta: muted is outside application control and enabled is inside application control
06:11:22 [TonuKuo]
TonuKuo has joined #webrtc
06:11:23 [ekr]
jesup: where should this be tied to?
06:11:28 [yahui]
yahui has joined #webrtc
06:11:56 [ekr]
fluffy: what about a track going to two places?
06:12:10 [richt]
richt has joined #webrtc
06:12:12 [yusuke_]
yusuke_ has joined #webrtc
06:13:10 [jeromemarcon]
jeromemarcon has joined #webrtc
06:13:51 [ekr]
general consensus we need more knobs
06:14:38 [ekr]
jesup lists some
06:14:41 [TonyKuo]
TonyKuo has joined #Webrtc
06:14:59 [ekr]
fluffy draws diagram
06:15:25 [feross]
feross has joined #webrtc
06:15:59 [jmr]
jmr has joined #webrtc
06:16:11 [ekr]
1. Camera with hardware control to go black
06:16:21 [ekr]
2. Application control to do (black, silence, frozen frame)
06:16:25 [ekr]
3. Stop sending packets
06:17:59 [ekr]
[stopping transcription]
06:19:04 [silvia1]
silvia1 has joined #webrtc
06:19:37 [AndyF]
AndyF has joined #webrtc
06:19:48 [AndyF]
AndyF has left #webrtc
06:19:57 [AndyF]
AndyF has joined #webRTC
06:20:05 [ekr]
Topic 1: hw mute button
06:20:36 [ekr]
This is read-only
06:21:16 [ekr]
Topic 2: freeze/black from the application. consensus that black/silence was fine
06:21:19 [ekr]
zakim, who is here?
06:21:26 [ekr]
dom: apparently not
06:22:06 [ekr]
mt: what about removing the stream?
06:22:34 [ekr]
fluffy: permanent vs. temporary stream removal
06:23:12 [stephane]
stephane has joined #webrtc
06:24:59 [tao]
tao has joined #webrtc
06:26:01 [ekr]
various comments about how much you need to send dummy data even when not sending content in order to keep bandwidth estimation working
06:26:43 [ekr]
abr: people with gateways want to tell the gatewy stream is going inactive
06:27:44 [ekr]
… they want signaling to indicate it
06:27:52 [Tiffany]
Tiffany has joined #webrtc
06:31:25 [ekr]
ekr got lost
06:31:38 [ekr]
and cullen has agreed to write down his view
06:32:02 [fluffy]
RTP RTCP m-line
06:32:03 [fluffy]
Send Black Black yes yes
06:32:04 [fluffy]
no RTP no yes yes
06:32:05 [fluffy]
end no yes zero
06:32:29 [fluffy]
take two
06:32:30 [fluffy]
RTP RTCP m-line
06:32:31 [fluffy]
Send Black Black yes yes
06:32:32 [fluffy]
no RTP no yes yes
06:32:33 [fluffy]
end no no zero
06:35:24 [fluffy]
Need to turn the audio on and off immediately, and no RTP can not happen super quick
06:35:51 [ken]
ken has joined #webrtc
06:36:10 [Tiffany]
Tiffany has joined #webrtc
06:36:29 [ken]
ken has joined #webrtc
06:36:59 [ekr]
proposal. enabled --> send black but still send RTP
06:37:39 [ekr]
"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."
06:38:00 [fluffy]
slides are http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf
06:38:08 [fluffy]
slide number 18
06:41:22 [feross]
feross has joined #webrtc
06:41:41 [ekr]
<new thing> --> stop sending RTP
06:45:05 [jib]
jib has joined #webrtc
06:45:28 [ekr]
<new thing> also causes onnegotiationneeded on the sender side
06:45:40 [TonyKuo_]
TonyKuo_ has joined #webrtc
06:47:19 [ekr]
on the receiver side, .enabled = false causes the output to be black
06:47:42 [yw_]
yw_ has joined #webrtc
06:48:01 [ekr]
if the other side stops sending RTP, the track gets mute set
06:49:14 [yw]
yw has joined #webrtc
06:49:50 [ken]
ken has joined #webrtc
06:51:23 [ekr]
juberti: the names are messed up but not clear we can fix it
06:51:53 [DanS]
DanS has joined #webrtc
06:52:37 [tao]
tao has joined #webrtc
06:53:35 [richt]
richt has joined #webrtc
06:54:18 [stefanh]
we lost seattle
06:54:30 [richt]
richt has joined #webrtc
06:54:38 [fluffy]
ok
06:54:46 [fluffy]
we noticed and trying to get you back
06:54:46 [burn]
we lost both call and hangouts from you
06:54:50 [stefanh]
no phone, no hangout
06:55:03 [stefanh]
thanks!
06:55:06 [burn]
you will need to re-call
06:55:21 [fluffy]
HTA working on calling
06:55:31 [ken_]
ken_ has joined #webrtc
06:55:54 [TonyKuo]
TonyKuo has joined #Webrtc
06:56:48 [burn]
we are still connected to hangouts (and were to the phone as well before we hung up), so this appears to be on your end
06:57:13 [fluffy]
Dom can you guys hang up so we can reinvade you
06:57:37 [fluffy]
ok - we are trying to redial
06:57:52 [fluffy]
we are seeing you
06:57:56 [burn]
we see you in hangouts
06:57:58 [burn]
waiting for the call
06:59:14 [DanD]
DanD has joined #webrtc
06:59:27 [hta]
I have called again, but I get no sound from your phone
06:59:37 [hta]
try unmuting in the hangout..
06:59:57 [ekr]
no.
07:00:01 [ekr]
we cannot hear you
07:04:04 [richt]
richt has joined #webrtc
07:04:23 [richt]
richt has joined #webrtc
07:05:08 [DanS]
DanS has joined #webrtc
07:07:19 [yusuke__]
yusuke__ has joined #webrtc
07:10:49 [yusuke]
yusuke has joined #webrtc
07:11:13 [jehoochen]
jehoochen has joined #webrtc
07:11:27 [jehoochen]
jehoochen has left #webrtc
07:12:15 [martin_]
I know for sure that removing a stream or ending it have the same net effect
07:13:41 [TonyKuo]
TonyKuo has joined #webrtc
07:14:20 [martin_]
conclusion there was that removing or ending the track will cause the msid to disappear from signaling
07:15:36 [DanS]
DanS has joined #webrtc
07:17:51 [fluffy]
thanks - got you that time
07:18:49 [fluffy]
http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf slide 20
07:23:05 [richt]
richt has joined #webrtc
07:23:49 [richt]
richt has joined #webrtc
07:24:06 [TonyKuo_]
TonyKuo_ has joined #webrtc
07:25:29 [richt]
richt has joined #webrtc
07:25:55 [tao]
tao has joined #webrtc
07:26:57 [ijongcheol]
ijongcheol has joined #webrtc
07:28:29 [ken]
ken has joined #webrtc
07:28:57 [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
07:29:35 [martin_]
If you then treat the stream association for each track as a property of each track, easy.
07:30:13 [richt]
richt has joined #webrtc
07:35:29 [HJ_lee]
HJ_lee has joined #webrtc
07:36:18 [ken]
ken has joined #webrtc
07:38:05 [tao]
tao has joined #webrtc
07:46:58 [richt]
richt has joined #webrtc
07:47:52 [richt_]
richt_ has joined #webrtc
07:48:00 [ken]
ken has joined #webrtc
07:48:35 [richt]
richt has joined #webrtc
07:49:58 [yusuke]
yusuke has joined #webrtc
07:50:38 [richt]
richt has joined #webrtc
07:51:43 [ijongcheol]
ijongcheol has joined #webrtc
07:56:27 [tao]
tao has joined #webrtc
07:56:37 [yusuke_]
yusuke_ has joined #webrtc
07:57:37 [ijongcheol]
ijongcheol has joined #webrtc
08:00:18 [minami]
minami has joined #webrtc
08:01:02 [minami]
minami has left #webrtc
08:01:32 [ekr]
It was hard to follow here too
08:02:56 [rbarnes]
rbarnes has joined #webrtc
08:04:36 [kotakagi]
kotakagi has joined #webrtc
08:05:45 [fluffy]
http://www.w3.org/2011/04/webrtc/wiki/images/4/40/W3C-sdp-oa.pdf slide 23
08:06:03 [stephane]
stephane has joined #webrtc
08:06:06 [fluffy]
we need action to do what was on the above slide 23 - it seems people agree with thqt
08:06:08 [yw]
yw has joined #webrtc
08:07:27 [ekr]
action fluffy: make addIceCandidate queued
08:07:27 [trackbot]
Created ACTION-93 - Make addicecandidate queued [on Cullen Jennings - due 2013-11-18].
08:08:12 [Leon]
Leon has joined #webrtc
08:08:31 [ijongcheol]
ijongcheol has joined #webrtc
08:08:46 [hta]
action justin: prepare slides for Tuesday on Stop() versus Removestream()
08:08:46 [trackbot]
Created ACTION-94 - Prepare slides for tuesday on stop() versus removestream() [on Justin Uberti - due 2013-11-18].
08:10:37 [fluffy]
http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0005.html
08:10:55 [dom]
ScribeNick: adambe
08:11:02 [Tony]
Tony has joined #webrtc
08:12:23 [adambe]
burn: you might want to look at the webrtc spec as we walk through the email
08:12:39 [dom]
Topic: Error handling
08:12:59 [rbarnes]
drumbeat.stop()
08:14:11 [dom]
-> http://dev.w3.org/2011/webrtc/editor/webrtc.html WebRTC editors draft
08:15:27 [dom]
-> http://dev.w3.org/2011/webrtc/editor/archives/20130830/webrtc.html Aug 30 draft
08:15:59 [adambe]
burn: we're ready here
08:17:13 [adambe]
... I've gone throgh the document and noted where we have "throw a TBD error" or where an error is reported
08:17:21 [TonyKuo]
TonyKuo has joined #webrtc
08:19:08 [ken]
ken has joined #webrtc
08:19:41 [adambe]
... on topic RTCPeerConnection, section 4.3.1
08:19:56 [ijongcheol]
ijongcheol has joined #webrtc
08:20:00 [adambe]
... action to remove bullet 5
08:20:01 [Tonykuo]
Tonykuo has joined #webrtc
08:20:35 [adambe]
... that is bullet 5 in the third algorithm
08:21:33 [adambe]
... additional actions: remove bullet 4 in the some algorithm as well as "issue 1"
08:22:26 [Marcus_Altman__]
Marcus_Altman__ has joined #webrtc
08:22:51 [DanD]
DanD has joined #webrtc
08:22:51 [adambe]
... next topic: addIceCandidate(), section 4.3.2.3
08:22:55 [bo_hu]
bo_hu has joined #webrtc
08:26:20 [ijongche_]
ijongche_ has joined #webrtc
08:29:14 [richt]
richt has joined #webrtc
08:29:21 [ywu]
ywu has joined #webrtc
08:31:39 [BoYang]
BoYang has joined #WebRTC
08:33:13 [adambe]
... proposed solution: the addIceCandidate() method should throw "InvalidCandidate" and "InvalidMediaIndex" depending on the error
08:33:42 [yahui]
yahui has joined #webrtc
08:33:52 [adambe]
... "InvalidMediaIndex" should be "InvalidMidIndex"
08:34:11 [Tony]
Tony has joined #Webrtc
08:34:37 [adambe]
... the method should fire the error callback instead of throwing
08:36:01 [adambe]
... the line about "SyntaxError" should also be removed
08:39:08 [adambe]
... the "SyntaxError" should be moved the the RTCIceCandidate() constructor
08:39:10 [adambe]
... next topic: addStream(), section 4.3.2.3
08:39:48 [adambe]
burn: I think the exception is fine
08:41:20 [adambe]
... the WebRTC document needs to be updated to use the new Constrainable concepts
08:41:59 [richt]
richt has joined #webrtc
08:45:53 [adambe]
... 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
08:47:40 [Tony]
Tony has joined #Webrtc
08:47:56 [Dan]
Dan has joined #webrtc
08:48:06 [hta]
action dan: Go through all usage of constraints in WebRTC and figure out how to deal with them (or find someone else to do that)
08:48:06 [trackbot]
'dan' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dburnett, ddruta, dromasca).
08:48:35 [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)
08:48:36 [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].
08:49:27 [adambe]
burn: next topic: close(), section 4.3.2.3
08:50:17 [adambe]
... conclusion, remove the throw
08:51:16 [adambe]
... on topic addStream(), section 4.3.2.3, remove issue 3
08:51:34 [adambe]
... new topic: createAnswer(), section 4.3.2.3
08:51:44 [richt]
richt has joined #webrtc
08:51:56 [adambe]
... let's skip the issues with Constrainable
08:53:47 [Marcus_Altman__]
Marcus_Altman__ has joined #webrtc
08:54:55 [adambe]
... conclusion: if the SDP generation process fails, the error callback should be called with "GenericFailure"
08:55:20 [adambe]
... next topic: createOffer(), section 4.3.2.3
08:55:32 [adambe]
... same conclusion as createAnswer()
08:55:39 [kotakagi]
kotakagi has joined #webrtc
08:55:47 [adambe]
... next topic: removeStream(), section 4.3.2.3
08:56:51 [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".
08:59:47 [adambe]
... conclusion: keep the exception
09:00:08 [adambe]
burn: next topic: setLocalDescription() , section 4.3.2.3
09:01:22 [adambe]
... conclusion: keep the exception
09:01:23 [richt]
richt has joined #webrtc
09:02:52 [ywu]
ywu has joined #webrtc
09:04:17 [juberti]
For IceRestart:
09:04:52 [yusuke]
yusuke has joined #webrtc
09:05:13 [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".
09:05:16 [adambe]
... conclusion (cont.): juberti will send text on the ice part (paragraph 2)
09:07:16 [ijongcheol]
ijongcheol has joined #webrtc
09:07:52 [silvia]
silvia has joined #webrtc
09:08:15 [yusuke__]
yusuke__ has joined #webrtc
09:08:31 [gangliang]
gangliang has joined #webrtc
09:09:55 [adambe]
... conclusion (cont.): lets keep InvalidSessionDescriptionError
09:10:06 [Tony]
Tony has joined #Webrtc
09:11:16 [ijongche_]
ijongche_ has joined #webrtc
09:12:13 [richt]
richt has joined #webrtc
09:12:29 [adambe]
... conclusion (paragraph 4): needs more discussion
09:12:54 [ekr]
action: fluffy to do s/roll back/rollback/g
09:12:54 [trackbot]
Created ACTION-96 - Do s/roll back/rollback/g [on Cullen Jennings - due 2013-11-18].
09:13:00 [adambe]
... next topic: setRemoteDescription(), section 4.3.2.3
09:13:19 [richt]
richt has joined #webrtc
09:14:21 [Tony]
Tony has joined #Webrtc
09:15:46 [richt]
richt has joined #webrtc
09:15:59 [yusuke]
yusuke has joined #webrtc
09:16:27 [ijongcheol]
ijongcheol has joined #webrtc
09:17:27 [adambe]
... conclusion: fluffy will fix the reference
09:17:44 [bo_hu]
bo_hu has joined #webrtc
09:18:21 [adambe]
... conclusion (cont.): martin_ will write a proposal
09:18:41 [adambe]
martin_: proposal is "send black"
09:19:10 [ywu_]
ywu_ has joined #webrtc
09:19:26 [adambe]
burn: next topic: updateIce(), section 4.3.2.3
09:20:09 [ywu]
ywu has joined #webrtc
09:21:14 [adambe]
... skip the constrainable part (we've already got an action on that)
09:22:03 [ijongcheol]
ijongcheol has joined #webrtc
09:22:21 [Tony]
Tony has joined #Webrtc
09:24:09 [kotakagi_]
kotakagi_ has joined #webrtc
09:24:21 [richt_]
richt_ has joined #webrtc
09:24:34 [adambe]
... conclusion: the method does not have to be queued
09:26:15 [adambe]
burn: are we done with updateIce?
09:28:20 [richt]
richt has joined #webrtc
09:29:38 [ijongcheol]
ijongcheol has joined #webrtc
09:31:12 [richt_]
richt_ has joined #webrtc
09:32:04 [martin_]
Adding ice servers takes effect right away
09:32:25 [martin_]
removing doesn't come into effect until the next time candidate gathering commences (i.e., ICE restart)
09:32:45 [martin_]
the candidate filter can't be made more restrictive
09:33:23 [martin_]
attempting to make the filter more restrictive generates an error (exception)
09:34:10 [martin_]
justin suggested that this could be silent and the restriction could be applied at the next restart
09:34:32 [martin_]
ekr points out that this is a security feature and suppressing what is bad behaviour would be not good
09:35:10 [richt]
richt has joined #webrtc
09:37:01 [martin_]
if you want to make more restrictive filters on candidates, create a new RTCPeerConnection
09:37:40 [stephane]
stephane has joined #webrtc
09:39:31 [ijongcheol]
ijongcheol has joined #webrtc
09:40:50 [dom]
RRSAgent, draft minutes
09:40:50 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/11/11-webrtc-minutes.html dom
09:40:59 [stefanh]
actions: https://www.w3.org/2011/04/webrtc/track/actions/open
09:41:03 [martin_]
ACTION for EKR: 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
09:41:03 [trackbot]
Error finding 'for'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
09:41:06 [dom]
-> http://www.w3.org/2013/11/11-webrtc-minutes.html#ActionSummary Today's action items
09:41:13 [martin_]
ACTION EKR: 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
09:41:13 [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].
09:41:26 [dom]
RRSAgent, draft minutes
09:41:26 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/11/11-webrtc-minutes.html dom
09:42:34 [christer]
christer has joined #webrtc
09:44:09 [taocai]
taocai has left #webrtc
09:50:16 [richt]
richt has joined #webrtc
09:50:37 [silvia]
silvia has joined #webrtc
09:50:43 [richt_]
richt_ has joined #webrtc
09:55:42 [richt__]
richt__ has joined #webrtc
09:56:46 [ijongcheol]
ijongcheol has joined #webrtc
09:57:32 [silvia]
silvia has joined #webrtc
09:59:24 [richt]
richt has joined #webrtc
10:00:19 [dong]
dong has joined #webrtc
10:00:29 [dong]
dong has left #webrtc
10:04:23 [hta]
hta has joined #webrtc
10:05:32 [frodek]
frodek has joined #webrtc
10:07:03 [frodek]
frodek has left #webrtc
10:09:46 [richt_]
richt_ has joined #webrtc
10:16:44 [ken]
ken has joined #webrtc
10:22:18 [silvia1]
silvia1 has joined #webrtc
10:22:35 [richt]
richt has joined #webrtc
10:23:10 [richt_]
richt_ has joined #webrtc
10:29:06 [richt__]
richt__ has joined #webrtc
10:56:57 [jib]
jib has joined #webrtc
11:27:16 [ken]
ken has joined #webrtc
11:55:46 [adam]
adam has joined #webrtc
12:55:34 [wolfgangbeck01]
wolfgangbeck01 has joined #webrtc
13:03:14 [wolfgangbeck01]
wolfgangbeck01 has left #webrtc
13:06:30 [adam]
adam has joined #webrtc
13:45:09 [kotakagi]
kotakagi has joined #webrtc
14:02:15 [chris]
chris has joined #webrtc
14:07:19 [adam]
adam has joined #webrtc
14:20:49 [ijongcheol]
ijongcheol has joined #webrtc
14:29:31 [awclin]
awclin has joined #webrtc
14:39:10 [silvia]
silvia has joined #webrtc
14:45:23 [silvia1]
silvia1 has joined #webrtc
14:47:38 [lgombos_]
lgombos_ has joined #webrtc
14:56:27 [ken]
ken has joined #webrtc
15:08:03 [silvia]
silvia has joined #webrtc
15:14:50 [ken]
ken has joined #webrtc
15:18:03 [adam]
adam has joined #webrtc
15:23:06 [matteo]
matteo has joined #webrtc
15:42:11 [chris]
chris has joined #webrtc
15:42:56 [mreavy]
mreavy has joined #webrtc
16:20:47 [chris]
chris has joined #webrtc
16:41:24 [hta]
hta has joined #webrtc
16:43:16 [jesup]
jesup has joined #webrtc
16:57:13 [silvia]
silvia has joined #webrtc
18:29:53 [adam]
adam has joined #webrtc
18:50:07 [lgombos]
lgombos has joined #webrtc
19:32:55 [lgombos]
lgombos has joined #webrtc
19:40:36 [adam]
adam has joined #webrtc
19:51:55 [hta]
hta has joined #webrtc
19:59:01 [hta1]
hta1 has joined #webrtc
20:13:56 [ken]
ken has joined #webrtc
20:32:55 [feross]
feross has joined #webrtc
20:36:08 [lgombos_]
lgombos_ has joined #webrtc
20:51:43 [hta]
hta has joined #webrtc
20:52:00 [lgombos]
lgombos has joined #webrtc
21:42:04 [ken]
ken has joined #webrtc
22:24:35 [ken]
ken has joined #webrtc
22:26:10 [silvia]
silvia has joined #webrtc
22:41:23 [adam]
adam has joined #webrtc
23:08:08 [lgombos]
lgombos has joined #webrtc
23:43:37 [hta]
hta has joined #webrtc
23:44:49 [lgombos_]
lgombos_ has joined #webrtc