Problem Statement & Protocol Summary [Jonathan R.] 20m Mark Nottingham - the draft says that it's an HTTP application. But, it says has dependencies on HTTP3. The infrastructure in cloud providers aren't even HTTP2 yet. You may not get HTTP3 benefits. Need to choose components that will work. jdr - the assumption is - an implementer would wait until the cloud supports HTTP mnot - when a cloud platform says we support v3 means front end. You discuss byways - those are hanging gets. Those will interact badly. You are just saying you are relying on webtransport and a hack for a dataplane. jdr - the app would use webtransport if it can find it, then fall back to this hack. Need collab with webtrans and http3 groups. mnot - getting that hack right will be a significant challenge. jdr - I don't think anyone will turn this on until the cloud infrastructure supports v3. We'll ask if people want it to work on http1 or not. Jared Maunch - RTP is efficient to carry G711 ulau. What will this add as overhead? Upload capacities are constrained. jdr - haven't measured it yet. The new http stuff helps because it's binary. Probably more than RTP, but less than http 1 or 2. ekr - these drafts have odd assumptions about what is invariant of the ecosystem. Need to push on the assumptions. jdr - the implementor will know if the infrastructure can support it and would wait for it. We don't want to be different on the web. Make it work as a web app. ekr - it's weird that you assume ... datagram... but not ,.... jdr - UDP is not well supported in public cloud. Justin - the current deployment situation, you have to do everything yourself. It's impossible to make it work in a failover situation. We can optimize so there's no overhead when sending RTP via QUIC. David Schinazi, webtransport chair - would ript be implemented in javascript? jdr - implemented in browsers with OTS HTTP stack. There would be a split. Some are server software that does some VOIP stuff and interacts with an SBC - no browser at all. David - the #1 goal of webtransport is to make things accessible to javascript and enable the web security model. I'm not sure what you're getting out of webtransport if there are non-browser solutions. ------------------------------------------------------------------------ Implementation Experiences at Google [Justin Uberti] 15m Harald Alvestrand (hta) - (media issues - look in the chat room) ------------------------------------------------------------------------ Freeswitch Use Cases and Needs [Anthony Minessale] 10m ------------------------------------------------------------------------ Prototype Status [Suhas Nandakumar] 10m Watson Ladd - could you get 2 servers working with load balancing? Suhas - want to try that. Haven't done it yet. ------------------------------------------------------------------------ Charter Review and Discussion [Cullen Jennings] 30m Questions about Charter slide 1/4 ekr - this slide does not mention fallback to h2. Cullen - we can update it, it's covered maybe later in the charter. What should it say? ekr - you want this to work universally - how does it work when there's no UDP penetration. if it's h2 that's ok. Say something. cullen - h2 doesn't get through all firewalls. But in a ton of usecases there's no firewalls (cloud to cloud). Need to get clarification on what fallback looks like. what should we say. ekr - I would have assume h2. But it has to be tcp. mnot - we talked about it in DoH and httpbis. The problem with specifying a particular version of http, you can't control everything in the chain. You have to be pessimistic - still needs to work in http1. jdr - I added test in the webex chat - "operating on top of HTTP but optimized for HTTP/3" Stephan Wenger - (audio issues) James Gruessing - we should consider broadcast usecases - video conferencing. Cullen - historically these have not mixed that much. THis would be usable for broadcast, but they need simpler systems - like dash. James - on the contribution side of broadcast. Consider non-bidirectional usecases. Surveillance cameras. Cullen - unidirectional in scope. Maybe clarify - unidirectional and bidirectional. Harald - The big question is - does it _have_ to pass the media over http? I don't see it work over http1. Stephan - I don't understand and I'm not convinced why you can't separate signaling and call control. The charter prejudges a design decision on coupling. I would like the freedom to separate it. Cullen - many of us believe that the media follows signaling - for LB, leveraging the HTTP environment. It won't be a change acceptable to many people. ekr - are the current documents only outgoing calls? Will the WG specify incoming and outgoing calls? Mo - yes. Questions about Charter slide 2/4 ekr - lets not enshine OAuth for all eternity - remove the parenthetical. Colin Perkins - I agree that we don't represent all of SIP. Need to clarify what we want to replicate and avoid scope creep. jdr - I looked at 3261-5, so much of what's in those are replaced in the draft. You'll be shocked that it's not that hard to cover all of it. It's subsumed by lower layers. RTP is a different story. Colin - I'm nervous because I saw how the PTSN interops creeped into SIP. jdr - IMS headers are out of scope for instance. RjS - an example of what Colin may be worried about - one-way media app - a requirement to insert the appropriate commercial at the appropriate time - cutting out foul words. Protect against that in the charter. jdr - can be handled at the app layer, not here. Do you have words to suggest? RjS - not in real-time. Bernard - There's a lot of different problems in the charter, maybe choose one of those big problems to solve. Cullen - they are deeply tied together - for instance e2e encryption. Questions about Charter slide 3/4 Sanjay Mishra - commenting about 2/4, be more explicit about utilizing STIR. Martin - take to list. ekr - Implemented in C++ or javascript in the browsers. Cullen - depends on whether webtransport exists. ekr - assume it does. Justin - we don't need 4 dev teams to implement it. ekr - good theory. One theory - used in unmodified web browsers. Justin - if you have webtransport and codecs, you have everything you need to make this work. ekr - if that a nice to have or a design requirement? Justin - should be implmentable by javascript with nothing more than webtransport and web codecs. mnot - if it's available to the browser without mods, what stops the robocalling? If I can just write some javascript... Are the servers going to have the discipline to deal with any browser making a call. Cullen - they'll want to figure out how to authorize that. jdr - client to server media makes this easier. You connect to the server, that's where you send stuff. Questions about Charter slide 4/4 Mirja - webtransport is the worst dependency, is it a strong dependency. Cullen - only a dependency on how it reflects up into the browser. Dependency is vague here. But we are very dependent on QUIC. Mirja - you need a connection mode that's not HTTP that's on top QUIC. Cullen - Harald - will list the w3c groups that will liaise with? Cullen - yes, send me text? Harald - yes. lnx - ICE working group is closed - strike the mention from the charter. Victor - Vasiliev - I'm not concerned about the dependency. Can help inform design choices in webtransport - it's an advantage. Deliverables slide E2E crypto slide ekr - this sin't adequate - it's table stakes now. Has to say e2e by default and spec the keying. Cullen - fine with MLS for keying? ekr - don't think we should define today. Cullen - HTTP end to end? ekr - I'm lost Cullen - the end2end is client and server - a data center trying to send to an asr. SIP trunking use cases. ekr - there are people at the end of the trunking calls and what them to have encryption. Cullen - this mandates TLS. ekr - is it a problem to have encryption here? I want to avoid to the case where were in the clear on the server. Cullen - I don't have a problem with that. e2e is one thing, e2e keying is another, and e2e identity is another. Need to solve all of that. Propose text. roni even - lnx - the "allow for" in this sentence is really vague. ekr pasted text in the jabber room. jdr - e2e encryption is not the same as p2p media (?) calls to the ptsn doesn't not have e2e encryption, but I don't want a solution that is only browser based. Do not do the keying in this protocol. ekr - that does not work for me. I don't want this protocol to be a promise for future. encrypted to the pstn gateway. I'll take this offline, but I want to be clear. Cullen - you want the WG to do the keying protocol. ekr - I hope we can point at one. Victor - there's many layers to this protocol. Emphasize transporting media over http over cloud are not related to voice - e2e encryption doesn't make sense. Justin - this is a hop by hop protocol, what does e2e encryption even mean. (something about keys not exposed to javascript) Richard - +1 ekr. hbh - need your media thing to carry things that used to negotiate keys. by default. We will need to point to some key negotiation protocol. If we can solve Cullens 1st two points, identity can come later. P2P media slide Harald - I agree with Cullen. I'll add to bonfire of not doing p2p - doesn't have server identity or barely identity, leaving it out scope - makes it clearer. ekr - I'm not on board with this. Given that we're having centralized servers falling over, why are we're pitching it? Should have p2p media. Ted Hardy - +1 ekr Colin - +1 ekr if we don't do p2p, we need packetization here so we can add it later. Harald - motivation talks about deployments in the data centers. This proposal is client-server. Justin - we can look at p2p media when the protocol is more well developed. client-server can upgrade later. later can support ript over ice for p2p. bernard - http3 datagrams. if p2p - raw quic and quic datagrams - very different things. if rtp over datagrams, it works for http3 datagrams (?) ------------------------------------------------------------------------ BoF Questions [Chairs] 15m mnot - http makes on the control side, but falling back won't work the way think - need wiggle room in charter. Fail hard or fall back? watson - gap between semantics in HTTP and demands of connecting 2 clients to the same server - seems they are in conflict. spencer - What's in the current charter - slam dunk to make it work. Make a list of your dependencies if this is supposed to be short term deliverable. I hope you learn things about media over quic that we can use in a lot of different places. Hope you think about the general case of media or quic. jdr - we have a ton of use cases that are client-server. Don't want to solve for a use case that we already have something that does it well - webrtc. magnus - the media transport can be separated but could still fate sharing. Don't repeat rtp's mistake with the media model. Or you will miss things. Mo - lot of energy to do some work here, lot of questions about scopes and dependencies - premature to resolve all the charter issues today. Is there's a substantial amount of energy? any objections - other solutions or ... martin - who wants to put in an effort on this - +1 in webex chat. If it's a bad idea - go to the mike queue. mnot - I figure there will be a discussion on the charter. martin - yes. Jared - trying to keep the scope contained. We can end up in the ditch. Mo - keep the discussion going on the list. ~~~ ********************************************************************* Agenda & Minutes from Etherpad ********************************************************************** XMPP channel: ript@jabber.ietf.org Administrivia [Chairs] 10m Problem Statement [Jonathan R.] 15m High Level Protocol summary [Jonathan R.] 15m Implementation Experiences at Google [Justin U.] 15m Freeswitch use cases and needs [Anthony M.] 10m Charter review and questions [Cullen J.] 30m # Chair slides - 🪑🪑 https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-chair-slides # Problem Statement and summary - Jonathan Rosenberg https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-problem-statement-protocol-summary Questions Mark Nottingham: Concern about positioning - draft talks about communication as application .. but it seems to be highly dependent on HTTP/3. However, much of the public cloud infrastructure hasn't upgraded to HTTP/2 yet. Many are still running HTTP/1. Once they move to HTTP/2, they may be there for a while. Questions dependency on HTTP/3 and timelines. Also noted that "HTTP/3 Support" by a cloud provider might initially only be on the front-end, but support will be needed in the rest of the infrastructure 2nd comment - draft talks about "byways" that include 20 different GETs. That will not interact well with some of existing infrastructure. You're really talking about WebTransport. It will not be easy to get this right. JDR: We'll have to understand if people want this to work on HTTP/1, HTTP/2, etc Jared Mauch: RTP is relatively efficient to carry a G.7ll/ulaw. Do we know how much additional overhead this will add with HTTPS and all additional HTTP headers? JDR: We need to test this. It will be more than RTP. There will be use cases where this will be okay. EKR: These drafts make assumptions about what parts of the ecosystem are variable and invariable. Assumes that some things will change, while others will not. Need to discuss this more. JDR: Justin Uberti: Current situation is that you have to build everything David Schinazi: Webransport is about making datagrams available to JavaScript, within the browser security model; if you don't need that, you probably don't need Webtransport # Implementation experience - Justin Uberti https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-rtc-implementation-experiences Harald Alvestrand: Had mic issue, but question was basically "can you confirm that all these advantages require a datacenter at one en?" # Freeswitch use case and needs - Anthony Minnesale https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-freeswitch-perspective Freeswitch is one of the likely implementers of RIPT if this work goes forward. No questions # go get RIPT - Suhas Nandakumar https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-go-ript-codebase Experience of implementing RIPT in Go Watson Ladd: Were you able to get two servers communicating together? Suhas: Not yet. This was just basic work. # Charter discussion - Cullen Jennings https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-charter-discussion ## Charter Slide 1 of 4 EKR: Slide doesn't mention HTTP/2. Needs to say something about what you do when you don't have UDP penetration? (firewall blocks UDP) Cullen: There are use cases that don't need HTTP/2. We need to have some kind of fallback. Mark Nottingham: Problem with specifying a version of HTTP is that you cannot control entire chain of connections. You have to be pessimistic and expect that you may have to fall back to HTTP/1. JDR: Suggests text like "operating on top of HTTP but optimized for HTTP/3" Stephan Wenger: (inaudible) James Gruessing: We should think of use cases beyond telephony. Also could be used for broadcasting. Cullen: Broadcast hasn't driven requirements here because there are simpler protocols for that use case. Should clarify that this is for both "unidirectional" and "bidirectional" realtime communications. Harald Alvestrand: Are we building a system that HAS to pass the media over HTTP? Or not? Has a hard time seeing that working over HTTP/1. Stephen Wenger: Would prefer to have separation between media transport and signaling / call control. Not convinced by discussions on the list. Charter has prescribed a unified solution, would prefer that the option is there to separate the two? Cullen: "Signalling follows the media" is a tenant believed by the proponents, for leveraging HTTP environment, load balancers, etc. Bernard Aboba: (waiting until later) EKR: Is the intent to specify both incoming and outgoing calls in this working group? Mo Zanaty: yes ## Charter Slide 2 of 4 EKR: Thinks the parenthetical phrase "notably OAuth" should be removed. Cullen: agreed Colin Perkins: Agree you don't want to replicate all of SIP. Past attempts had had a great amount of scope creep. We should be clear on what features of signaling we DO want to replicate. JDR: Researched current SIP and extensions... found that much of what is needed has been subsumed by lower layers of HTTP. Colin: Just concerned about scope creep. Watched PSTN features creep into SIP. JDR: Thinks it will be okay. Robert Sparks: Provides example - "foul word removal service" - Charter protection JDR: Thinks the extreme case would not be in current text. Would be very open to suggestions of text? Bernard Aboba: There are a lot of different problems to solve in this Charter. Thinks you need to choose which problem to solve. Cullen: sees all the problems as intertwined Sanjay Mishra: Suggests that maybe mentioning using STIR for call identification ## Charter Slide 3 of 4 EKR:.... is this browsers or applications that run in browsers? (I will give you WebTransport in the browser for the purposes of this discussion) Justin: Need to make this available to more applications, including web applications; once we have webtransport and webcodecs, that should be enough (modulo some small tweaks to existing primitives) EKR: We need to make sure we have what we need. Justin: "should be implementable in JavaScript using WebTransport and basic primitives" Mark Nottingham: If this is available from browsers without modification, what does that say about the threat model? If this is in every browser, could someone just make phone calls? Would this be used by advertisers/spammers? Cullen: how is this different from WebRTC? Mark: WebRTC has API and spent great amount of time on authorization. Difference in scale. JDR: This is why unified signaling and media is beneficial - there's no ability to send media to a different place (for DOS attacks). Uses the web security model. ## Charter Slide 4 of 4 Mira Kuehlewind: what is the dependency on WebTransport? Cullen: May or may not have a dependency based on direction the protocol evolves. Harald Alvestrand: Do you want to list the W3C efforts you will need to liase with? Cullen: Yes, we do. Can you please send text? Jonathan Lennox: remove "ICE" because it has been folded back into "MMUSIC" Victor Vasiliev: NOT concerned about dependency. Thinks it is good that WebTransport be designed with RIPT as a consumer of WebTransport ## Deliverables slide ## E2E Crypto EKR: It should say that E2E is required by default and to specify the keying. Cullen: Are you okay with MLS? EKR: I don't think that should be in the charter. [In Jabber chat, EKR proposed "The protocol will provide for E2E media ancryption by default and specify a mechanism for establishing the keys for that encryption"] Roni Even: What is the requirement (couldn't understand)? Jonathan Lennox: The "allow for" in this wording is awfully vague. JDR: Be clear that E2E is not P2P media. A common use case is making a call to the PSTN, and there's no e2e encryption there. Doesn't want to be locked into situation where it only worked between browsers. Also, JDR doesn't want to invent another keying protocol. EKR: That wording would NOT work. Doesn't want to make a promise that can't be kept. Wants e2e. For PSTN case, wants e2e to PSTN gateway. Cullen: Do you want working group to do the keying protocol? EKR: Want group to *specify* the keying protocol. Victor Vasiliev: There are MANY layers here. Many cases for transfering media in the cloud are not related to telephony. Ex. of sending media to a cloud transcription service.. e2e encryption doesn't matter there. Justin Uberti: Since this is a hop-by-hop protocol, it's not clear to me what e2e encryption means. Does think it makes sense to support MLS. But given that everything is sent over TLS, not clear on need for additional encryption wrapper. Richard Barnes: +1 to EKR and e2e being on by default. Will need some kind of key negotiation protocol. Thinks that identity can be solved later. ## Open Issue #1 - P2P media - Is P2P media in or out? Harald Alvestrand: No we shouldn't do P2P. Multiple reasons - P2P doesn't have server identity, but HTTP security models rely on server identity. Should say explicitly that this is only for client/server model. EKR: Finds it ironic that when centralized conferencing systems are falling over, we are arguing for centralized. Thinks that protocol SHOULD have facilities for P2P media. Ted Hardie: +1 to EKR and having P2P media in scope Colin Perkins: +1 to EKR ... if we don't do P2P media, we'll want packetization, which is similar.. Harald Alvestrand: All motivation slides talk about data center deployment. This particular proposal is client/server and should be allowed to just be that. Justin Uberti: We can look at P2P after protocol evolves. Start with C/S and evolve to P2P. Bernard Aboba: Presentation is really all about HTTP/3, which would not be used in P2P ## General discussion Mark Nottingham: I understand why HTTP/3 is being used, but I think for media there will be problems. Charter should allow for flexibility and needs more thought about use for media. Watson Ladd: It seems to me that the inherent properties of each system are in conflict. (References discussion in jabber chat.) Spencer Dawkins: Need to make a list of the things you depend upon that are not there yet (if this is a short-term deliverable). I hope you all find out things about media over QUIC that we can use in lots of other places. I hope you will be thinking about general case of media over QUIC. Mo Zanaty: (he will take his to the list) JDR: Don't let massive scope be the enemy of getting something done. We have a ton of people trying to solve for media processing in the cloud. In favor of deferring P2P and all the problems that come with it. Magnus Westerlund: Think the media transport work can be separated - and should be. Media over HTTP/3 or QUIC will be needed in other places and should not be tightly linked to signaling. Multiparty transport will also be something you need to deal with. # BoF questions - Chairs Mo: Questions about scope, ambiguities means we can't create charter today, but there is obviously energy. Are you willing to do the necessary work? (Put "+1" into WebEx chat - many people do) Mark Nottingham: will the charter be further discussed? Or will the IESG come up with something? Martin: the charter WILL be further discussed and modified on the list Jared Mauch: keeping scope narrow enough to keep people engaged will be challenge. Even if everyone is well-intentioned, there is plenty of room for scope creep. ********************************************************************** Bluesheet - Sign with your name and affiliation The NOTE WELL statement applies to this meeting. Participants acknowledge that these attendance records will be made available to the public. ********************************************************************** Anthony Minessale, SignalWire / FreeSWITCH Bernard Aboba, Microsoft Corporation Mo Zanaty, Cisco Ciprian Dosoftei, Independent Watson Ladd, Cloudflare Marwan Fayed, Cloudflare Colin Perkins, University of Glasgow Barry Leiba, FutureWei Hirochika Asai, Preferred Networks / WIDE Project Mary Barnes, MLB@Realtime Communications, LLC Spencer Dawkins, Tencent America Bernie Hoeneisen, Ucom.ch / pEp Foundation Stephan Wenger, Tencent Sean Turner, sn3rd patrick mcmanus, fastly Steven Fuerst, F5 Networks Mark Baushke, Juniper Networks, Inc Cullen Jennings, cisco Suhas Nandakumar, cisco Yasuo Okabe, Kyoto University Hirochika Asai, Preferred Networks / WIDE Project tim costello, BT Monika Ermert, eLance Jonathan Lennox, 8x8 / Jitsi Martin Duke, F5 Networks chi-jiun su, hughes network systems Peter Wu, Cloudflare Danile Migault Cathy Aronson, ARIN Matthew Miller, Mozilla Adam Roach, Mozilla Ben Kaduk, Akamai Harald Alvestrand, Google Ross Finlayson, Live Networks James Gruessing, BBC Jared Mauch, Akamai Shuai Zhao, Tencent Dan York, Internet Society Nigel Weinronk, Gamma Robert Sparks, AMS Takahiro Nemoto, Tokyo University of Agriculture and Technology Rohit Abhishek, Tencent Jean Mahoney, AMS Steve Donovan, Oracle Mitsuaki Hatano Karl Kathuria, Internews Alexey Melnikov, Isode Ltd Andrew Gallant Magnus Westerlund, Ericsson Jörg Ott, TUM Jeongseok Kim, SK Telecom Roni Even James Hamlin, Private Individual Roland Schott, Deutsche Telekom Sanjay Mishra, Verizon Jon Peterson, Neustar Ben Campbell, Independent Rob Wilton, Cisco Pat White, Five9 Ash Wilson, Valimail Bo Burman, Ericsson Warren Kumari, Google. Godfred Ahuma, Packetfile David Schinazi, Google Russ Housley, Vigil Security LLC John Border, Hughes Roland Jesske, Deutsche Telekom Ted Hardie, Google Karen O'Donoghue, Internet Society John Mah, NortonLifeLock Simon Hicks,DCMS Peter Yee, AKAYLA Lucas Pardue, Cloudflare Rifaat Shekh-Yusef, Avaya Eric Rescorla, Mozilla Alissa Cooper, Cisco Guru Somadder, Google Hiroyuki Goto, Gree Christer Holmberg, Ericsson Charles Eckel, Cisco Yuji SUGA, IIJ/CELLOS consortium Kelly Veit, Google Zaheduzzaman Sarker, Ericsson Grant Taylor, Self Jim Reid, rtfmllp Gabriel Montenegro, Microsoft Mirja Kühlewind, Ericsson Mark Nottingham, Fastly Richard Barnes, Cisco Carsten Bormann Pete Resnick, Episteme Chris Wendt, Comcast Steve Todd, Independent Bhumip Khasnabish Leif Sawyer, GCI Communications Mayumi Ohsugi, NTT Wilhelm Wimmreuter (williw) InCharge Systems Inc. Jonathan Rosenberg, Five9 Subir Das, Perspecta Labs Abdussalam Baryun, University of Tripoli Erik Kline, Loon LLC