Minutes IETF107: ript
minutes-107-ript-00

 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

<no questions>

------------------------------------------------------------------------
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 - <flailing here>

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

<no comments>

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 - <hard to follow audio>

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