Subject: [V3] Thoughts on scope for ript

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Mar 2020 14:21:00 +0000

With our BoF coming up this Thursday, I thought the time is right to restart discussions with a focus in particular on SCOPE of the effort.

For me its defined entirely by the GOAL. The goal is:

It is possible to implement a ript server in public cloud, such that it is nothing more than a web application as far as public cloud is concerned, and therefore works with web-centric features such as Kubernetes, global http load balancers, and service meshes - to name a few. The server implements everything needed to make and receive voice and video calls.

I do think the scope needs to be inclusive of server to server peering, not just client to server. The client-to-server stuff defines the core, but for me I'm really interested in building an alternative to sip trunking and that requires solving for additional things (inbound load balancing, inbound authentication, number routing). I think those can easily be in a separate draft but I think they should be in scope.

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2020 07:49:19 -0700

Hi Jonathan,

As I said in my review [0] I don't think that the current draft achieves
this, and I think it's lead to a number of fairly misguided design
decisions (with byways being perhaps the most obvious).

More to the point, the future is bigger than the past. H3 is not widely
deployed yet, and so we should think about how we want things to look, not
tie ourselves in knots trying to fit the precise current environment copied
onto H3.

-Ekr

[0] https://mailarchive.ietf.org/arch/msg/v3/V2BuGEZJpEMcAKcYLNHDMtV3i70/

On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg <[email-masked]>
wrote:

> With our BoF coming up this Thursday, I thought the time is right to
> restart discussions with a focus in particular on SCOPE of the effort.
>
> It is possible to implement a ript server in public cloud, such that it is
> nothing more than a web application as far as public cloud is concerned,
> and therefore works with web-centric features such as Kubernetes, global
> http load balancers, and service meshes - to name a few. The server
> implements everything needed to make and receive voice and video calls.
>
> I do think the scope needs to be inclusive of server to server peering,
> not just client to server. The client-to-server stuff defines the core, but
> for me I'm really interested in building an alternative to sip trunking and
> that requires solving for additional things (inbound load balancing,
> inbound authentication, number routing). I think those can easily be in a
> separate draft but I think they should be in scope.
>
> Thx,
> Jonathan R.
>
> --
> Jonathan Rosenberg
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential information of Five9 and/or its affiliated entities. Access by
> the intended recipient only is authorized. Any liability arising from any
> party acting, or refraining from acting, on any information contained in
> this e-mail is hereby excluded. If you are not the intended recipient,
> please notify the sender immediately, destroy the original transmission and
> its attachments and do not disclose the contents to any other person, use
> it for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Five9 and/or its
> affiliated entities.
>
> --
> V3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v3
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Mar 2020 10:09:22 -0700

In addition to Eric's comments, I think the biggest question regarding
goals and scope is whether we focus on both client-to-server and
server-to-server.

If we are taking a fresh look at how all of IP calling works, we could find
ourselves looking at:
a) a replacement for SIP "RPCs" (i.e, how are commands reliably exchanged)
b) a replacement for SIP operations and routing (i.e., the specific
commands and routing mechanisms)
c) a replacement for offer-answer (i.e., how do both sides agree on media
formats)
d) a replacement for SDP (i.e., the details of how media formats are
described)
e) a replacement for SRTP (i.e., how media is transmitted from point A to B)
f) a replacement for RTP packetization (i.e., how media is encapsulated
when transmitted)

I think that server-to-server, essentially a NNI, requires us to consider
all of these items, and that may ultimately make sense. However, if we
focus initially on client-to-server, we can get by by only focusing on e)
and f), as a-d) are under application control

This could still provide a lot of value, since moving to a world where even
private RTC services can be built atop HTTP would still be quite an
accomplishment. (Compared to the current state of the world, where people
deploying cloud RTC services need to source and deploy their own
ICE/DTLS/SCTP/SRTP stacks and all the load
balancing/authentication/failover tech that Jonathan mentions). It would
also be complementary to WebRTC, which works pretty well for p2p
applications, but struggles in c2s environments for the aforementioned
reasons.

---

From: Anthony Minessale <[email-masked]>
Date: Mon, 23 Mar 2020 17:22:31 -0500

Also more consideration for live translation to sip/rtp/webrtc and
back-to-back scenarios.

If calls are being loaded balanced to many servers you still probably will
want a way to keep track of what calls are on what server in a way that
goes out of scope of HTTP so the application doing the clustering will bear
a pretty big burden of solving that problem from behind the cluster.

I read the memo about replacing SIP and was slightly disturbed that RFC2833
(4733/4734) is the one thing salvaged ;)
That would be the first to go IMHO, its the leading cause of interop issues
in all of telephony and very rarely implemented to its full potential not
to mention there are some timestamp translation issues I pointed out on the
github discussion so that is it's own can of worms.

Also, the description seems to be evolving more towards considerations
about making calls behave like a web app which is fine because that's the
GOAL but there is little consideration of actual trunking so far.  SIP
trunking is just a made-up marketing term to mirror original TDM trunking
which was actual trunking (bundling many calls into one stream to reduce
overhead) In reality SIP trunking is often just (a lot of SIP calls) We
have our SIP setup so you can send many calls to many different phone
numbers over a single registration and that causes introp issues because
most people don't comprehend this lol.

So it seems like there could be some improvements that could clean up
issues with WebRTC and how web-app type environments can bust through nat
etc.
WebRTC is still compatible with SIP in the sense that you can carry a
WebRTC SDP over sip and set up calls but most of the time its SIP over
WebSockets (though FS and Kamailio can translate and negotiate WebRTC
sessions to other SIP transports)

>From a server perspective with density being a major concern, removing all
the need for dialogs and route headers is a good thing. What I also think
is critical to preserve is the server's ability to limit the media formats
etc sent by the sender.  Killing Offer/Answer is ok but the replacement
should at least preserve the notions that a client can offer what it can
do, the server can narrow that scope with its own requirements and the
client must work within those shared formats.  The server is the one who
has to create thousands of connections etc and must not be treated as a
simple peer-to-peer agent.

Removing SRTP is another concern because it's pretty widely used now, it's
required in WebRTC and decryption in the middle was something I was hoping
we would go the other direction on and find ways to route encrypted packets
without needing to decode them.

I think if you want to replace SIP trunking more considerations have to be
made for the mass translation of TDM/SIP/SS7 and how that works with
routing and clustering.  I think some of that is how we got into that boat
with SIP because it was only later that this was tried and then workarounds
abounded for years.

On Mon, Mar 23, 2020 at 12:09 PM Justin Uberti <juberti=
[email-masked]> wrote:

> If we are taking a fresh look at how all of IP calling works, we could
> find ourselves looking at:
> This could still provide a lot of value, since moving to a world where
> even private RTC services can be built atop HTTP would still be quite an
>> It is possible to implement a ript server in public cloud, such that it
>> is nothing more than a web application as far as public cloud is concerned,
>> affiliated entities..

-- 

Anthony Minessale  | Founder and CEO

SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303
<https://maps.google.com/?q=228+Hamilton+Ave+3rd+Floor,+Palo+Alto,+CA+94303&entry=gmail&source=g>*

*https://youtu.be/WKjZkzgK4pc <https://youtu.be/WKjZkzgK4pc>*

https://youtu.be/MwqpSl7luSM

https://youtu.be/l82JtCECkog <https://www.youtube.com/watch?v=l82JtCECkog>

Email: [email-masked]

Phone: 262-309-8501

Website: <https://www.freeswitch.com/>https://www.signalwire.com
<https://www.facebook.com/search/top/?q=signalwire>
<https://twitter.com/SignalWire>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Mar 2020 15:43:00 -0700

On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale <[email-masked]>
wrote:

> I read the memo about replacing SIP and was slightly disturbed that
> RFC2833 (4733/4734) is the one thing salvaged ;)
> That would be the first to go IMHO, its the leading cause of interop
> issues in all of telephony and very rarely implemented to its full
> potential not to mention there are some timestamp translation issues I
> pointed out on the github discussion so that is it's own can of worms.
>

> without needing to decode them.

One reason we are focusing on client-to-server vs peer-to-peer is that it
avoids the interop issues associated with p2p (i.e., the difference between
connecting to the server that you control vs various peers that you don't
control). Also, WebRTC already works well for the peer-to-peer case.

I also think that whatever we come up with to replace SRTP will probably be
able to gateway to SRTP easily for systems that expect SRTP.

>>> affiliated entities...
> Phone: 262-309-8501 <(262)%20309-8501>
>

---

From: Anthony Minessale <[email-masked]>
Date: Mon, 23 Mar 2020 18:38:24 -0500

On Mon, Mar 23, 2020 at 5:43 PM Justin Uberti <[email-masked]> wrote:

>> If calls are being loaded balanced to many servers you still probably
>> will want a way to keep track of what calls are on what server in a way
>> that goes out of scope of HTTP so the application doing the clustering will
>> bear a pretty big burden of solving that problem from behind the cluster.
>>
>> From a server perspective with density being a major concern, removing
>> all the need for dialogs and route headers is a good thing. What I also
>> think is critical to preserve is the server's ability to limit the media
>> formats etc sent by the sender.  Killing Offer/Answer is ok but the
>> replacement should at least preserve the notions that a client can offer
>> what it can do, the server can narrow that scope with its own requirements
>> and the client must work within those shared formats.  The server is the
>> one who has to create thousands of connections etc and must not be treated
>> as a simple peer-to-peer agent.
>>
>> Removing SRTP is another concern because it's pretty widely used now,
>> it's required in WebRTC and decryption in the middle was something I was
>> hoping we would go the other direction on and find ways to route encrypted
>> packets without needing to decode them.
>>
>

As a server, I appreciate that because it makes scaling much easier to have
the power to dictate things.

>
> I also think that whatever we come up with to replace SRTP will probably
> be able to gateway to SRTP easily for systems that expect SRTP.
>

>> I think if you want to replace SIP trunking more considerations have to
>> be made for the mass translation of TDM/SIP/SS7 and how that works with
>>> c) a replacement for offer-answer (i.e., how do both sides agree on
>>> media formats)
>>> I think that server-to-server, essentially a NNI, requires us to
>>> consider all of these items, and that may ultimately make sense. However,
>>> if we focus initially on client-to-server, we can get by by only focusing
>>> on e) and f), as a-d) are under application control
>>>
>> https://youtu.be/l82JtCECkog
>> <https://www.youtube.com/watch?v=l82JtCECkog>
>>

-- 

Phone: 262-309-8501

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 25 Mar 2020 11:30:46 -0400

I would like to second Justin's point here about the value of a
client-server RTP streaming by itself (e-f, though in-band c-d are also
valuable).  There's a lot of value in the world where I can take an HTTP
URL to some endpoint in the cloud and give it to, say, an IoT camera device
to use as a realtime media sink, or pass it to an off-the-shelf streaming
library to show a realtime media source on screen.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 25 Mar 2020 11:27:51 -0500

This is interesting ...

> library to show a realtime media source on screen.

I know most of my own concerns about RIPT media have started out with "this
won't be as good as RTP for media", but what I've been getting from RIPT
discussions is, that may not matter as much as I expected.

For a use case like Victor's, great media quality would be great, but good
enough media quality may be ... good enough.

Am I putting words in the mouths of the proponents?

Best,

Spencer

---

From: Anthony Minessale <[email-masked]>
Date: Wed, 25 Mar 2020 11:53:57 -0500

On Wed, Mar 25, 2020 at 11:28 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> I know most of my own concerns about RIPT media have started out with
> "this won't be as good as RTP for media", but what I've been getting from
> RIPT discussions is, that may not matter as much as I expected.
>
Being "as good as RTP" is relative and so is "quality" There is quality
like how it sounds and quality like (how many packets did I get that I am
supposed to be getting and are they on time, are they dejittered and are
they dropped when they are too old)
If the media signal is in good shape then the second type makes all the
difference in preserving that.

One thing about RTP that is helpful but often not taken advantage of is
that you can pass it through as is even out of order and messed up and the
final thing to receive the stream can put things back together.
If something in the middle just cleanses it and rewrites all the timestamps
you get a permanently messed-up stream that can never be fixed.
Sometimes you want to dejitter and rewrite the packets when you know the
next hop has no way to do it but otherwise usually only when you are the
final terminating leg.

Everything RTP can do to make sure you have these features should be
duplicated or maybe an encapsulation mode to just carry old school RTP as a
payload so 2 aincent devices can still exchange RTP across a RIPT-wormhole.

-- 

Phone: 262-309-8501

---

From: Justin Uberti <[email-masked]>
Date: Wed, 25 Mar 2020 09:55:28 -0700

On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Some applications may tolerate somewhat lower quality in fallback
scenarios, but I think we should be aiming for RTP performance with HTTP
ease of deployment.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 25 Mar 2020 14:25:45 -0500

Replying to Justin, after reading Victor's reply - thank you both for
replying ...

On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <[email-masked]> wrote:

>> For a use case like Victor's, great media quality would be great, but
>> good enough media quality may be ... good enough.
>>

I was actually hoping that wasn't the case, because ISTM that the question
whether RTP performance over HTTP is possible/likely is going to suck up a
LOT of the discussion time during the BOF ...

Best,

Spencer

---

From: Justin Uberti <[email-masked]>
Date: Wed, 25 Mar 2020 12:31:37 -0700

> LOT of the discussion time during the BOF ...

To Eric's point, "H3 is not widely deployed yet, and so we should think
about how we want things to look". I think it's entirely possible to
achieve RTP performance over H3, and hopefully also have a reasonable
fallback when only H2 is available.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 25 Mar 2020 19:37:59 +0000

Hi Justin, all:

From: V3 <[email-masked]> on behalf of Justin Uberti <juberti=[email-masked]>
Date: Wednesday, March 25, 2020 at 12:32
To: Spencer Dawkins at IETF <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>, Jonathan Rosenberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [V3] Thoughts on scope for ript

On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
Replying to Justin, after reading Victor's reply - thank you both for replying ...

On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
This is interesting ...

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasilvv=[email-masked]<mailto:[email-masked]>> wrote:
I would like to second Justin's point here about the value of a client-server RTP streaming by itself (e-f, though in-band c-d are also valuable).  There's a lot of value in the world where I can take an HTTP URL to some endpoint in the cloud and give it to, say, an IoT camera device to use as a realtime media sink, or pass it to an off-the-shelf streaming library to show a realtime media source on screen.

I know most of my own concerns about RIPT media have started out with "this won't be as good as RTP for media", but what I've been getting from RIPT discussions is, that may not matter as much as I expected.

For a use case like Victor's, great media quality would be great, but good enough media quality may be ... good enough.

Some applications may tolerate somewhat lower quality in fallback scenarios, but I think we should be aiming for RTP performance with HTTP ease of deployment.

I was actually hoping that wasn't the case, because ISTM that the question whether RTP performance over HTTP is possible/likely is going to suck up a LOT of the discussion time during the BOF ...

To Eric's point, "H3 is not widely deployed yet, and so we should think about how we want things to look". I think it's entirely possible to achieve RTP performance over H3, and hopefully also have a reasonable fallback when only H2 is available.

[Stephan]: many video conferencing technologies (including Vidyo, Zoom), have previously, or are currently supporting http-based media transport, often for years or even decades.  They are almost never enabled by any professional deployer, because the resulting QoS is user-perceived as so bad that the marketing guys decided that offering no video/voice (and instead make people pick of the phone) is better for product reputation than offer the degraded QoS.
Do any of you guys have hard numbers what sort of delay h3-based transport can achieve on today’s infrastructure?

---

From: Justin Uberti <[email-masked]>
Date: Wed, 25 Mar 2020 12:49:55 -0700

On Wed, Mar 25, 2020 at 12:38 PM Stephan Wenger <[email-masked]> wrote:

> Hi Justin, all:
>
>
>
> *From: *V3 <[email-masked]> on behalf of Justin Uberti <juberti=
> [email-masked]>
> *Date: *Wednesday, March 25, 2020 at 12:32
> *To: *Spencer Dawkins at IETF <[email-masked]>
> *Cc: *Victor Vasiliev <[email-masked]>, Jonathan Rosenberg <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [V3] Thoughts on scope for ript
>
>
>
>
>
>
>
> [Stephan]: many video conferencing technologies (including Vidyo, Zoom),
> have previously, or are currently supporting http-based media transport,
> often for years or even decades.  They are almost never enabled by any
> professional deployer, because the resulting QoS is user-perceived as so
> bad that the marketing guys decided that offering no video/voice (and
> instead make people pick of the phone) is better for product reputation
> than offer the degraded QoS.
>

With H3 we have lots of options; there are lots of details to work through
here but given that the substrate is QUIC there is no theoretical reason
why RTP performance isn't possible.

Regarding HTTP media transport in existing products (i.e., non-H3), you are
correct that there are indeed limitations and as such providers do what
they can to avoid this option, but it is nowhere near as grim as you make
it out to be. Recall that the first web version of Zoom exclusively used
websockets for transport <https://webrtchacks.com/zoom-avoids-using-webrtc/>
.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Mar 2020 12:56:20 -0700

On Wed, Mar 25, 2020 at 12:52 PM Justin Uberti <juberti=
[email-masked]> wrote:

>> I was actually hoping that wasn't the case, because ISTM that the
>> question whether RTP performance over HTTP is possible/likely is going to
>> suck up a LOT of the discussion time during the BOF ...
>>
>>
>>
>> Do any of you guys have hard numbers what sort of delay h3-based
>> transport can achieve on today’s infrastructure?
>>
>
> Regarding HTTP media transport in existing products (i.e., non-H3), you
> are correct that there are indeed limitations and as such providers do what
> websockets for transport
> <https://webrtchacks.com/zoom-avoids-using-webrtc/>.
>

I mostly concur with Justin here: I would expect QUIC (which is to say
probably H3 + Datagram) to be roughly comparable to RTP [0]. Anything over
TCP will obviously be non-awesome, but we already do have some nontrivial
fraction of media going over TCP to TURN relays, so it's not like it
doesn't work at all, especially in good network conditions.

-Ekr

[0] There are some open issues with how QUIC congestion control and the
media rate control interact, but I imagine they are mostly soluble.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 25 Mar 2020 13:18:24 -0700

On Wed, Mar 25, 2020 at 12:58 PM Eric Rescorla <[email-masked]> wrote:

> [email-masked] <[email-masked]>> wrote:
>
>>
>>
>> With H3 we have lots of options; there are lots of details to work
>> through here but given that the substrate is QUIC there is no theoretical
>> reason why RTP performance isn't possible.
>>

Yes, the CC stuff is one of the details I was thinking of. The other main
one is the right abstractions in cloud providers to allow more direct
access to the underlying transport.