Wednesday, 1 February 2012< ^ >
martin.thomson has set the subject to: RTCWEB WG
Room Configuration

[00:00:10] <> Same goes for direction attribute... whatever you put on m-lines affects all SSRC....
[00:00:41] <> Harald: All the videos have to live within the set of negotiated codecs for that m-line. If multiple codecs are permitted you can use them, but you cannot say that you want to use this codec for this and that codec for that.
[00:00:45] <> Christer: Everyone has to be prepared to receive what you have negotiated.
[00:00:52] Jonathan Lennox leaves the room
[00:00:57] <> Legacy interop which comes up... if you send an offer like this....
[00:01:02] <> Cullen: It won't work!
[00:01:13] <> Christer: He will throw it away and send something back!
[00:01:23] <> In SIP you'd use an option tag and a fallback....
[00:02:11] <> Harald: For legacy interop case, either legacy can accept multiple SSRCs or it's not. If not, it will fail anyway. Interesting case is legacy with multiple SSRCs, which needs information in MSID tag to sort them out.
[00:02:30] <> Harald: So you understand concept of media stream but can't handle MSID tag.
[00:03:05] <> Harald: Is there anything in that category?
[00:03:10] <> Cullen: Video mixers
[00:03:34] <> Cullen: Are you saying browser has to know before generating offer if it is talking to legacy?
[00:03:51] <> Harald: App has to know if it cares about legacy.
[00:04:00] <> Cullen: If I call JSEP createOffer, what will it do?
[00:04:23] <> Harald: If you add two video channels where will it put the other one? It won't work. So app has to know what to do.
[00:04:38] <> In JSEP what you don't understand, you throw away, so in theory it will do no harm.
[00:04:53] <> Christer: It is written that way... but if you send me an offer with two SSRCs...
[00:05:06] <> I'm a piece of equipment that doesn't understand SSRC attribute....
[00:05:14] <> Harald: Can you take two SSRCs on one m-line?
[00:05:33] <> Christer: You sent offer with m=audio with two SSRCs... I send offer back without SSRC attribute, only m=audio. What do you do?
[00:05:44] Jonathan Lennox joins the room
[00:05:47] <> Harald: I would send two audio streams. What will you do about it?
[00:06:23] <> Magnus: As Chair I want to comment.. main goal is to figure out if it is a reasonable proposal... then throw it over the wall to MMUSIC. Can WG focus on what we're trying to accomplish.
[00:06:47] <> Aaron Rosenberg: Should two cameras show up in two media streams or one media stream with two tracks? What would the effect of the choice be?
[00:07:04] <> Harald: Way spec is currently written... when they are one media stream they are played out synchronously.
[00:07:46] <> Aaron Rosenberg: If I've got two cameras with different hardware encoding c apabilities and different codecs, do they have to be separate streams? No. Do they have to be on separate m-lines? You'd have to declare rtpmap attributes for both codecs.
[00:08:09] <> Jonathan Lennox: Am on side of multiple SSRCs. m-lines are bi-directional whereas as mediastream tracks are uni-directional.
[00:08:27] <> JL; Question I have: why doesn't WebEX default to mute on???
[00:08:59] <> JL: If it's a useful semantic it's useful outside of RTCWEB... explain what semantics are so non-RTCWEB web stuff can take advantage.
[00:09:44] <> Harald: RTP has a statement if two things have same CNAME they should be synchronous.... first proposal was to use CNAME for the purpose... but can't do that because CNAME identifies an end-user... one end-user could send more than one media stream.
[00:10:04] <> Jonathan Lennox: Single end-user could send multiple streams that aren't synchronized?
[00:10:07] <> Harald: Yes.
[00:11:33] <> Harald: mediastreamTrack can have 7 audio streams.... to make audio stream 3 louder you have to have some agreement on how to identify a track.
[00:11:46] <> If sender tells you to play track 3 louder... how do you know what he means???
[00:12:32] <> Hadriel: Chair said it goes to MMUSIC... do think that interop issue does matter... we have to explain if we need interop. What happens if you get an answer that doesn't include this?
[00:12:43] <> What breaks if I (SBC) deletes extra lines in the middle?
[00:13:08] <> Harald: Suggest that all the SSRCs that you don't have an MSID for get dumped into a default category.
[00:14:24] <> Hadriel: If you do have multiple m-lines if we offer bundle, answer might not use bundle.
[00:15:12] <> Harald: question about mediastreamTracks.... one consequence is that I asked for removeTrack to go away....
[00:15:23] <> Harald: otherwise this would require signaling every time you remove a track.
[00:15:41] <> harald: we can still end a track....
[00:16:00] <> Harald: We need to discuss this in WEBRTC tommorrow.
[00:16:12] <> Ted: Now we go from JSEP to Randall Jessup.....
[00:16:38] <> Randall up for WebRTC Data Channels...
[00:16:53] <> Ted: Anyone object to us kicking this to MMUSIC.
[00:17:03] <> Cullen: Who understands what this solves?
[00:17:25] <> Some hands go up.
[00:17:41] <> Back to Randall. draft-jesup-rtcweb-data-02.
[00:18:02] <> RTCWEB is not taking a position... no objection to send it to MMUSIC....
[00:18:13] <> Cullen: whether the group objects isn't relevant...
[00:18:22] <> Ted: Don't record anything about this so we can move on.
[00:18:36] <> Randall Jesup from Mozilla.
[00:18:47] <> Presentation looks similar to Taipei. No time for discussion there.
[00:19:01] <> Updated from IETF 82 presentaiton.
[00:19:03] burn leaves the room
[00:19:15] burn joins the room
[00:19:30] <> Uses of data channels.... side channels during 'call' (mute status); chat; file transfer; app synch; games; whiteboard, etc.
[00:19:49] <> Data Channel Requirements... multiple data channels.
[00:20:16] <> Stefan Hakansson: Couldn't derive these requirements from the use cases... not saying they are invalid.. but where do these reqts come from?
[00:21:10] <> Reqts: reliable and unreliable... datagram ans tream.. MUST be congestion controlled, MUST be secure, quality open-source userland implementation.
[00:21:20] <> Stefan: How much do we gain from unreliable data channels?
[00:21:37] <> Randall: Critical to realtime apps... otherwise would have to wait for retries.
[00:21:53] <> Stefan: Not really true... can discard if it arrives too late.
[00:22:20] <> Randall:
[00:22:40] <> Reliable channel would hide from app that data hand't arrive.
[00:22:48] <> Mathew: dont' confuse reliable delivery with in-order delivery.
[00:23:00] <> Randall: am assuming reliable in-order delivery.
[00:23:44] <> Justin: going down a familiar rathole. Need unreliable, which you can't do with websockets. Do you need multiple data channels within the browser or could you build this in JS?
[00:23:59] <> Can you build reliable, multiplexing, etc over a basic API for unreliable?
[00:24:36] <> Justin: Format of data within the data channel is app specific. Are we all agreed that these are the true requirements? As Stefan said, they don't derive from use cases.
[00:24:56] <> Randall: Can always add multiplexing layers....
[00:25:02] <> Mathew: And people will add them....
[00:25:11] <> Stefan Wenger: And people will love it!
[00:25:52] <> Randall Jesup: These are reqts I came up, we started from app... thought this was functionality necessary to address the need. Many ways you could implement this.
[00:27:06] <> EKR: necessary to have unreliable datagram transport....notion of reinventing reliable streams in JS gives me heebie-jeebies. I could live without multiplexing of multiple data streams.
[00:27:46] <> Michael? (Adobe): I think multiple datastreams are necessary...
[00:27:57] <> Randall: You can build anything on top of UDP....
[00:28:17] <> Michael: You want lower layer to take care of reliability because you want congestion control.
[00:30:13] <> Randall: Options slide. Pseudo TCP over UDP (reliable) + DCCP (unreliable) bother over DTLS-ICE-UDP
[00:30:38] <> DCCP user implementation available, but we don't know how good it is.
[00:30:48] Lars joins the room
[00:30:59] <Lars> this is the open source userland dccp implementation:
[00:31:06] <Lars> as i said, no idea how good this is
[00:31:08] <> DTLS-SCTP is specified... but SCTP-DTLS not currently specified.
[00:32:02] <> Pseudo-TCP-over-UDP (reliable) + DCCP (reliable)... Pros: well-known... Cons: two protocols needed.
[00:32:17] <rejzak> please consider those of us on the bridge and use the mike!
[00:33:05] <Lars> rejzak: sorry
[00:33:28] <> SCTP-DTLS-ICE-UDP or DTLS-SCTP-ICE-UDP: single kitchen-sink protocol...
[00:33:38] <> Ted: Hands mike to Randall Stewart.
[00:33:43] <> Turn on mike!
[00:34:39] <> Randall Steward: DTLS-SCTP works out there.. but thinking it would be possible to flip order.... Cisco funded effort to make it portable... shouldn't be hard to switch it around.
[00:35:01] <> Randall Jesup: SCTP-DTLS is no big deal, right? Yes.
[00:35:28] <> EKR: I concur. Once you get to the point where you can do SCTP over abstract ICE transport....
[00:37:23] <> Randal Jesup: Limitations on size of datagrams but SCTP-DTLS can use streams). Loss-based congestion control (but replaceable).
[00:42:26] <> Jonathan Lennox: Can you run TLS over SCTP/
[00:42:51] <> Randall Stewart: You don't want to... can't do unordered with TLS over SCTP.
[00:46:50] <> Justin: How do we handle large datagrams? Do you get an error or do you do reassembly?
[00:47:18] <> Randal: It is in the open issues. Aps are going to want to know that datagrams will fit onto the channel. Some are flexible, others are not.
[00:47:56] <> Current implementation of SCTP does reassembly by default. So we could enable larger datagrams.
[00:48:39] <> Randall Stewart: There is a downside to large messages... people have sent 100 MB messages... the way SCTP fragments, it will now block everything else while 100 MB gets through... have talked about new chunk to get around it.
[00:48:50] <> Randall Jesup: Would not suggest 100 MB datagrams.
[00:49:26] <> Justin: If you want true unreliable you want to expose the MTU to the application.
[00:50:42] <> Hadriel: To be clear, if you send something larger than MTU it is handled at SCTP... so not fragmentation within IP. So broken routers or NATs will see a full sized packets, routers don't do reassumbly, etc.
[00:52:10] <> Lars: Does the new impementation do MTU discovery?
[00:52:15] <> Randall STewart: Yes.
[00:52:24] <> Lars: DTLS-SCTP is the way to go here....
[00:52:57] <> Lars: Congestion control will be tricky.
[00:53:14] <> Progress since IETF 82... Updated userland SCTP released... Justin working on JS APIs.
[00:53:30] <> SCTP supporting pluggable congestion control.
[00:54:00] <> WAnt to avoid starving media channles while doing large data transfers.
[00:55:04] Bran, Cary leaves the room
[00:55:22] <> When a loss sensitive algorithm competes with a delay algorithm, the delay sensitive one loses....
[00:59:22] <> Paper in transactions on networkng... showed it was fair competing against TCP.
[00:59:33] <> (Cx-TCP)
[00:59:57] <> Lars: While it's easy to play with algorithms you will want one that is standardized eventually.
[01:00:29] <> Lars: This will be a huge amount of work.. potential BoF for Paris... now there is energy, but is not easy.
[01:01:49] <> Lars: Could use LEDBAT (delay based) and TFRC...
[01:02:07] <> Randall Jesup: Not clear how LEDBAT would compete with another delay based scheme...
[01:02:18] <> Lars: One with lower delay threshold will lose.
[01:03:02] <> Randall: In game don't want to lay down for your media....
[01:03:39] <> Aaron Rosenberg: You need rate control estimate to send any video... estimate has to exist.
[01:06:07] <> Cx-TCP approximates RED AQM; typically keeps delay low.
[01:06:29] <> Investigation to prove fairness with algorithms from Harald's draft.
[01:07:40] <> Question to room: Is there consensus on using SCTP?
[01:07:56] <> Or do people want to use DCCP or something else?
[01:08:04] <> Magnus: Want a formal call.
[01:08:49] <> Dan Wing: Question is about SCTP over UDP... want SCTP native eventually..... HTTP didn't plan for using SCTP eventually... would be good if we thought of it now.
[01:09:31] <> Mathew: SCTP like SDP is the least-bad alternative before us... unfortunate that we dont have better alternatives.... SCTP isn't quite what we wanted.
[01:10:13] <> Justin: A few hard problems around congestion control... is there a subset that we can implement in v1 that can be developed into a full implementation?
[01:10:21] <> Randal: Congestion control is biggest open question.
[01:11:57] <> Lars: You want to go with a framework.... we has loss-based congestion control as well as LEDBAT.... if you want to limit yourself to them, IETF will be ok with that.
[01:12:25] RjS joins the room
[01:12:47] <> Lars: There is high speed TCP, qbic... in IRTF. When I was transport AD, we tried, but authors haven't had energy to bring them forward. They could come out of IETF quickly, but don't know how useful they are.
[01:12:59] <> Justin: Where could you get to by mid-year?
[01:13:08] <> Lars: TCP and LEDBAT algorithms.
[01:14:50] Martin Thomson leaves the room
[01:15:46] Martin Thomson joins the room
[01:18:42] <> Bernard: If you're trying to send large amounts of data you'll need to understand how LEDBAT will interact with video congestion control.
[01:20:14] <> Lars: You won't get everything you want with caps... LEDBAT is understood when working with TCP... understood in bit torrent.... TFRC reacts much slower.... if you use loss based we will understand it.
[01:20:37] <> Aaron: Use case is user drags picture into conversation.... can do inside a video stream, but also as a side data channel.
[01:20:45] <> Randall: High priority data channel.
[01:21:22] <> Martin: Concern that I had one association or multiple between peers?
[01:21:27] <> Randall jesup: ONe.
[01:21:40] <> Martin: Can you mix game data with something less strict?
[01:21:50] <> Randall: Maybe... have to look at use cases.
[01:22:24] <> Magnus: Can we make some decisions? First question is SCTP or not.
[01:23:11] <Martin Thomson>
[01:23:15] <> Go directly to two questions: Do you want something for the data transport protocol, SCTP or something else?
[01:23:45] <> 3
[01:24:09] <> Favoring SCTP: 19 hands.
[01:24:56] <> Next question is ordering: SCTP over DTLS or DTLS over SCTP (both over UDP).
[01:25:26] <> Randall Stewart: Only real difference is because of DTLS there is limit on size. 2^14.
[01:25:42] <> If you go opposite way you won't be in kernel.. since DTLS won't be in kernel.
[01:26:06] <> DTLS over SCTP has size... SCTP over DTLS won't be done in kernel.
[01:26:29] <> You can send multiple streams with DTLS over SCTP...
[01:27:37] <> EKR: You would need ICE in the kernel... so it this a real consideration? Seems unlikely.
[01:28:02] <> EKR: Anything can be made to work but preference is SCTP over DTLS.
[01:29:21] <> Magnus: Do you have enough data to decide? Second is do you prefer SCTP-DTLS-UDP (from top to bottom) or DTLS-SCTP-UDP (from top to bottom).
[01:29:25] rillian leaves the room
[01:30:39] <> EKR: One on right (DTLS-SCTP-UDP) is simply bad.... have to do SCTP handshake first... one on right has size limitation... one on left (SCTP-DTLS-UDP) is better.
[01:30:47] <> Magnus: Show hands for not enough info.
[01:31:02] <> Stefan: I don't have enough info to know if I care!
[01:31:07] <> One hand up.
[01:31:34] <> Magnus: Do you prefer SCTP-DTLS-UDP. 18.
[01:31:49] <> Magnus: DTLS/SCTP/UDP: no hands.
[01:32:15] <> Magnus: pretty clear we go forward with SCTP-DTLS-UDP choice
[01:32:38] <> Magnus: we can't make much more decisions today... more has to come out of improving use cases and picking up a working doc.
[01:33:55] Lars leaves the room
[01:34:30] RjS leaves the room
[01:34:33] <> EKR has an unimpressive demo... but he is shy.
[01:36:33] Gonzalo leaves the room
[01:37:14] <> Demo of browser selecting webcam.... Together Conference Board.
[01:38:17] <> Connected to conf. bridge in France... uses WebRTC to SIP relay....
[01:38:56] <> EKR comes up to give demo.
[01:39:42] <> Generic IdP demo Verifier.
[01:40:00] <> Has one side sending an assertion, the other verifying it.
[01:41:02] rejzak leaves the room
[01:41:21] <> Justin Uberti up.
[01:41:37] <> Justin: For those on the phone this may not be so exciting....
[01:41:48] Neil Stratford leaves the room
[01:41:59] <> Justin: Two things here...
[01:42:09] <> EKR: This is even worse than my demo (screen is black)!
[01:42:24] <> Justin: This is face detection in JS... not even using a worker!
[01:42:43] <> Takes output from getUserMedia, uses Canvas, does face detection....
[01:43:10] <> Square over Justin's face....
[01:43:21] <> It finds Magnus and Ted.
[01:43:51] <> In JS you can do amazing things... surprising for a C++ programmer. Unless it's really high performance, you can do it in JS .
[01:44:34] <> Justin: This is someone else's demo, not mine.
[01:44:44] <dontcallmedom> (a demo with getUserMedia (as implemented by Opera) that does face detection and adds a moustache: )
[01:45:43] <dontcallmedom> another one where the getUserMedia output is made to explode
[01:45:52] <> Can do cool effects within browser itself... stuff applied to a video tag.... you can do things with stuff going through encoder...
[01:46:21] <> Can do things that are hard in hangouts now... mindblowing.
[01:46:52] <> A little sample app to understand what devs want to do.... here is an app running on app engine... doesn't work with latest version of Chrome canary temporarily.....
[01:47:19] <> Randal: Never preceed a demo with an ything other than "watch this".
[01:47:55] <> Justin: People who visit the same URL get placed into video chat with you....
[01:48:12] <> What codec? VP8.
[01:48:33] <> Will be running at
[01:48:53] <> Watch this... you get a URL down at the bottom if someone gets the same URL you'll be off and chatting.
[01:49:19] <>
[01:49:38] <>
[01:49:48] <> Check it out!
[01:50:39] <> More apps...
[01:51:06] <Martin Thomson>
[01:51:22] <Martin Thomson>
[01:51:35] <Martin Thomson> Doesn't work in IE8
[01:52:28] <> App running in a webview on an iPad.
[01:53:03] <> Shows call between PC and an iPad.
[01:53:15] <> It crashed!
[01:53:19] <> Watch this!
[01:53:50] <> Stefan: is supposed to show....
[01:54:30] <> Ted fooling with demo....
[01:54:48] <> Now we have an ongoing video call....
[01:54:50] <Martin Thomson> Ted is trying to get the ubuntu laptop to mirror onto the big screen
[01:55:09] <> Looks like a fancy camera that should be able to zoom.....
[01:55:38] <> Stefan's head pops up on iPad....
[01:56:19] <> So you have a WebKit browser talking to iPad application.
[01:57:02] <> Another demo....
[01:57:26] hardie leaves the room
[01:57:27] <> When you join a URL you get thrown into a specific room....
[01:59:10] Spencer Dawkins leaves the room
[01:59:58] Spencer Dawkins joins the room
[02:00:10] <> More between the PC and iPad....
[02:00:56] <> Can have screen as a source (screen s haring scenario).
[02:02:10] <> Any more demos?
[02:02:13] <> One more.
[02:03:21] <> Opera has getUserMedia and has nice demos... but not my demo (I have nothing to do with Opera).
[02:03:39] <> You can show getUserMedia with elements... can use canvas on top of it to get nice ffects.
[02:04:04] <> Can do face recognition and put a mustache on the face.
[02:05:07] <> Cullen working on Cisco demo....
[02:05:17] <> Anyone want to demo before Cullen?
[02:05:48] <> Cullen: skiing is like demos... I don't my last words to be "ooops".... but rather "watch this".
[02:06:07] <> EKR: few things are good after "watch this..." (when your son says this...).
[02:06:19] <> Someone (?) steps up... I can do a emo.
[02:07:10] <> htps://
[02:07:22] <> Will attempt to make a video call: "watch this!"
[02:08:03] <> Can see people in room... have a bridge version of this....
[02:08:56] jesup leaves the room
[02:08:57] <> Bridge is hosted in the cloud....
[02:09:33] <> Watch this....
[02:10:18] Spencer Dawkins leaves the room
[02:10:23] burn leaves the room
[02:10:26] <> Cullen: maybe tomorrow at lunch. Breakfast at 8 AM tomorrow. YOu will need another badge.
[02:10:35] <> Thank you everyone!
[02:10:44] <> Meeting adjourned. Impromtu dinners may follow.
[02:10:45] Martin Thomson leaves the room
[02:11:23] hta leaves the room
[02:11:26] leaves the room
[02:12:17] Paul Hoffman leaves the room
[02:12:27] Hadriel Kaplan leaves the room
[02:15:45] Cullen Jennings leaves the room
[02:17:25] hta joins the room
[02:18:17] hta leaves the room
[02:19:27] Jonathan Lennox leaves the room
[02:21:52] dontcallmedom leaves the room
[02:43:43] jmce leaves the room: offline
[03:15:57] drageke leaves the room
[04:46:52] hta joins the room
[04:51:37] hta leaves the room
[05:05:03] RjS joins the room
[05:05:03] varun leaves the room
[05:17:43] dontcallmedom joins the room
[05:42:15] Magnus leaves the room
[06:02:29] varun joins the room
[06:20:42] RjS leaves the room
[06:33:22] jesup joins the room
[07:58:18] Hadriel Kaplan joins the room
[08:18:01] Hadriel Kaplan leaves the room
[08:18:02] Hadriel Kaplan joins the room
[08:33:02] varun leaves the room
[09:12:30] varun joins the room
[09:15:58] varun leaves the room
[13:42:35] Spencer Dawkins joins the room
[13:53:28] Neil Stratford joins the room
[13:59:29] Spencer Dawkins leaves the room
[14:00:20] Spencer Dawkins joins the room
[14:17:56] Spencer Dawkins leaves the room
[14:38:00] Hadriel Kaplan leaves the room
[15:13:01] jesup leaves the room
[15:30:28] Neil Stratford leaves the room
[15:51:22] Neil Stratford joins the room
[16:08:11] Neil Stratford leaves the room
[16:08:28] Neil Stratford joins the room
[16:11:58] Hadriel Kaplan joins the room
[16:27:20] dontcallmedom leaves the room
[16:32:50] Neil Stratford leaves the room
[16:33:03] Neil Stratford joins the room
[16:33:08] dromasca joins the room
[16:34:46] dromasca leaves the room
[16:39:13] Neil Stratford leaves the room
[16:40:19] Neil Stratford joins the room
[16:45:10] rillian joins the room
[16:52:37] dontcallmedom joins the room
[16:52:49] joins the room
[16:53:45] <> RTCWEB Interim Meeting, February 1, 2012 (Day 2)
[16:56:25] hta joins the room
[16:56:56] paul.hoffman joins the room
[16:57:35] jesup joins the room
[16:58:19] <paul.hoffman> FWIW, I note that neither the host nor "Front O Room" are in the WebEx at this moment.
[16:58:47] <paul.hoffman> So, we're not hearing anything (not that we could hear much yesterday...)
[17:01:42] <paul.hoffman> I take it that the meeting hasn't actually started, correct?
[17:01:53] RjS joins the room
[17:02:54] <hta> no, mchairs are congregating in front of room.
[17:03:24] Adium joins the room
[17:04:36] <paul.hoffman> Who's winning? :-)
[17:05:45] rejzak joins the room
[17:06:27] Neil Stratford leaves the room
[17:06:54] Neil Stratford joins the room
[17:07:20] <paul.hoffman> Call-in folks: please remember to mute your mics. Someone is sniffling and typing...
[17:07:28] <hta> The podium is empty - I guess they all lost.
[17:07:31] leaves the room
[17:10:23] Lars joins the room
[17:10:28] <paul.hoffman> We can barely hear Ted.
[17:11:01] Adium leaves the room
[17:11:13] Gonzalo joins the room
[17:11:58] Jonathan Lennox joins the room
[17:12:00] <rejzak> the volume from the room was unacceptably low for most of the day yesterday, so if there's anything that can be done to improve it today I'm sure all of us who are remotely connected would be eternally grateful
[17:12:51] Magnus joins the room
[17:13:19] <rillian> audio seems no better than yesterday :(
[17:13:22] <paul.hoffman> Eric is barely audible, and he usually speaks loudly.
[17:13:28] <paul.hoffman> Yes, same as yesterday.
[17:13:42] Ted Hardie joins the room
[17:14:07] Lars leaves the room
[17:14:10] <hta> Did it help?
[17:14:17] <rillian> slightly
[17:14:18] <paul.hoffman> Helped a bit, yes.
[17:14:33] Lars joins the room
[17:15:35] <dontcallmedom> Web Origin RFC
[17:15:54] Neil Stratford leaves the room
[17:16:00] Neil Stratford joins the room
[17:16:45] <jesup> Could someone paste the slide link? Thanks
[17:17:47] Cullen Jennings joins the room
[17:18:01] <rillian> ?
[17:18:47] joins the room
[17:19:00] <rillian> thanks for scribing yesterday, aboba
[17:19:19] <> Eric at the mike. Going over mixed content issue.
[17:19:51] <> Proposed resolution is to treat HTTP and HTTPS origins as separate. Asking about whether to forbid all active mixed content or remote RTCWEB permissions.
[17:20:14] <> Stefan: By revoking permissions we mean both camera and mic?
[17:20:29] <> Eric: If permission grants are attached to HTTP origins, then they are not active on that page.
[17:21:21] <> Mani: I agree it should be a MUST. Can Javascript can be signed?
[17:21:31] <> Eric: Not currently, but if so, would be treated like HTTPS.
[17:21:55] <> Jonathan Lennox: Are you saying that existing permissions don't apply or that you don't grant additional permission requests?
[17:22:13] Neil Stratford leaves the room
[17:22:35] <> Maybe ask permission every time?
[17:22:37] Neil Stratford joins the room
[17:23:09] <> Tim: Mixed content changes over time. You could create a peerconnection and then it accesses a Javascript resource and then becomes mixed. Do you want to stop streaming immediately?
[17:23:39] <> Eric: Could say don't allow3ed mixed to start with, leave up to browser to handle dynamic case.
[17:24:09] <> Eric: Will put text together and send to the list.
[17:24:27] <> Issue: consent freshness/keepalives.
[17:24:37] <Cullen Jennings> Great point TIm made - I sure hope that issue gets captured in some document
[17:24:46] <> Problem: How to verify continuing consent?
[17:24:58] <> ICE keepalives are STUN Binding Indications (one-way).
[17:26:06] <> Proposal: use STUN Binding Requests instead.
[17:27:54] <Cullen Jennings> Bernard asking: draft not clear about exact ice extensions to exibit consent. Are the flags the same or not? does it need credentials. Answer: needs to be worked out
[17:28:03] <> What we need is an ICE mehanism.
[17:29:07] <> Hadriel: Are you ok if the STUN binding request lacks auth?
[17:29:10] <> Eric: Yes.
[17:29:25] <> Dan Wing: How about sending it the other way (from receiver to sender).
[17:30:05] <> issue: Media Security Requirements (won't be resolved today).
[17:30:44] <> Hadriel: back a slide, please. We also talked about RTCP as a consent mechanism. Not necessary anymore.
[17:31:20] <> DTLS/SRTP can detect MITM with fingerprint checks.
[17:31:38] <> Demand for SDES, RTP or both
[17:31:59] <> Oscar makes an argument for SDES in his draft.
[17:32:32] <> Interop deployment questions
[17:32:48] <> Most current implementations support SDES (all support RTP).
[17:33:38] <> Interaction with Server-based features.
[17:33:41] burn joins the room
[17:34:07] <> Demos we saw involved having servers touch media.... can't do that with e2e security.
[17:34:37] <> Two models: browser to browser secure... media protected from JS
[17:34:53] <> JS visible. Powerful effects but need to trust JS
[17:35:09] Neil Stratford leaves the room
[17:35:43] Neil Stratford joins the room
[17:39:23] <Ted Hardie> The new presentation should be on the proceedings site now
[17:39:28] Martin Thomson joins the room
[17:40:39] <Martin Thomson> in response to Hadriel: when verifying the identity of the other party, you have to trust their identity provider
[17:41:25] <> Randal Jesup has slides, this is a hard problem we will punt it.
[17:42:37] <> Oscar: Requires willingness to partcipate.
[17:43:07] <> Eric: Poker sites are supposed to take funds and escrow them.... give up things to gain confidence.
[17:43:26] <> Justin: Identity could be an individual or an entity ( a bridge server you trust, versus pokerstars).
[17:44:04] <> RTCWEB Generic Identity Service
[17:44:45] <> Who knows what an Iframe is? Lots raise their hands. In the web? Less. How many know what click jacking is? Some raise hands.
[17:45:21] <> What are we trying to accomplish? Allow Alice and Bob to have a secure call, authenticated with their identity providers.
[17:46:58] <> Mathew: Isn't protection against active attack bad for service provider?
[17:47:38] <> Cullen: WebEx believes it would be a business advantage.
[17:52:47] Cullen Jennings leaves the room
[17:53:44] Cullen Jennings joins the room
[17:53:53] <> Terminology (Authenticating Party), Identity Provider, Relying Party
[17:54:09] <> There are two types of IdP, authoritative and third-party
[17:56:00] dontcallmedom leaves the room: Replaced by new connection
[17:56:02] dontcallmedom joins the room
[17:57:27] <> NO need to explicitly trust authoritative IDPs.
[17:57:39] Lars leaves the room
[17:57:41] <> Third-party IdPs need to be explicitly trusted.
[17:57:47] Lars joins the room
[18:00:24] Martin Thomson leaves the room
[18:00:38] paul.hoffman leaves the room
[18:00:41] <> Dan Druza: What about phone numbers.
[18:00:44] Martin Thomson joins the room
[18:00:50] <> Eric: Jon Peterson is the IdP for phone numbers.
[18:01:18] <> Cullen: multiple parties can claim ownership (e.g iMessage).
[18:12:02] leaves the room
[18:14:13] drageke joins the room
[18:16:33] joins the room
[18:16:57] <> BrowserID: Why no MITM attacks?
[18:17:13] <> Alice does GET to, forwards GEt to
[18:17:59] <> Audience parameter (, relying party checks origin
[18:18:16] Neil Stratford leaves the room
[18:18:33] <> BrowserID JS is part of the TCB
[18:18:50] Lars leaves the room
[18:20:15] Lars joins the room
[18:20:18] Neil Stratford joins the room
[18:22:28] <drageke> Audio level still apparently lousy
[18:25:34] Martin Thomson leaves the room
[18:25:45] Martin Thomson joins the room
[18:27:15] <> PostMessage: receiver
[18:27:20] <> origin value can be trusted
[18:28:53] <> Why aren't logins done in IFRAMEs?
[18:29:38] <> Both Facebook Connect and BrowserID use a separate window a separate window means they can examine the origin
[18:34:40] jmce joins the room
[18:45:34] Martin Thomson leaves the room
[18:52:02] leaves the room
[19:11:01] joins the room
[19:12:11] Neil Stratford leaves the room
[19:12:54] Neil Stratford joins the room
[19:16:04] <Magnus> Link to the draft in RFC-editor queue for the VBR speech codec issue:
[19:25:17] joins the room
[19:25:33] leaves the room
[19:27:06] leaves the room
[19:27:32] Soo-Hyun Choi joins the room
[19:41:33] Soo-Hyun Choi leaves the room
[19:47:25] Cary FitzGerald joins the room
[19:57:46] Neil Stratford leaves the room
[19:58:00] Neil Stratford joins the room
[20:02:12] hta leaves the room
[20:02:57] hta joins the room
[20:04:35] hta leaves the room
[20:04:43] hta joins the room
[20:05:07] Ted Hardie leaves the room
[20:13:32] Lars leaves the room
[20:13:33] Hadriel Kaplan leaves the room
[20:15:13] RjS leaves the room
[20:15:36] Neil Stratford leaves the room
[20:17:36] Neil Stratford joins the room
[20:24:14] Neil Stratford leaves the room
[20:24:39] Magnus leaves the room: I'm happy Miranda IM user. Get it at
[20:26:12] Neil Stratford joins the room
[20:35:13] jmce leaves the room: offline
[20:37:33] Lars joins the room
[20:37:40] Lars leaves the room
[20:53:01] rejzak leaves the room
[20:58:43] Neil Stratford leaves the room
[21:00:47] Neil Stratford joins the room
[21:00:51] Adium joins the room
[21:02:39] Cary FitzGerald leaves the room
[21:03:59] Hadriel Kaplan joins the room
[21:04:37] Cary FitzGerald joins the room
[21:08:24] Jonathan Lennox leaves the room
[21:09:40] jesup leaves the room
[21:10:34] Cullen Jennings leaves the room
[21:58:53] rillian leaves the room
[22:04:20] RjS joins the room
[22:05:25] Soo-Hyun Choi joins the room
[22:30:52] RjS leaves the room
[22:44:07] Neil Stratford leaves the room
[22:44:23] Neil Stratford joins the room
[22:51:09] Neil Stratford leaves the room
[22:51:29] Neil Stratford joins the room
[23:04:49] Neil Stratford leaves the room
[23:05:05] Neil Stratford joins the room
[23:26:35] Neil Stratford leaves the room
[23:28:41] Neil Stratford joins the room
[23:35:27] Neil Stratford leaves the room
[23:35:46] Neil Stratford joins the room
[23:38:56] dontcallmedom leaves the room
[23:52:07] Gonzalo leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!