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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Jonathan,

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

> 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.
>

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


>
> -Jonathan R.
>
> On Fri, Feb 14, 2020 at 6:57 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> 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 <[e-mail]>
>> 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:
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>
>> 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
>>
>>
>>> 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.
>>> --
>>> V3 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v3
>>>
>> --
>> V3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v3
>>
>
>
> --
> Jonathan Rosenberg, Ph.D.
> [e-mail]
> http://www.jdrosen.net
> --
> V3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v3
>