Re: [V3] Thoughts on scope for ript

Victor Vasiliev <vasilvv@google.com> Wed, 25 March 2020 15:31 UTC

Return-Path: <vasilvv@google.com>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2533A0983 for <v3@ietfa.amsl.com>; Wed, 25 Mar 2020 08:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFNZEmEkxIOO for <v3@ietfa.amsl.com>; Wed, 25 Mar 2020 08:31:05 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D4E3A095D for <v3@ietf.org>; Wed, 25 Mar 2020 08:31:04 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id v16so2864547ljk.13 for <v3@ietf.org>; Wed, 25 Mar 2020 08:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PGP2awUiXDKYQl6IeNrlKL0leSg4HgpMBkG8QCZ6yvg=; b=eHMDOl7Ncx+8zBp7q9vmeidTff5Lmv3imCR8lNuaopNyUhuWpOUN/KEclt9+LxhpHW H0660xT1smcjUEj20ewHlUeDQExTO7ubDPRb5ud5U59REnqkwoi8pysx/PpqZ9zKdi7G KctHitXqyx9auCPReOe/fEuuLlpaFJH412gBo5Nja/6YdxOMP1r8D2i6EnCvhNxQ8ZVR IBFIG125XtLcRjHlZ/ArbuGHmYODTjrnj1QM7wNmn9VnBpDY47Lq5d2Zd2FFy+RPg+3v 9EgF41wqdTm2dKvxs8LEGM5bosPcidDU20Px5AqdQK4MVg/JlkUTqG7Urb5LLjtU2uXr BCMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PGP2awUiXDKYQl6IeNrlKL0leSg4HgpMBkG8QCZ6yvg=; b=CKLuhMfoWQckHgIIuPDnd8F8NX7N7jX8TGJ0VbujLv6DSqD9MJhX/woK3VzPg8JajD h13Lzczqxq/TAEIHOEeAAsRM06a1LHgsHkLH2kSPJj8v46Tx8Xul6awGt8rKSw23J4Jl GFxU4JX1cdsIxJdFc4EulGNSvos7uIHyDvEvtJ1+0Mkk5Xz5vYoZXXbA6jLcr65K0vz6 OI0NhFhaFfFCZlj8gfmwwA//l/ep5XvPJ3qoTLiHmdKvh0DEpzdxzCwJvi1w1YlPbGv4 mgDg7n5fVW6LfjMU0XttnyGaNK95muvVZmaVsVPJWrNA6WbgDkbDu5Yq2GsCzbyp8CpN /y9Q==
X-Gm-Message-State: AGi0PubAR9yk0d56jXR55yYPodWkoyJ4v137wRaIf5R+oL65/xpboKO2 5cWWEE45QUSYUxThMXt0MtM6CkBvcdMMbMQCEipFFQ==
X-Google-Smtp-Source: ADFU+vsWJetudDyXl4yfbsccdd5xaxN5Y9GtWLwayV3wkRQlbaL2zGECbKLk6cXeTlYpMzLdP+MOJvZe7HVMp0uMYKY=
X-Received: by 2002:a2e:85cb:: with SMTP id h11mr2343272ljj.55.1585150259569; Wed, 25 Mar 2020 08:30:59 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR06MB4391FBC64E195E87003061B8FBF00@BYAPR06MB4391.namprd06.prod.outlook.com> <CAOJ7v-0MP4p=tpzgNJu1Mxgt8cv4PL01PbQWhTzN6bYSQR9Yuw@mail.gmail.com>
In-Reply-To: <CAOJ7v-0MP4p=tpzgNJu1Mxgt8cv4PL01PbQWhTzN6bYSQR9Yuw@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Wed, 25 Mar 2020 11:30:46 -0400
Message-ID: <CAAZdMadmEuZz4T6t6BP_=ZMUrducE4g-qwYHpeiB8Ho8SEKCsQ@mail.gmail.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
Cc: Jonathan Rosenberg <jdrosen@five9.com>, "v3@ietf.org" <v3@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023856305a1af8ece"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/D340d2BwkLiHYiliTmISMdM4P9U>
Subject: Re: [V3] Thoughts on scope for ript
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 15:31:08 -0000

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.

On Mon, Mar 23, 2020 at 1:09 PM Justin Uberti <juberti=
40google.com@dmarc.ietf.org> wrote:

> 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.
>
>
> On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg <jdrosen@five9.com>
> 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.
>>
>> 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..
>>
>> --
>> V3 mailing list
>> V3@ietf.org
>> https://www.ietf.org/mailman/listinfo/v3
>>
> --
> V3 mailing list
> V3@ietf.org
> https://www.ietf.org/mailman/listinfo/v3
>