Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Feb 2020 22:00:02 +0000

Good news folks - RIPT bof was approved for IETF107 and we'll be meeting. Goal is to try and get a WG formed. As such, charter discussion is in order. Cullen, myself and Justin worked a draft charter. Comments please:

This working group will standardize a protocol, capable of operating
atop HTTP/3, which supports real-time voice and video communications,
including signaling, media negotiation, and transmission of media
packets.

The primary rationale for this new protocol is to enable deployment of
real-time communications services on modern "cloud" systems. These
systems are built around HTTP, and for HTTP-based applications, they
enable load balancing, HA, auto-scaling, and so on. However, real-time
communications protocols are based on SIP and RTP, and they cannot take
advantage of these HTTP-based capabilities.

It is a non-goal of this working group to replicate all of SIP and its
many extensions into HTTP. The group will limit itself to supporting the
functionality in widespread actual usage today.

The protocol uses HTTP techniques for authentication and authorization
(notably OAuth), and requires hop by hop encryption (i.e., https). The
protocol will also allow for e2e media encryption, although keying is
out of scope, and is expected to be handled by other protocols such as
MLS. This extension will also utilize STIR for callerID.

This protocol should be implementable in browsers, thick desktop
clients, mobile apps and servers.

The group will standardize an extension to the baseline protocol that
automates the configuration necessary to achieve calling between on
organization which is a customer of the other (for example, enterprise
to service provider).

[OPEN ISSUE: Is P2P media in or out? If in, ICE or something else ?]

The group will do its work in conjunction with active software
development efforts, so that implementation experience feeds directly
into protocol development.

The group will coordinate with the Webtranport, QUIC, HTTPbis and STIR
working groups.

Milestones:

Dec 2020: Submit baseline protocol to IESG
Mar 2021: Submit autoconfiguration protocol to IESG

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: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Feb 2020 17:55:42 -0600

Hi, Jonathan,

Thank you for this e-mail, and especially for the one describing the four
drafts that describe what you're thinking of.

I have one point of confusion, inline below.

On Fri, Feb 14, 2020 at 4:00 PM Jonathan Rosenberg <[email-masked]>
wrote:

> Good news folks – RIPT bof was approved for IETF107 and we’ll be meeting.
> Goal is to try and get a WG formed. As such, charter discussion is in
> order. Cullen, myself and Justin worked a draft charter. Comments please:
>
>
>
>
>

I'm confused about the mention of RTP here. From my understanding so far,
RTP is MOSTLY out of the proposed scope, but this sentence made me think
that RTP will be changed or replaced, or encapsulated in QUIC, or something
else wild in this proposed working group, the way SIP is being replaced. Is
it correct that "transmission of media packets" refers to signaling
necessary to tell each endpoint what the media path will look like (I saw
your P2P media open issue), or are you thinking about something else?

Would removing "and RTP" make a difference for the proposed working group's
scope?

Best,

Spencer

> ------------------------------
>
> 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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Feb 2020 19:15:25 -0500

RTP is in scope, in that, RIPT replaces RTP (and SDP and SIP).

Basically, the output of the codec is placed into something called a 'media
chunk' which adds a few parameters which are similar to RTP (i.e.,
timestamp) and then sent in a PUT request or GET response.

No doubt an issue of contention will be whether we should just encapsulate
RTP vs. whats in the draft.

-Jonathan R.

On Fri, Feb 14, 2020 at 6:57 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Would removing "and RTP" make a difference for the proposed working
> group's scope?
>
> Best,
>
> Spencer
>
>

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Feb 2020 19:38:08 -0600

Hi, Jonathan,

On Fri, Feb 14, 2020 at 6:16 PM Jonathan Rosenberg <[email-masked]>
wrote:

> Basically, the output of the codec is placed into something called a
> 'media chunk' which adds a few parameters which are similar to RTP (i.e.,

That's very clear, as you explain it. Perhaps it's worth a mention in the
proposed charter?

Also, perhaps adding AVTCORE as one of the coordinated-with working groups?

Best,

Spencer

>>> Good news folks – RIPT bof was approved for IETF107 and we’ll be
>>> meeting. Goal is to try and get a WG formed. As such, charter discussion is
>>> in order. Cullen, myself and Justin worked a draft charter. Comments please:
>>>
>>>
>>>
>>>
>>>

---

From: Ross Finlayson <[email-masked]>
Date: Sat, 15 Feb 2020 19:00:00 +1300

On Feb 15, 2020, at 1:15 PM, Jonathan Rosenberg <[email-masked]> wrote:
> Basically, the output of the codec is placed into something called a 'media chunk' which adds a few parameters which are similar to RTP (i.e., timestamp) and then sent in a PUT request or GET response.

Jonathan is ‘handwaving’ a bit here :-), as he understands (more than just about anyone) that replicating the functionality of RTP would involve a lot more than just adding a few parameters to PUT and GET.  For each media type being transported, you’d need to define how data is best framed within (QUIC) datagrams, how (optional) FEC could be used, what RTCP XR functionality will be retained (and how), how (the equivalent of) RTP header options would be defined/carried, etc. etc. etc.  Essentially, you’d be replicating all of the work that took place (over several years) within AVT to define a RTP payload format for each media type.  Therefore...

> No doubt an issue of contention will be whether we should just encapsulate RTP vs. whats in the draft.

If we want to get something standardized/working quickly, then this is a ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets directly in QUIC datagrams - in such a way that the existing RTP payload format defined for each media type could map directly (i.e., with no more media-specific IETF standardization work required).  Even if this means that there's some duplication of functionality between RTP and QUIC (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)

While - at some point in the future - it may be worthwhile defining a new version (v3?) of RTP that works more efficiently with QUIC, this should not be something that we require before we define/standardize a replacement for SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to show its age, but it’s not broken, and has lots of existing deployment that could, ideally, be leveraged quickly within a SIP replacement.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Feb 2020 23:54:53 -0800

On Fri, Feb 14, 2020 at 10:00 PM Ross Finlayson <[email-masked]>
wrote:

> Jonathan is ‘handwaving’ a bit here :-), as he understands (more than just
> about anyone) that replicating the functionality of RTP would involve a lot
> more than just adding a few parameters to PUT and GET.  For each media type
> being transported, you’d need to define how data is best framed within
> (QUIC) datagrams, how (optional) FEC could be used, what RTCP XR
> functionality will be retained (and how), how (the equivalent of) RTP
> header options would be defined/carried, etc. etc. etc.  Essentially, you’d
> be replicating all of the work that took place (over several years) within
> AVT to define a RTP payload format for each media type.  Therefore...
>
>
> If we want to get something standardized/working quickly, then this is a
> ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets directly
> in QUIC datagrams - in such a way that the existing RTP payload format
> defined for each media type could map directly (i.e., with no more
> media-specific IETF standardization work required).  Even if this means
> that there's some duplication of functionality between RTP and QUIC
> (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)
>

Yes, this is my preferred approach. There still will be a lot of work just
to get this up and running, figure out how congestion control works in this
world, and avoid ending up with a lot of bloat from the encapsulation.
Assuming this works, we get fairly straightforward gatewaying between the
old and new worlds.

> While - at some point in the future - it may be worthwhile defining a new
> version (v3?) of RTP that works more efficiently with QUIC, this should not
> be something that we require before we define/standardize a replacement for
> SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to show
> its age, but it’s not broken, and has lots of existing deployment that
> could, ideally, be leveraged quickly within a SIP replacement.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> --
> V3 mailing list
> [email-masked]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 15 Feb 2020 15:10:42 -0500

I also would think that “encapsulated RTP” approach is more promising as a starting point for all the reasons already mentioned. Having said that, and despite probably being one of the most “legacy oriented” people in the WG, I think it is worth to assess other strategies as well. I would consider cloud/legacy/failover friendliness as important parameters during this process.

Thanks,
Tolga

From: V3 <[email-masked]> On Behalf Of Justin Uberti
Sent: Saturday, February 15, 2020 2:55 AM
To: Ross Finlayson <[email-masked]>
Cc: Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

On Fri, Feb 14, 2020 at 10:00 PM Ross Finlayson <[email-masked]<mailto:[email-masked]>> wrote:

Yes, this is my preferred approach. There still will be a lot of work just to get this up and running, figure out how congestion control works in this world, and avoid ending up with a lot of bloat from the encapsulation. Assuming this works, we get fairly straightforward gatewaying between the old and new worlds.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/<http://www.live555.com/>

--
V3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 15 Feb 2020 20:28:03 +0000

Definitely interesting/useful concept in general if the end result indeed can deliver benefits on the following aspects: HA, load-balancing, auto-scaling, cloud-friendliness. Having said that, just “going HTTP” hardly would provide satisfactory results IMHO. The issues with Cloud/real tiem session (mis)match are usually due to the fact that the infrastructure is tailored for certain type of applications, i.e. for the lack of a better term “web applications”. Failover, service discovery, load balancing, message retransmission/back-off/circuit breaking, what is understood as HA etc… are all areas where a real time session application is currently a misfit. Yes, there are workarounds/various strategies but mostly painful/indirect/not complete.

I am optimistic that things can be made better but it really would help if we make sure that each strategic decision first goes through a detailed analysis in terms of its implementation/deployment implications/benefits -or lack of it-. This aspect is usually not considered as an integral part of protocol standardization but IMHO for this WG it should, as “making life easier” is one of the core goals. Furthermore, I would argue that following a modular approach -as much as possible- could be useful so that certain pieces can be plugged into the SIP/SDP world as well, e.g. HTTP encapsulated RTP if that happens to be the choice.

Thanks,
Tolga

From: V3 <[email-masked]> On Behalf Of Jonathan Rosenberg
Sent: Friday, February 14, 2020 5:00 PM
To: [email-masked]
Cc: Cullen Jennings (fluffy) <[email-masked]>
Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Good news folks – RIPT bof was approved for IETF107 and we’ll be meeting. Goal is to try and get a WG formed. As such, charter discussion is in order. Cullen, myself and Justin worked a draft charter. Comments please:

Milestones:

Thx,
Jonathan R.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Feb 2020 09:33:34 -0600

Jonathan, Cullen,

For the following:

"It is a non-goal of this working group to replicate all of SIP and its 
many extensions into HTTP. The group will limit itself to supporting the 
functionality in widespread actual usage today."

How do you envision defining the "functionality that is in widespread 
actual usage today?"

Do we need another working group deliverable to define what of existing 
SIP is in and what is out?

Thanks,

Steve

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 18 Feb 2020 22:00:43 +0600

In-line below.
ThanksSamir

On 2/18/2020 at 9:04 PM, "Steve Donovan"  wrote:                  
Jonathan, Cullen,
     For the following:
	"It is a non-goal of this working group to       replicate all of SIP
and its many extensions into HTTP. The group       will limit itself
to supporting the       functionality in widespread actual usage
today."     

	How do you envision defining the "functionality       that is in
widespread actual usage today?"     

	Do we need another working group deliverable to       define what of
existing SIP is in and what is out?     

	SS>> I am in agreement for defining SIP extensions in wide usage. 

	Thanks,     

	Steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Feb 2020 16:12:24 +0000

So - let me be more precise on my (correctly labeled!) handwaving:

The idea is largely to replace the syntax of the RTP header with something new. The primary motivations for this are to (1) add explicit labels for streams (defined as the combo or source and destination sinks within a callID), (2) utilize variable length encodings to increase the effective number of bits used for timestamps and sequence numbers so that they never roll over, (3) utilize variable length encodings for static payload types, a necessary artifact from the advertisement/directive model which forgoes per-call capabilities exchanges.

Beyond that, the idea was that issues like codec encapsulation do in fact reuse the massive library of payload types that have been defined to date. I agree it would be folly to redo them.

RTCP is more interesting. RIPT adds per-packet acks, along with timestamps, basically gives senders all the information (and more) they'd get from RTCP RR, for example. We also use RTCP a lot for media control (i.e., FIR). With RIPT, since signaling follows media, these can now be sent reliably as events over the event channel. Consequently, the applicability of many of the RTCP extensions is an open question in my mind. I have on my todo-list to do an analysis of the many RTP extensions to get a full picture of this, to aid our decision on whether to fully encapsulate RTP, encapsulate the payloads but change the RTP header (which is what the draft is proposing), or something else entirely.

Also to be clear - whilst I agree that RTP on QUIC is interesting - it is not in scope because httpbis is our target, not quic. We want to allow voice signaling and media to run over web infrastructure services, so http is our 'waist of the hourglass' not quic.

-----Original Message-----
From: Ross Finlayson <[email-masked]>
Sent: Saturday, February 15, 2020 1:00 AM
To: [email-masked]
Cc: Spencer Dawkins at IETF <[email-masked]>; Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; Jonathan Rosenberg <[email-masked]>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Feb 2020 11:17:40 -0500

Tolga -

Totally agree that pragmatic "this actually works" is crucial. This is why
the following is called out in the charter:

I think your suggestion is a good one - that it is not just implementation
of the protocol, but working on practical implementation into things like -
I dont know, maybe Ribbon SBCs (hint hint) - and cloud services like amazon
and google, to gain an understanding of what works.

Thx,
Jonathan R.

On Sat, Feb 15, 2020 at 3:28 PM Asveren, Tolga <[email-masked]> wrote:

> Definitely interesting/useful concept in general if the end result indeed
> can deliver benefits on the following aspects: HA, load-balancing,
> auto-scaling, cloud-friendliness. Having said that, just “going HTTP”
> hardly would provide satisfactory results IMHO. The issues with Cloud/real
> tiem session (mis)match are usually due to the fact that the infrastructure
> is tailored for certain type of applications, i.e. for the lack of a better
> term “web applications”. Failover, service discovery, load balancing,
> message retransmission/back-off/circuit breaking, what is understood as HA
> etc… are all areas where a real time session application is currently a
> misfit. Yes, there are workarounds/various strategies but mostly
> painful/indirect/not complete.
>
>
>
> I am optimistic that things can be made better but it really would help if
> we make sure that each strategic decision first goes through a detailed
> analysis in terms of its implementation/deployment implications/benefits
> -or lack of it-. This aspect is usually not considered as an integral part
> of protocol standardization but IMHO for this WG it should, as “making life
> easier” is one of the core goals. Furthermore, I would argue that following
> a modular approach -as much as possible- could be useful so that certain
> pieces can be plugged into the SIP/SDP world as well, e.g. HTTP
> encapsulated RTP if that happens to be the choice.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* V3 <[email-masked]> *On Behalf Of *Jonathan Rosenberg
> *Sent:* Friday, February 14, 2020 5:00 PM
> *To:* [email-masked]
> *Cc:* Cullen Jennings (fluffy) <[email-masked]>
> *Subject:* [V3] RIPT BoF approved for IETF 107 - Draft charter below
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. that is confidential and/or proprietary for
> the sole use of the intended recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately and then delete all copies, including any attachments.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Feb 2020 11:21:09 -0500

Great question Steve. The goal is to do it based on working group
consensus, as always.

This would be educated based on - the concrete proposal in the current
documents which defines exactly the scope that is being proposed right now.
This avoids making this a theoretical discussion because we have a starting
point.

This question is also why I'm working on this draft:
https://tools.ietf.org/html/draft-rosenberg-dispatch-ript-sipdiffs-00

which is yet incomplete but will present an analysis of the SIP extension
landscape to get a feel for what the proposed scope actually covers.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Feb 2020 13:49:39 -0500

I certainly would be happy to share all the pain, agony etc… experienced during this still ongoing Odyssey, starting from Lotus Eaters.

I understand that the idea is to have HTTP based hourglass model but it would be really useful if at least some concepts/strategies can be plugged-in to other models. Honestly, I am not sure whether/how this would eb possible though but worth to give it a try IMHO.

Thanks,
Tolga

From: Jonathan Rosenberg <[email-masked]>
Sent: Tuesday, February 18, 2020 11:18 AM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Tolga -

Totally agree that pragmatic "this actually works" is crucial. This is why the following is called out in the charter:

I think your suggestion is a good one - that it is not just implementation of the protocol, but working on practical implementation into things like - I dont know, maybe Ribbon SBCs (hint hint) - and cloud services like amazon and google, to gain an understanding of what works.

Thx,
Jonathan R.

On Sat, Feb 15, 2020 at 3:28 PM Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
Definitely interesting/useful concept in general if the end result indeed can deliver benefits on the following aspects: HA, load-balancing, auto-scaling, cloud-friendliness. Having said that, just “going HTTP” hardly would provide satisfactory results IMHO. The issues with Cloud/real tiem session (mis)match are usually due to the fact that the infrastructure is tailored for certain type of applications, i.e. for the lack of a better term “web applications”. Failover, service discovery, load balancing, message retransmission/back-off/circuit breaking, what is understood as HA etc… are all areas where a real time session application is currently a misfit. Yes, there are workarounds/various strategies but mostly painful/indirect/not complete.

Thanks,
Tolga

From: V3 <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonathan Rosenberg
Sent: Friday, February 14, 2020 5:00 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>>
Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Milestones:

Thx,
Jonathan R.

________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________
--
V3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>

--
Jonathan Rosenberg, Ph.D.
[email-masked]<mailto:[email-masked]>
http://www.jdrosen.net<http://www.jdrosen.net>

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 19 Feb 2020 09:02:40 +1300

> On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <[email-masked]> wrote:
> 

So just to clarify here:  Is your goal (for this protocol) that media be transferred only over streams (TCP or (reliable) QUIC), not datagrams?  Consequently, how important is end-to-end latency for audio/video calls that would use this protocol?

And are peer-to-peer audio/video calls (that would not involve a web server at all, except perhaps for initial end-user lookup/discovery) out of scope for this protocol?

If that's the case, then you’re not really ‘replacing’ RTP, but rather defining a new media transport protocol to be used in this one (restricted, but important) environment: Transport using reliable protocols via web server(s).  And if that’s the case, then I’m concerned that your SIP replacement (i.e., replacement of the one thing that’s truly broken, and needs replacing) might end up being too restrictive for more general media transport (datagrams and/or peer-to-peer).

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 18 Feb 2020 16:47:12 -0600

I am also hoping for clarity here, or at least clue.

On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <[email-masked]>
wrote:

> > Also to be clear - whilst I agree that RTP on QUIC is interesting - it
> is not in scope because httpbis is our target, not quic. We want to allow
> voice signaling and media to run over web infrastructure services, so http
> is our 'waist of the hourglass' not quic.
>
> So just to clarify here:  Is your goal (for this protocol) that media be
> transferred only over streams (TCP or (reliable) QUIC), not datagrams?
> Consequently, how important is end-to-end latency for audio/video calls
> that would use this protocol?
>
> And are peer-to-peer audio/video calls (that would not involve a web
> server at all, except perhaps for initial end-user lookup/discovery) out of
> scope for this protocol?
>
> If that's the case, then you’re not really ‘replacing’ RTP, but rather
> defining a new media transport protocol to be used in this one (restricted,
> but important) environment: Transport using reliable protocols via web
> server(s).  And if that’s the case, then I’m concerned that your SIP
> replacement (i.e., replacement of the one thing that’s truly broken, and
> needs replacing) might end up being too restrictive for more general media
> transport (datagrams and/or peer-to-peer).
>

I think I arrived at the same place as Ross, coming from the opposite
direction. ("Thunk!")

ISTM that the proposal floating through here for a new media transport
protocol, if it is successful, would be useful for non-RIPT applications as
well, and ISTM that other proposals for RTP over QUIC (or whatever we're
all muttering about privately), if one of them is successful, might be
useful for RIPT applications as well.

So, the first suggestion I'd make at the BOF, if work on media transport of
whatever flavor is still part of the proposed RIPT charter, is to split it
off into a separate proposal, which I'd love to see go forward on its own,
unless there are really strong reasons why RIPT signaling specification
work and RIPT media transport work need to be coupled, need to fate-share,
and need to compete for attention in the same working group.

I can say more about that at a mike in Vancouver, but let me start with
this, on a mailing list ...

Best,

Spencer

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Feb 2020 20:25:54 -0500

“So, the first suggestion I'd make at the BOF, if work on media transport of whatever flavor is still part of the proposed RIPT charter, is to split it off into a separate proposal, which I'd love to see go forward on its own, unless there are really strong reasons why RIPT signaling specification work and RIPT media transport work need to be coupled, need to fate-share, and need to compete for attention in the same working group. “

Couldn’t agree more.

Thanks,
Tolga

From: V3 <[email-masked]> On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, February 18, 2020 5:47 PM
To: Ross Finlayson <[email-masked]>
Cc: Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <[email-masked]<mailto:[email-masked]>> wrote:

> On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>> wrote:
>

I think I arrived at the same place as Ross, coming from the opposite direction. ("Thunk!")

ISTM that the proposal floating through here for a new media transport protocol, if it is successful, would be useful for non-RIPT applications as well, and ISTM that other proposals for RTP over QUIC (or whatever we're all muttering about privately), if one of them is successful, might be useful for RIPT applications as well.

So, the first suggestion I'd make at the BOF, if work on media transport of whatever flavor is still part of the proposed RIPT charter, is to split it off into a separate proposal, which I'd love to see go forward on its own, unless there are really strong reasons why RIPT signaling specification work and RIPT media transport work need to be coupled, need to fate-share, and need to compete for attention in the same working group.

I can say more about that at a mike in Vancouver, but let me start with this, on a mailing list ...

Best,

Spencer

Ross Finlayson
Live Networks, Inc.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 18 Feb 2020 19:55:05 -0800

Replying to Ross...

> that would use this protocol?

Critical. We believe that there are techniques within HTTP/3 that can
address this situation, although (speaking for myself) we may find
ourselves needing to go lower in the protocol stack.

> server at all, except perhaps for initial end-user lookup/discovery) out of

P2P is in scope, but using existing WebRTC protocols. Since p2p scenarios
require both endpoints to participate, there's a chicken-and-egg problem
there, and we can look at that after we get things working in the c2s
scenario.

> transport (datagrams and/or peer-to-peer).

This is a reasonable concern, but we think that starting small and
expanding scope later (especially when there is a sense of how that
expansion might work) might allow for faster progress.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 18 Feb 2020 20:01:06 -0800

On Tue, Feb 18, 2020 at 2:47 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> So, the first suggestion I'd make at the BOF, if work on media transport
> of whatever flavor is still part of the proposed RIPT charter, is to split
> it off into a separate proposal, which I'd love to see go forward on its
> own, unless there are really strong reasons why RIPT signaling
> specification work and RIPT media transport work need to be coupled, need
> to fate-share, and need to compete for attention in the same working group.
>

Spencer -

I agree that the signaling and media transport aspects are separable, but
ultimately many applications will deploy them together, and perhaps
multiplex them over the same HTTP transport. As such, there's definitely
value in having a WG that considers the overall problem space and the
various interactions between the layers (I think there are actually 3
layers - signaling, session descriptions, and media transport).

Certainly worth discussing further though.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Feb 2020 06:22:14 -0600

Hi, Justin,

> Replying to Ross...

I'm not Ross, but I found this reply helpful.

> ourselves needing to go lower in the protocol stack.

Yeah, that was certainly the goal (no one was ignoring latency in the QUIC
working group, either). IIUC, this approach would be tied to HTTP
infrastructure that hasn't had end-to-end latency for realtime
communication as a goal in the past, but we'll see where this goes.

> expansion might work) might allow for faster progress.

That's fair. Collecting actual experience and data is rarely wrong.

Best.

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Feb 2020 06:40:45 -0600

Hi, Justin,

>> this, on a mailing list ...

This time, I AM Spencer :-)

> layers - signaling, session descriptions, and media transport).

"Consider" is the key word, and I think that's an invitation to good
systems engineering. No objection to that.

My suggestion is that the BOF proponents be really clear about what they
expect to happen after the considering, and especially asking whether work
on media relies on the same expertise as signaling, and (speaking as past
AD for QUIC) whether you really need everyone in the same room at the same
time, with no opportunity for parallel processing of separable topics.

At a minimum, I'd suggest adding AVTCORE, MMUSIC, and ICE to the list of
working groups to coordinate with.

But do the right thing, of course :-)

Best,

Spencer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Feb 2020 14:01:02 +0000

Hi Spencer:

As you and Ross have inquired about – a KEY goal for this specification to enable client-to-server real-time media applications in modern cloud platforms. Examples would include audio bridges, contact centers, IP PBXs which handle media (many do), softswitches, cloud sbcs, and so on. All of these handle both signaling and media. This goal does in fact couple the media to signaling in some new ways, which introduce new requirements that a fully clean separation of signaling and media cannot easily address.  Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice. That means that clients have to send media through HTTP. Secondly, we assume that sticky routing happens in these load balancers the ‘normal’ way – through a combo of hashing of 5-tuples and usage of session cookies. That means that, in order to get the media to the server handling the signaling (which is what we want), the media needs to come in the same connection, and use cookies. This further ties it to HTTP. In order to deal with failures of those servers and enable mid-call recovery without loss of media packets, we also need the transport to contain call identifiers. This way, media can just ‘be sent’ to a new server in the pool behind the load balancer, and it can pick up where things left off in the previous server without losing any media packets (like - not one). In RIPT this happens because all media are PUT/GET from the call URI.

All of the above requirements largely point to the need for a new encapsulation technique for the content of RTP packets, which enables them to be transported over HTTP in a way that is quite coupled with the signaling.

Ross had asked (or was it Spencer 😉) about whether the goal was to transmit the media over TCP. Our objective is that the media ultimately end up in a UDP packet in such a way that we avoid HOL blocking and enable the system to function with packet loss causing dropped packets. That can be accomplished in HTTP3 by using a new HTTP transaction for each packet, which maps to a new QUIC stream, which can be opened with zeroRTT, and if you end the transaction and don’t use it again, you end up getting media in a single UDP packet. This however is but one technique. Assuming webtransport gets standardized and widely deployed and runs within http, this would be another. We can also round-robin across transactions (this is what I had in earlier drafts). These are different solutions which the group needs to choose from. But the core requirement is to ultimately get low-latency media.

This also comes with an underlying assumption that the HTTP load balancers, networks, service meshes, serverless compute engines, and so on – which are used for HTTP – achieve low latency in general (network transport aside) – sufficiently low for voip. There is evidence to suggest that this is the case, as more and more ‘non-real-time’ apps on the web are getting pretty darn fast. Financial transaction processing is one such example. In fact, initial experiments were run to push media over plain old HTTP 1.1 in these platforms, which uses TCP, and it was pretty darn good!

HTH –
Jonathan R.

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Wednesday, February 19, 2020 7:41 AM
To: Justin Uberti <[email-masked]>
Cc: Ross Finlayson <[email-masked]>; Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Hi, Justin,

On Tue, Feb 18, 2020 at 10:01 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 18, 2020 at 2:47 PM Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
I am also hoping for clarity here, or at least clue.

Spencer -

I agree that the signaling and media transport aspects are separable, but ultimately many applications will deploy them together, and perhaps multiplex them over the same HTTP transport. As such, there's definitely value in having a WG that considers the overall problem space and the various interactions between the layers (I think there are actually 3 layers - signaling, session descriptions, and media transport).

"Consider" is the key word, and I think that's an invitation to good systems engineering. No objection to that.

My suggestion is that the BOF proponents be really clear about what they expect to happen after the considering, and especially asking whether work on media relies on the same expertise as signaling, and (speaking as past AD for QUIC) whether you really need everyone in the same room at the same time, with no opportunity for parallel processing of separable topics.

At a minimum, I'd suggest adding AVTCORE, MMUSIC, and ICE to the list of working groups to coordinate with.

Best,

Spencer

Best,

Spencer

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 20 Feb 2020 03:52:13 +1300

> On Feb 20, 2020, at 3:01 AM, Jonathan Rosenberg <[email-masked]> wrote:
> 
> Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice. That means that clients have to send media through HTTP. Secondly, we assume that sticky routing happens in these load balancers the ‘normal’ way – through a combo of hashing of 5-tuples and usage of session cookies. That means that, in order to get the media to the server handling the signaling (which is what we want), the media needs to come in the same connection, and use cookies. This further ties it to HTTP. In order to deal with failures of those servers and enable mid-call recovery without loss of media packets, we also need the transport to contain call identifiers. This way, media can just ‘be sent’ to a new server in the pool behind the load balancer, and it can pick up where things left off in the previous server without losing any media packets (like - not one). In RIPT this happens because all media are PUT/GET from the call URI.

OK, thanks - this explanation makes it very clear that what you’re planning is a protocol for audio/video calls *over HTTP* - and over HTTP only.  A lot of the confusion (largely on my part, I admit) about what you’re proposing would have been avoided if this had been clearer in the name of the protocol (and BOF) - i.e., if there had been an “H” in there (I would have preferred something like MoH: “Media over HTTP” :-)

And grandiose statements about this protocol "replacing SIP, RTP and SDP” don’t help either - unless you really see the “HTTP Internet” (hourglass) becoming the entire Internet.  (Not all of us are ready to concede that, just yet ;-)

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 20 Feb 2020 04:17:35 +1300

> On Feb 20, 2020, at 3:52 AM, Ross Finlayson <[email-masked]> wrote:
> 

On reflection, something like “RMoH” (“Real-time Media over HTTP”) would be even better, to distinguish this from other HTTP-based media delivery systems like HLS (“HTTP Live Streaming”), that don’t have the same low-latency requirements.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 19 Feb 2020 07:29:42 -0800

> OK, thanks - this explanation makes it very clear that what you’re planning is a protocol for audio/video calls *over HTTP* - and over HTTP only.  A lot of the confusion (largely on my part, I admi…

I think v3 is about both media and signaling not just media.

But anyway I think it should be the other way around -- HTTP is less and less about Hypertext, so that's the thing that should be renamed.  Web Transport Protocol? WTP?

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Feb 2020 15:57:21 +0000

> On Feb 14, 2020, at 10:00 PM, Ross Finlayson <[email-masked]> wrote:
> 

Almost no modern RTP implementation actually does the full RTP spec so at the very least we need some serious subsetting of what part of RTP would be mapped to QUIC. The RTP extension mechanism is badly broken particularly for low bandwidth satellite links. And if you look at what RTP clients do with the RTCP sent to them, well, I think there is some house cleaning needed here to be able to actually use RTP /RTCP.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Feb 2020 16:00:59 +0000

So what I think we should do here is to use QUIC  (or fallback to something else) as the transport mechanism for the media. Now QUIC provide for example congestion control. So does RTP. Trying to define how RTPs congestion controls works when running at the same time as QUICs seem like a nightmare. I think we should just define the mapping of the RTP like semantics about the media into a QUIC stream and let QUIC be the transport - not try and say we are using RTP over QUIC. 

> On Feb 18, 2020, at 2:47 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <[email-masked]> wrote:
>

---

From: Joerg Ott <[email-masked]>
Date: Wed, 19 Feb 2020 17:03:36 +0100

Let me just point out here that there is still a dangling question
if one could leverage more state from QUIC than just offering a
datagram service.

Colin and I went through some thought exercise to this end, but we
don't have an integrated implementation within QUIC for some RTP
features yet.  Still, our little analysis may turn out to be useful:
http://www.netlab.tkk.fi/~jo/papers/2018-12-epiq-quic-rtp.pdf

Jörg

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Feb 2020 16:09:42 +0000

> On Feb 18, 2020, at 5:25 PM, Asveren, Tolga <[email-masked]> wrote:
> 
>  there are really strong reasons why RIPT signaling specification work and RIPT media transport work need to be coupled, need to fate-share,

Yes, the key point of this work is the signalling and media flow over the same transport and are fate shared. This is a key part of what makes it work with modern load balancers. So I think we do have to deal with how the media and signalling go over HTTP is this proposed WG. Now that does not mean we can’t tunnel RTP/RTCP over HTTP but that can be pretty complicated to define.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Feb 2020 11:32:47 -0800

Thanks for this paper, I think this is a good exploration of the space,
especially the table on page 4.

Generally I think the substrate protocol gives us datagrams (or a suitable
alternative), encryption, a global sequence number, and some parts of the
necessary congestion control machinery, and the rest needs to be layered on
top.

On Wed, Feb 19, 2020 at 8:03 AM Joerg Ott <[email-masked]> wrote:

> >> If we want to get something standardized/working quickly, then this is
> a ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets
> directly in QUIC datagrams - in such a way that the existing RTP payload
> format defined for each media type could map directly (i.e., with no more
> >> While - at some point in the future - it may be worthwhile defining a
> new version (v3?) of RTP that works more efficiently with QUIC, this should
> not be something that we require before we define/standardize a replacement
> for SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to
> show its age, but it’s not broken, and has lots of existing deployment that
> > Almost no modern RTP implementation actually does the full RTP spec so
> at the very least we need some serious subsetting of what part of RTP would
> be mapped to QUIC. The RTP extension mechanism is badly broken particularly
> for low bandwidth satellite links. And if you look at what RTP clients do
> with the RTCP sent to them, well, I think there is some house cleaning
> needed here to be able to actually use RTP /RTCP.
> >
>
> --
> V3 mailing list
> [email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Feb 2020 15:30:43 -0600

Joerg,

> especially the table on page 4.

I wanted to echo Justin's thanks for forwarding a link to your/Colin's
paper. It's very helpful.

Best,

Spencer

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 20 Feb 2020 00:37:26 +0000

“Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice.”

I would like to point out that this is an important assumption and does not entirely overlap with reality. Application specific and L4 load balancers are used widely in Cloud deployments for real-time sessions. I doubt standard HTTP  load balancers can be used as is even if all real time session messaging (signaling, media, …) is HTTP based. Required semantics, e.g. different treatment based on RPH, overload control etc…,  are simply different than what is needed/used/sufficient for standard Web applications.

On another note, a core issue for Cloud load balancing is failure detection/failover time for back ends servers. This again is an area where “just using HTTP” wouldn’t help.

Having “HTTP only” as a core principle is fine but I think the rationale for that should be articulated more in detail and clarity.

Thanks,
Tolga

From: V3 <[email-masked]> On Behalf Of Ross Finlayson
Sent: Wednesday, February 19, 2020 9:52 AM
To: Jonathan Rosenberg <[email-masked]>
Cc: Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]; Spencer Dawkins at IETF <[email-masked]>; Justin Uberti <[email-masked]>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

> On Feb 20, 2020, at 3:01 AM, Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>> wrote:
>

Ross Finlayson
Live Networks, Inc.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 20 Feb 2020 00:45:38 +0000

> On Feb 19, 2020, at 4:37 PM, Asveren, Tolga <[email-masked]> wrote:
> 

This may be a bit of terminology confusion. I know I consider L4 load balancers to be one of the many types of normal HTTP load balancers though.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Feb 2020 01:20:25 +0000

Now we’re getting to some meat! Tolga said:

> I doubt standard HTTP  load balancers can be used as is even if all real time session messaging (signaling, media, …) is HTTP based. Required semantics, e.g. different treatment based on RPH, overload control etc…,  are simply different than what is needed/used/sufficient for standard Web applications. On another note, a core issue for Cloud load balancing is failure detection/failover time for back ends servers. This again is an area where “just using HTTP” wouldn’t help.

So – a key goal here is to move away from voip being ‘special’ to being ‘just another app’. You’re correct that Resource Priority isn’t something existing LB’s deal with, but the idea of prioritizing different requests when a load balancer is overloaded, is not a problem unique to voip. I also don’t think that the applications which typically worry about RPH are initial targets for this protocol.

For overload control – well there I disagree. In this protocol, the HTTP LB holds no call state so normal HTTP overload handling I think will work fine.

Similarly – failure detection is often done today via REST endpoints which are implemented in the origin servers which the LB pings. That will work just fine in this case, Ive personaly implemented stuff that works this way.

That said – you are correct that the charter needs to be clearer on this underlying assumption.

From: Asveren, Tolga <[email-masked]>
Sent: Wednesday, February 19, 2020 7:37 PM
To: Ross Finlayson <[email-masked]>; Jonathan Rosenberg <[email-masked]>
Cc: Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]; Spencer Dawkins at IETF <[email-masked]>; Justin Uberti <[email-masked]>
Subject: RE: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Thanks,
Tolga

From: V3 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ross Finlayson
Sent: Wednesday, February 19, 2020 9:52 AM
To: Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>
Cc: Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>>; Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>; Justin Uberti <[email-masked]<mailto:[email-masked]>>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Feb 2020 01:24:51 +0000

Good points - I think the clear feedback from this and Tolga's comments are making the fact that this is really ontop of HTTP much clearer.

In terms of 'grandiose statements' - well, it actually does replace SIP/RTP/SDP depending on what one means by 'replace'. It replaces - in that it provides similar functionality and thus eliminates the need for - SIP/SDP/RTP - in the use case we are trying to address. Those use cases are around peering between cloud-based applications (CCaaS, UCaaS, cloud PBXs, etc) which run in public clouds, and telco providers. Another key use case is between browser and cloud-based application that wants to terminate media (conferencing provider, IP PBX which handles media, etc).

-----Original Message-----
From: Ross Finlayson <[email-masked]>
Sent: Wednesday, February 19, 2020 9:52 AM
To: Jonathan Rosenberg <[email-masked]>
Cc: Spencer Dawkins at IETF <[email-masked]>; Justin Uberti <[email-masked]>; Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 20 Feb 2020 14:10:16 -0500

Trying to dive deeper so that the goals/scope/expectations could be defined in a more detailed way:

i- IMHO “being just another app” is a bit problematic, at least not for some real-time session applications

 *   I think it is not realistic to expect that majority of real-time session applications won’t have any notion of “special handling for emergency calls”
 *   Semantics for how 503 responses from back-ends need to be interpreted/dealt with also wouldn’t match well with the “standard HTTP LB” functionality
 *   We obviously can restrict the scope so that “such cases” are out of scope but let’s be aware that those are a non-negligible amount of overall real-time session universe
ii- Back-end failover

 *   Yet another area where Cloud LBs (whether HTTP or L4) fall short
 *   Yes, there are heartbeats between backend and LB but the failure detection time is usually nowhere near being satisfactory for media
 *   What could be useful
    *   Media is negotiated with a backup address
       *   This would be a different URI for HTTP based media
       *   And this should result that a different backend receives the packets
    *   Sender switches to backup address when inactivity is detected
    *   The same could be done with SIP/SDP as well, e.g. maybe by utilizing RFC5888 FID
       *   But FID/semantics of using it in this fashion are not widely supported
    *   v3 being “new”, the rules would be defined from scratch so this can be the standard behavior

Thanks,
Tolga

From: Jonathan Rosenberg <[email-masked]>
Sent: Wednesday, February 19, 2020 8:20 PM
To: Asveren, Tolga <[email-masked]>; Ross Finlayson <[email-masked]>
Cc: Cullen Jennings (fluffy) <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]; Spencer Dawkins at IETF <[email-masked]>; Justin Uberti <[email-masked]>
Subject: RE: [V3] RIPT BoF approved for IETF 107 - Draft charter below

From: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 19, 2020 7:37 PM
To: Ross Finlayson <[email-masked]<mailto:[email-masked]>>; Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>
Cc: Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>>; Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>; Justin Uberti <[email-masked]<mailto:[email-masked]>>
Subject: RE: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Thanks,
Tolga

Ross Finlayson
Live Networks, Inc.

---

From: "Roni Even (A)" <[email-masked]>
Date: Sat, 29 Feb 2020 07:51:05 +0000

Hi,
I read the drafts. I like the idea of having the endpoint capabilities known in advance making call establishment simpler. We have the must support codecs in RTCweb and this is a step forwards. Maybe it is also about time to deprecate the "MUST support H.261/G.711" in older documents (H.323,...).
As for media transport, I think that Jorge and Colin document provide good starting point and motivation why to use datagrams for the media and it is my preference for conversional services to have the application layer decide if to retransmit.  My view is that for audio it is not needed (use redundancy, the best retransmission is for the listener to say "I could not hear it, can you please repeat".
As for video my view is that the requirement is not retransmission but re-synchronize. For "talking heads" video conference just resynch and continue.

Roni

From: V3 [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
Sent: Saturday, February 15, 2020 12:00 AM
To: [email-masked]
Cc: Cullen Jennings (fluffy)
Subject: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Milestones:

Thx,
Jonathan R.