IETF
rtcweb@jabber.ietf.org
Thursday, 28 July 2011< ^ >
martin.thomson has set the subject to: RTCWEB WG http://tools.ietf.org/wg/rtcweb/agenda
Room Configuration

GMT+0
[13:22:59] burn joins the room
[15:00:30] burn leaves the room
[16:57:56] Hadriel Kaplan joins the room
[16:58:35] kepeng_li\40jabber.org joins the room
[16:58:49] MeetechoAudioFeed joins the room
[16:59:09] RjS joins the room
[16:59:27] Lorenzo Miniero joins the room
[16:59:34] MeetechoSlides joins the room
[16:59:50] Robert Sparks joins the room
[17:00:21] <MeetechoSlides> Slide 1: RTCWEB WG
[17:00:48] MeetechoSpromano joins the room
[17:01:58] mph joins the room
[17:02:18] <MeetechoSlides> Slide 2: NOTE WELL
[17:02:36] <Hadriel Kaplan> Welcome to the RTCWEB jabber room, I will be your remote microphone. If you wish to have a comment spoken at the mic, please prefix your jabber text with "mic:"
[17:02:37] Cullen Jennings joins the room
[17:02:51] Jonathan Lennox joins the room
[17:02:57] admin joins the room
[17:02:57] admin leaves the room
[17:03:00] Jan Skoglund joins the room
[17:03:02] g.e.montenegro joins the room
[17:03:06] Ralph Giles joins the room
[17:03:07] <MeetechoSlides> Slide 3: AGENDA THURSDAY
[17:03:18] patrick Mourot joins the room
[17:03:52] kpfleming joins the room
[17:04:05] richard.barnes joins the room
[17:04:32] <MeetechoSlides> Presentation stopped
[17:05:00] <MeetechoSlides> Slide 1: RTP Multiplexing
[17:05:01] <MeetechoSlides> Slide 2: Problem Definition
[17:05:22] MeetechoAlex joins the room
[17:05:26] hta joins the room
[17:05:26] Randell Jesup joins the room
[17:05:44] Ted Hardie joins the room
[17:06:07] <Ted Hardie> If you need something reflected to the room, please preface with MIC:
[17:06:08] <Ted Hardie> Thanks
[17:06:55] giles joins the room
[17:07:42] <MeetechoSlides> Slide 3: What we really want
[17:08:46] TedH joins the room
[17:09:18] <MeetechoSlides> Slide 4: Solution: Use SSRC for demux
[17:09:56] lef_jp joins the room
[17:10:18] Cary Bran joins the room
[17:11:45] Linyi Tian joins the room
[17:12:19] <Linyi Tian> it would be good to have slide number in the presentation. it will help jabber scribe
[17:13:20] <MeetechoSlides> Slide 5: Implications
[17:13:21] burn joins the room
[17:13:21] <Randell Jesup> I've done single-port before, but de-multiplexed by source addr/port, which won't work here
[17:14:14] MeetechoSpromano leaves the room
[17:14:27] MeetechoSpromano joins the room
[17:17:21] <MeetechoSlides> Slide 6: What gets specified
[17:18:50] <MeetechoSlides> Meetecho session is at http://www.meetecho.com/ietf81/rtcweb
[17:19:31] <Randell Jesup> mic: How will b=blah etc work? I assume that's the bandwidth for all data. Any other m= tied parameters that have issues?
[17:20:05] mph leaves the room
[17:20:25] suzukisn joins the room
[17:20:37] tterribe joins the room
[17:21:05] tterribe leaves the room
[17:21:13] <Randell Jesup> thanks
[17:21:29] Xavier Marjou joins the room
[17:22:26] <giles> good point about the payload types
[17:23:06] <Randell Jesup> mic: you can redefine the "standard" non-dynamic numbers
[17:23:18] <giles> wait, if you're distinguishing by SSRC, doesn't that let you parse the PT contingent on SSRC?
[17:23:57] simo.veikkolainen joins the room
[17:24:00] <Randell Jesup> Yeah, interop with that is "interesting"
[17:24:12] HAYASHI Tatsuya joins the room
[17:24:16] wolfgang.beck01 joins the room
[17:24:36] <Randell Jesup> giles: you can't tell from the SSRC if it's audio or video
[17:24:40] Ethan Hugg joins the room
[17:24:42] Enda Mannion joins the room
[17:24:53] Gonzalo joins the room
[17:25:03] yunfei joins the room
[17:25:33] Parthasarathi R joins the room
[17:25:41] <hta> .... the concept of defining a new definition of "payload type" that is scoped to SSRC rather than to RTP session makes me cringe, but it's technically possible, I think .....
[17:25:48] <Jonathan Lennox> Randall: in particular, you tell from the PT whether it's audio or video.
[17:25:51] Roy joins the room
[17:25:59] sal joins the room
[17:26:01] <Randell Jesup> Right
[17:26:06] <Jonathan Lennox> hta: but you have to signal the SSRC's top-level type out-of-band in that case
[17:26:11] <Randell Jesup> hum..
[17:26:20] <Jonathan Lennox> Which were you humming for?
[17:26:27] <Randell Jesup> I'm with the first group
[17:26:46] jmspeex joins the room
[17:26:47] <Hadriel Kaplan> I did hum, but it wasn't clear when to do it for you :)
[17:26:54] <Hadriel Kaplan> ah good i did
[17:26:55] <Randell Jesup> Good with that
[17:26:57] <hta> a=rtpmap:2458/98 .... (PT 98, but only when it's on SSRC 2458...)
[17:27:25] <MeetechoSlides> Presentation stopped
[17:27:36] <Randell Jesup> Thanks for the relays
[17:27:48] <MeetechoSlides> Media other than multiplexing (Colin)
Meetecho session is at http://www.meetecho.com/ietf81/
[17:27:51] <Hadriel Kaplan> Cullen at the mic
[17:27:54] <Hadriel Kaplan> presenting
[17:27:55] <MeetechoSlides> Slide 1: Media Negotiation
[17:27:56] Suhas Nandkumar joins the room
[17:27:58] <MeetechoSlides> Slide 2: What we seem to agree on
[17:28:16] <hta> Jonathan, how we handle that particular misfeature of SDP is something I'll be watching carefully when we map this signalling to the SDP punched cards.
[17:28:19] <MeetechoSlides> sorry... Meetecho session is at http://www.meetecho.com/ietf81/rtcweb
[17:29:02] Marc Linsner joins the room
[17:29:05] <giles> hta: that's more what I meant
[17:29:26] <giles> if you can't tell the media type from the SSRC, I'm not sure what 'demultiplexing by SSRC' means.
[17:29:49] <hta> giles, just to imagine how SDP would have looked if I had my druthers:
[17:29:53] <MeetechoSlides> Slide 3: Call from Slashdot to Ford
[17:30:11] <Linyi Tian> meetecho always kick me out, i don't know why
[17:30:16] patrick.mourot joins the room
[17:30:29] <hta> m=5
a=rtpmap:97 video/vp8
a=rtpmap:98 audio/opus
[17:30:49] <hta> more likely to win consensus is
[17:30:53] <Hadriel Kaplan> can you guys hear Cullen?
[17:31:16] <Randell Jesup> yes
[17:31:21] <Hadriel Kaplan> k
[17:31:35] <hta> m=video
a=marker:foo
a=rtpmap:97 vp8
m=audio
a=marker:foo
a=rtpmap:98 opus
[17:32:14] gmaxwell joins the room
[17:32:19] <giles> hta: *nod*
[17:32:22] <Jonathan Lennox> hta: The first model is great until you try to figure out the backward-compatibility
[17:32:57] <Lorenzo Miniero> Linyi we never kick anybody :?
[17:33:14] <Jonathan Lennox> As far as I can tell you'd need to use SDP Media CapNeg.
[17:33:15] <hta> Jonathan, yes, the first model requires a signalling gateway, more or less.
[17:33:19] <Lorenzo Miniero> oyu may just be getting timeouts from the interface, sorry about that
[17:34:40] <MeetechoSlides> Slide 4: JS User Clicks Offer
[17:34:53] <Linyi Tian> yup, just fail to go inside.
[17:35:07] <Linyi Tian> everytime i tried, i will leave automaticialy which i don't know hwy
[17:35:10] <MeetechoSlides> Slide 5: Call from Google to Facebook
[17:35:19] <Lorenzo Miniero> are you using the same name you are using now?
[17:35:23] <Jonathan Lennox> hta: Not just signaling, also media I think, to do the demux? The goal is to be able to send an offer that means "please do mux if you can" in a way that a legacy box will read as an offer of two sessions.
[17:35:27] <Linyi Tian> i tried firefox and safari,none of them work. it worked yesterday
[17:35:32] <Lorenzo Miniero> if so try a diferent one, since a conflict in nicknames may be the cause
[17:35:33] <Linyi Tian> maybe too many people inside?
[17:35:44] Marc Linsner leaves the room: Disconnected.
[17:35:51] <Linyi Tian> try again
[17:35:54] <Lorenzo Miniero> nono there's no such limit so it shouldn't be that
[17:35:59] <giles> Linyi Tian: i got a bug yesterday where it wouldn't let me back in until some timeout expired. You could try clearing the login cookie.
[17:36:44] <hta> Jonathan, that would obviously require version 2 of my examples. It also makes SDP more complicated, which is not a feature - which is why I start thinking of signalling gateways.
[17:36:53] Marc Linsner joins the room
[17:37:06] Real Linyi joins the room
[17:37:08] Kepeng Li joins the room
[17:37:16] kpfleming leaves the room: Replaced by new connection
[17:37:17] kfleming joins the room
[17:37:20] <Real Linyi> ok, now i am inside
[17:37:33] <Lorenzo Miniero> sorry about the issue..
[17:37:33] <Real Linyi> thanks for the help
[17:37:33] <MeetechoSlides> Slide 6: Requirements
[17:37:44] <hta> m=video
a=marker:foo
a=rtpmap:97 vp8
m=audio
a=iwouldreallylikethistogetherwith:foo
a=rtpmap:98 opus
[17:37:59] <hta> and both m=video and m=audio contains ICE stuff
[17:39:53] <Randell Jesup> Forking is important: joe@facebook may want to work to browser, laptop and android phone
[17:40:11] g.e.montenegro leaves the room
[17:40:29] danwing joins the room
[17:40:54] <MeetechoSlides> Slide 5: Call from Google to Facebook
[17:41:35] patrick.mourot leaves the room
[17:42:14] Marc Linsner leaves the room
[17:42:30] wolfgang.beck01 leaves the room
[17:42:47] Linyi Tian leaves the room
[17:43:17] <Randell Jesup> And there's a security state machine (key exchange), assuming security (DTLS/etc)
[17:44:57] <Jonathan Lennox> hta: Yeah, that's roughtly what I'm thinking. Roni Even suggested that a=iwouldreallylikethistogetherwith should be SDP grouping.
[17:44:57] <richard.barnes> those who do not know SIP are condemned to repeat it
[17:45:17] <MeetechoSlides> Slide 6: Requirements
[17:45:19] <Ted Hardie> Ask me sometime to explain why mahjong is not the same game in China and New Jersey
[17:45:39] <Ted Hardie> Sorry, that should have had @richard.barnes at the front.
[17:46:31] paul erkkila joins the room
[17:47:23] <Real Linyi> Ted: In China we have many ways to play Mahjong
[17:47:32] <kfleming> richard.barnes: also true of TCP far more often than should be the case
[17:47:59] <Real Linyi> So it really depends on which way you plays Mahjong.
[17:48:37] <Real Linyi> we have more than 30 provinces and we may have more than 30 ways to play mahjong.
[17:48:39] <Ted Hardie> @Linyi 對了, but they are all different from the New Jersey method, which changes the rules every year, in order to increase interest in the game
[17:48:56] <Real Linyi> so how to deliver SDP we also have many ways:)
[17:49:00] panqiuling\40jabber.org joins the room
[17:49:28] <Real Linyi> next time we can play together and i can win some money:)
[17:50:07] <MeetechoSlides> Slide 5: Call from Google to Facebook
[17:50:15] <Real Linyi> we can do FengShui on cullen's draft. it would be a good replacement than hum
[17:50:19] <Hadriel Kaplan> Reminder: please use the word "mic:" before your comment if you want it spoken at the microphone in the meeting
[17:50:26] <Jonathan Lennox> MGCP in the browser!
[17:50:33] <Hadriel Kaplan> Skinny in the browser
[17:50:44] <Ted Hardie> @Linyi I *really* hope we're not siting a grave.
[17:51:00] <Randell Jesup> H323 in the browser! :-)
[17:51:12] <MeetechoSlides> Slide 7: Option: High Path
[17:51:42] <MeetechoSlides> Slide 8: Option: Low Path
[17:52:17] <Real Linyi> it's red not orange
[17:52:45] paul erkkila leaves the room
[17:52:46] <Randell Jesup> Reduces delay, which is a good thing
[17:52:51] <MeetechoSlides> Slide 9: Option: Mid Path
[17:53:39] <MeetechoSlides> Slide 10: Choices we need to make soon
[17:54:23] <Real Linyi> are we sure Path B is better than A?
[17:54:46] qiuling pan joins the room
[17:54:48] <Real Linyi> we always hope something new would be better but it is not always the case.
[17:55:13] <Jonathan Lennox> We have the opportunity to make new mistakes.
[17:55:33] <kfleming> we'd also have to remove retargeting and lots of other SIP complexity
[17:55:35] <Ted Hardie> @Linyi Cullen and Jon lay out some arguments in their draft on advertise/proposals. You can check their logic there http://tools.ietf.org/html/draft-peterson-sipcore-advprop-01
[17:55:54] <MeetechoSlides> Slide 9: Option: Mid Path
[17:55:54] <Randell Jesup> You can do better than SDP (witness the pain of SDP CapNeg), but in the end you may not gain *that* much and it complicates interop a lot
[17:56:29] <kfleming> SDPCapNeg using some structured representation would be far less painful than what we have now
[17:57:36] <burn> Key is not whether you can do "better" for legacy interop but can you design something more appropriate for the web model of today. Legacy interop was, frankly, not the original driver for this work. It may be a use case today, but it is definitely not the only one.
[17:57:57] <burn> s/a use case/an important use case/
[17:58:58] <MeetechoSlides> Slide 6: Requirements
[17:59:26] <Real Linyi> Jonathon is honest:)
[17:59:31] <MeetechoSlides> Slide 10: Choices we need to make soon
[18:01:43] <hta> Identity is the *huge* thing that comes along with adopting any part of SIP.
[18:01:48] <Real Linyi> do
[18:02:14] <Real Linyi> do we really need to make the decison now. are the requirements clear enough to help us make the decision?
[18:02:28] <hta> Stealing will LOOK faster....
[18:02:52] <MeetechoSlides> Presentation stopped
[18:02:52] <Ted Hardie> Thank you for your emphasis
[18:03:21] <MeetechoSlides> Media other than multiplexing (Colin)
Meetecho session is at http://www.meetecho.com/ietf81/rtcweb
Slides at https://datatracker.ietf.org/meeting/81/materials.html
[18:03:23] <MeetechoSlides> Slide 1: RTP Functionalities for RTCWEB
[18:03:23] <Hadriel Kaplan> In short: we don't care about architectural principles when it doesn't suit us
[18:03:25] <MeetechoSlides> Slide 2: Introduction
[18:04:06] Enda Mannion leaves the room
[18:04:08] <kfleming> question from a relative IETF newbie: when has the IETF been willing to do something *fast* if that meant it might not be done *right*? that doesn't seem to be the IETF's modus operandi.
[18:04:16] <MeetechoSlides> Slide 3: Core Featuers
[18:04:29] MeetechoSpromano leaves the room
[18:04:31] <Hadriel Kaplan> Answer" whenever Google or Facebook are involved
[18:04:47] <Hadriel Kaplan> (just kidding)
[18:04:51] <Hadriel Kaplan> (sort of)
[18:05:07] Simon Romano joins the room
[18:05:30] <MeetechoSlides> Slide 4: RTP Optimizations
[18:05:31] <MeetechoSlides> Slide 3: Core Featuers
[18:05:50] <MeetechoSlides> Slide 4: RTP Optimizations
[18:06:36] Parthasarathi R leaves the room
[18:06:38] <kfleming> it seems like the pressure in this case is caused by the likely fact that there will only be 5-6 widely used implementations of this (on the client side)... because the RTCWEB stack in a browser isn't going to be replaceable with a different stack... and producing your browser with a different RTCWEB stack would likely not gain much traction
[18:06:51] Simon Romano leaves the room
[18:06:57] <kfleming> s/your browser/your own browser/
[18:07:00] MeetechoSpromano joins the room
[18:07:06] <Randell Jesup> Strong support fror 5506 and 5761 (was involved in specing both)
[18:07:15] <MeetechoSlides> Slide 5: Conferencing Extensions
[18:09:15] <Randell Jesup> mic: These are useful for point-to-point as well. Particularly TMMBR. And Iam very hesitant to have packet-loss stuff run through the JS code
[18:09:35] jmspeex leaves the room
[18:10:32] <Randell Jesup> Strong support for RTCP
[18:10:46] <TedH> @Randell Hadriel is in line to reflect
[18:11:02] <Real Linyi> We should start with simple features. we should not make it too complex from the beginning.
[18:11:59] <MeetechoSlides> Slide 6: RTP Header Extensions
[18:12:16] Robert Sparks leaves the room
[18:12:53] giles wonders how many of these google's webrtc code drop implements
[18:13:06] Parthasarathi R joins the room
[18:14:01] <Randell Jesup> @linyi but we should include the things we've found should have been there all along. Most of these (like 5506/5761) are pretty simple
[18:14:12] <kepeng_li\40jabber.org> I hope the chairs can reserve three sessions for the next F2F meetings.
[18:14:49] <Randell Jesup> @hadriel: thanks
[18:14:56] <kepeng_li\40jabber.org> There are many drafts available, and many people have interest in RTC-Web. Two sessions seem to be no enough.
[18:15:01] <Real Linyi> a blue day
[18:15:03] <MeetechoSlides> Slide 7: Open Issue: RTP Retransmission
[18:15:21] pee616 joins the room
[18:15:23] <Hadriel Kaplan> Randell: no prob
[18:15:38] <Real Linyi> Ted didn't smile for a while:)
[18:16:58] pee616 leaves the room
[18:16:59] <Randell Jesup> I prefer low-delay strongly over higher quality but delayed
[18:17:14] <MeetechoSlides> Slide 8: Open Issue: Forward Error Correction
[18:17:17] <Randell Jesup> (forideo)
[18:17:28] <Randell Jesup> (for video)
[18:17:48] <MeetechoSlides> Slide 9: Open Issue: RTP Rate Control
[18:19:54] <Randell Jesup> mic: I'd love something similar to Radvision's congestion control stuff - not loss-based congestion control only
[18:20:15] <Ted Hardie> I'm cutting the mic lines after RAndell's comment
[18:20:58] jmspeex joins the room
[18:21:21] <Randell Jesup> Agree strongly with speaker
[18:22:04] <giles> jabber doesn't define an unique ordering of messages
[18:22:16] <MeetechoSlides> Presentation stopped
[18:22:29] bpenfield joins the room
[18:22:58] <MeetechoSlides> Slide 1: RTC-Web NAT Traversal
[18:23:03] <richard.barnes> ekr's haiku are 1 / 3 / 1
[18:23:09] <kfleming> lol
[18:23:13] <MeetechoSlides> Slide 2: NAT Traversal
[18:23:32] <Hadriel Kaplan> comments to mic must be filtered through: http://www.everypoet.com/haiku/default.htm
[18:23:57] <Hadriel Kaplan> (joking)
[18:24:07] <MeetechoSlides> Slide 3: NAT Traversal
[18:24:11] <MeetechoSlides> Meetecho session is at http://www.meetecho.com/ietf81/rtcweb
Slides at https://datatracker.ietf.org/meeting/81/materials.html
[18:25:08] <kfleming> we have some mixed terminology going on here too... the last slide said "RTC-Web client applications must...", but is that the browser that provides an RTCWeb stack (accessible via WEBRTC APIs), or is that the JS application that someone wrote that uses the WEBRTC APIs?
[18:25:58] <Ted Hardie> Cullen Jennings on the floor
[18:26:16] <kfleming> i think we need to refer to "RTCWEB client applications" and "RTCWEB browsers"
[18:27:26] <MeetechoSlides> Slide 4: NAT Traversal
[18:28:02] <MeetechoSlides> Presentation stopped
[18:28:12] <MeetechoSlides> Slide 1: RTC-Web Non Media Data Transport
[18:28:17] <MeetechoSlides> Slide 2: Non-Media Data
[18:32:23] <Real Linyi> who is on the mic?
[18:32:33] <Hadriel Kaplan> EKR (Eric Rescorla)
[18:32:39] <giles> can we use RTP-over-DTLS instead of SRTP?
[18:33:08] <Randell Jesup> giles: Not advisable - see the RFC for DTLS-SRTP
[18:33:19] <Real Linyi> People didn't mention name at alllllllll
[18:33:27] <Hadriel Kaplan> That was Colin Perkins
[18:33:39] <Jonathan Lennox> Lars Eggert
[18:33:42] <Randell Jesup> @linyi he gave his name
[18:33:46] <MeetechoSlides> Slide 3: Non-Media Data
[18:34:01] <Real Linyi> some not
[18:34:03] <kfleming> this WG meeting needs the 90 minutes that CUSS didn't use yesterday :-(
[18:34:03] <Real Linyi> thanks
[18:34:24] <kepeng_li\40jabber.org> yes, we need more time
[18:34:25] <Hadriel Kaplan> Yes indeed
[18:34:32] <kfleming> Colin Perkins at the mic aain
[18:34:40] <Hadriel Kaplan> ya
[18:35:32] <Randell Jesup> mic: bandwidth adaptation will work better if they're at least cognizant of the bandwidth each other is using
[18:35:42] <kfleming> i don't know who that was speaking... he's never mentioned his name
[18:35:52] <burn> isn't there usually extra time on Friday afternoon? No one leaves early, right?
[18:36:03] <kfleming> burn: ha!
[18:36:20] <MeetechoSlides> Slide 4: Non-Media Data
[18:36:21] <Real Linyi> some people will do shopping:)
[18:36:39] <MeetechoSlides> Slide 5: Non-Media Data
[18:36:54] <Hadriel Kaplan> Before I went to the mic to speak for Randell, it was Richard Barnes
[18:37:01] <kfleming> yeah, but before that
[18:37:26] <Randell Jesup> Not needed to mic: you have a bandwidth budget that floats up and down; better to avoid self-congestion to start with than to adapt to it
[18:37:38] <Real Linyi> the v.1 should include fundemental things and keep it simple
[18:37:52] <Hadriel Kaplan> That was Justin Uberti (Google)
[18:38:05] <kfleming> thanks
[18:38:06] <MeetechoSlides> Presentation stopped
[18:38:21] <MeetechoSlides> Slide 1: The Case for Layered Codecs
[18:38:23] <MeetechoSlides> Slide 2: Limitations to presentation
[18:38:33] <Randell Jesup> Umberti's comment was why I was suggesting SCTP (though it may not have good implementations either)
[18:39:08] <kepeng_li\40jabber.org> Layered Codecs (Stephan) - 10 min
[18:39:12] <Hadriel Kaplan> SCTP is really hard to work through NATs/Firewalls
[18:39:26] <MeetechoSlides> Slide 3: Need for Error Resilience
[18:39:34] MeetechoSpromano leaves the room
[18:39:49] <Jonathan Lennox> Hadriel: presumably it'd be over UDP, just like DCCP would be
[18:40:19] <kfleming> is there a document describing use cases for the 'non-media data' that Cary was talking about?
[18:40:32] <Hadriel Kaplan> Yes but it's still ugly due to sending IP Address info inside itself in its control channel (though there's a draft or RFC now which addresses this I think)
[18:40:37] qiuling pan leaves the room
[18:41:05] panqiuling\40jabber.org leaves the room
[18:41:38] <MeetechoSlides> Slide 3: Need for Error Resilience
[18:41:51] <MeetechoSlides> Slide 4: Video Error Resilience Tools
[18:42:01] <Cary Bran> kfleming check out the use case draft http://trac.tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-01
[18:42:06] <kfleming> thanks
[18:42:14] <kfleming> lots of reading for this wg :-)
[18:42:26] <Cary Bran> oh yes
[18:43:05] <kfleming> and just like the CODEC group, we're taking about solutions before the requirements document has been completed, it appears. fun times.
[18:43:15] <hta> after us, the draftocalypse!
[18:43:20] tterribe joins the room
[18:43:24] <Hadriel Kaplan> of course - that way we can change the requirements to match our solution ;)
[18:43:34] <Real Linyi> kfleming: that is exactly what i said.
[18:43:35] tterribe leaves the room
[18:43:40] <Randell Jesup> mic: you can recover with p-frame references to older frames, if you're told where the loss occurs. This means recovery doesn't need an iframe, just a p-frame. (There is IPR on this, though). We do have a fast feedback channel, so this stuff is possible.
[18:44:05] <Real Linyi> we are trying to make it complex from the beggining. it may be much more than what we realy need.
[18:44:06] tterribe joins the room
[18:44:35] tterribe leaves the room
[18:44:37] <hta> kfleming, we're *implementing* before the requirements document has been completed. If the req doc isn't ready on time, we'll *ship product* before the requirements document has been completed. This is the Real Time Web!
[18:44:50] <MeetechoSlides> Slide 5: Temporal Scalability
[18:44:51] <kfleming> hta: yes, just like CODEC.
[18:44:54] <hta> (or just "business as usual".....)
[18:45:09] tterribe joins the room
[18:45:35] tterribe leaves the room
[18:45:37] <MeetechoSlides> Slide 6: Spatial Scalability (vs. Simulcast)
[18:46:01] tterribe joins the room
[18:46:05] tterribe leaves the room
[18:46:10] <hta> kfleming, the other alternative is of course that we get the use cases finished. Help by reading and commenting!
[18:46:16] <burn> hta: yes, in WebRTC as well. Arguably the work should have started there (with true end-user cases) and then moved to IETF, but hey, why do that when you can implement protocols first?
[18:46:25] <kfleming> will try.
[18:47:06] <Hadriel Kaplan> With regards to implement beofre specify: at the previous RTCWEB meeting this week, JDR asked Harald if Google would update to the specs if they end up being different, and he said yes
[18:47:24] tterribe joins the room
[18:47:35] tterribe leaves the room
[18:47:39] <burn> yes, Google is very considerate.
[18:48:17] <Ralph Giles> ouch
[18:48:32] <burn> oh wait, did you assume I was being sarcastic?
[18:48:32] <MeetechoSlides> Presentation stopped
[18:48:39] <Hadriel Kaplan> :)
[18:48:40] <hta> burn, real reason the draft is in rtcweb not in webrtc is that the I-D process was well known, and had the concept of personal drafts, while the W3C process took slightly more time getting used to.
[18:48:51] <MeetechoSlides> Slide 1: RTC-Web Codec and Media Processing
[18:48:55] <MeetechoSlides> Slide 2: Media Processing
[18:49:04] stpeter joins the room
[18:49:18] <kfleming> and now a new term "RTC-web endpoint devices"
[18:49:20] tterribe joins the room
[18:49:20] <burn> hta, you're right. The W3C process can also be slower than in IETF.
[18:49:21] <Ted Hardie> I think the use cases for non-media data really need to motivate why that channel cannot/should not be TCP
[18:49:23] <MeetechoSlides> Slide 3: Codec Recommendations
[18:49:35] tterribe leaves the room
[18:49:43] <kfleming> Ted Hardie: that's what i was thinking
[18:49:52] <MeetechoSlides> Slide 4: Audio Codec Recommendations
[18:49:57] Kepeng Li leaves the room
[18:49:59] <kfleming> well, TCP/TLS
[18:50:08] <MeetechoSlides> Slide 5: Video Codec Recommendations
[18:51:27] Parthasarathi R leaves the room
[18:52:01] tterribe joins the room
[18:52:05] tterribe leaves the room
[18:52:36] <giles> So "Optional" is a collection for implementation focus
[18:53:30] Parthasarathi R joins the room
[18:54:39] <Randell Jesup> mic: Strongest argument for H.263 would be VRS standards requirements - in the US FCC requires H.263 for Video Relay Service use (including VRS e911 usage). WOuldn't go beyond optional though
[18:54:56] RjS leaves the room
[18:55:18] <Hadriel Kaplan> wow Ted you seem to have less latency than me for these messages
[18:55:45] <Hadriel Kaplan> cause yo spoke before i saw it appear
[18:56:05] <kfleming> i saw it before he relayed it as well
[18:56:33] Gonzalo leaves the room
[18:56:43] burn leaves the room
[18:57:07] Jan Skoglund leaves the room
[18:57:45] <giles> hehe
[18:57:59] <hta> Google+ Hangouts?
[18:58:12] Ethan Hugg leaves the room
[18:58:14] <kfleming> i can provide a wideband audio capable SIP accessible bridge... with PSTN connectivity
[18:58:21] <Hadriel Kaplan> Thanks for playing the home game, bye bye
[18:58:26] lef_jp leaves the room
[18:58:34] <Randell Jesup> hadriel: thanks
[18:58:47] HAYASHI Tatsuya leaves the room
[18:58:58] Parthasarathi R leaves the room
[18:59:00] Hadriel Kaplan leaves the room
[18:59:05] Cary Bran leaves the room
[18:59:09] <kfleming> we could even provide an OPUS-accessible bridge :-)
[18:59:10] sal leaves the room
[18:59:10] richard.barnes leaves the room
[18:59:10] Ted Hardie leaves the room
[18:59:10] <MeetechoAlex> Bye everybody, the recording of this session will be posted soon...
[18:59:20] <Ralph Giles> thanks all
[18:59:20] hta leaves the room
[18:59:21] simo.veikkolainen leaves the room
[18:59:35] Jonathan Lennox leaves the room
[18:59:35] jmspeex leaves the room
[18:59:37] Cullen Jennings leaves the room
[18:59:45] Lorenzo Miniero leaves the room
[18:59:52] MeetechoAlex leaves the room
[18:59:54] suzukisn leaves the room
[18:59:55] <MeetechoSlides> The recording of this session will be available at http://www.ietf.org/meeting/81/remote-participation.html#Meetecho
[18:59:57] kepeng_li\40jabber.org leaves the room
[19:00:00] bpenfield leaves the room
[19:00:03] Xavier Marjou leaves the room
[19:00:04] <MeetechoSlides> bye bye
[19:00:05] gmaxwell leaves the room
[19:00:13] TedH leaves the room
[19:00:13] MeetechoAudioFeed leaves the room
[19:00:19] <MeetechoSlides> Presentation stopped
[19:00:23] Ralph Giles leaves the room
[19:01:04] MeetechoSlides leaves the room
[19:01:08] Real Linyi leaves the room
[19:02:12] patrick Mourot leaves the room
[19:02:13] Randell Jesup leaves the room
[19:02:14] Suhas Nandkumar leaves the room
[19:10:43] stpeter leaves the room
[19:13:58] yunfei leaves the room
[19:14:45] Roy leaves the room
[19:16:15] kfleming leaves the room
[19:16:38] danwing leaves the room
[19:16:44] danwing joins the room
[19:17:36] danwing leaves the room
[19:19:29] burn joins the room
[19:19:42] burn leaves the room
[19:21:11] admin joins the room
[19:21:12] admin leaves the room
[19:21:19] giles leaves the room
[19:21:30] RjS joins the room
[19:21:44] RjS leaves the room
[19:22:13] admin joins the room
[19:22:14] admin leaves the room
[19:22:14] danwing joins the room
[19:24:35] danwing leaves the room
[19:26:53] richard.barnes joins the room
[19:32:57] simo.veikkolainen joins the room
[19:33:27] richard.barnes leaves the room
[19:34:30] richard.barnes joins the room
[19:35:22] simo.veikkolainen leaves the room
[19:36:54] simo.veikkolainen joins the room
[19:37:59] simo.veikkolainen leaves the room
[20:16:47] Ted Hardie joins the room
[20:19:18] hta joins the room
[20:19:18] hta leaves the room
[20:19:41] hta joins the room
[20:30:03] jmspeex joins the room
[20:32:44] gmaxwell joins the room
[20:32:53] gmaxwell leaves the room
[20:45:47] simo.veikkolainen joins the room
[20:58:09] richard.barnes leaves the room
[21:00:17] richard.barnes joins the room
[21:01:08] hta leaves the room
[21:12:36] Ted Hardie leaves the room
[21:14:14] richard.barnes leaves the room
[21:24:06] jmspeex leaves the room
[21:30:49] jmspeex joins the room
[21:31:15] jmspeex leaves the room
[21:33:20] simo.veikkolainen leaves the room
[21:40:23] simo.veikkolainen joins the room
[21:42:41] Roy joins the room
[21:42:49] Roy leaves the room
[21:44:37] Ted Hardie joins the room
[21:44:40] Ted Hardie leaves the room
[21:45:17] simo.veikkolainen leaves the room
[23:53:40] hta joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!