Re: [V3] Thoughts on scope for ript

Justin Uberti <> Mon, 23 March 2020 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE66E3A0C83 for <>; Mon, 23 Mar 2020 10:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0LFmUM3yvDRI for <>; Mon, 23 Mar 2020 10:09:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A7903A0C67 for <>; Mon, 23 Mar 2020 10:09:37 -0700 (PDT)
Received: by with SMTP id 9so5241002uav.12 for <>; Mon, 23 Mar 2020 10:09:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fj5u0D8vphH+KOiNq62iiaqPjH4Yy0xIkpAsI9bF4uU=; b=pxsJiCl45+wZ+2okeWf26Ey0Y/TAPzFhz3k/XKjq6xhYyMm7p7SX6n/Uh/DG0F6rY4 X9bE1pdKzCyzDRm98/W9vcvhXv6cEvV0d5K5terTOLWoJmma3CStOaxUTo94Jr11g3g/ W0M2+8ZoNweK9qx2B1jCCvTf4Gl+BL1EN+iOgOwHQ/7EBxTMfbYYrxRoyrSz+Ic4DbY0 Tg+ylaueG5ZbbqdwECEkdiBwGMJiP+ielLYBzJWoJ0z8uPnOaGmq8728pcqNL+DuFnPq 5dEtN/g5hP2aGDGC0poFBh2dSLvBfSS8NFpPOE2C7DQIV6O1fMXqgGTOYBYL5Nl2mu9g V6Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fj5u0D8vphH+KOiNq62iiaqPjH4Yy0xIkpAsI9bF4uU=; b=QfMMN2ziv1OnM5AUSgF1e1EnfVB9R3qEzOumOJNiG1s7DpLY36pTjkyEvMRMT92ZxS Pu+Frv0+8urVYa8J9BvWCcC+3FpbOqWKInwkCIiX4jnINe2XdOSWlXD+3oVLGOG/ZyJN Sz71FuSrBiRg3eY6GzOBT7Xh2ukvjanPhh0EDg8ZJp6T+XGNh2UBB26nW2VGlElImuZ5 HjoX0gkrYtgOjwqJ0IfYqGhfXd3P5q5NS4bif/iK+aAYVD90apqHEHWAxY7GDukBj0xW 5Tw227MBUFwu2Vc5AjtLOzSWqYahJtr1K0RTgUy/+pSIFI3PLlWEl5fskwUF6wGwWnSa aFWA==
X-Gm-Message-State: ANhLgQ0+S5IWs3zeB8N94WKn8xLxLLpjVvYbCOearmf7ZiAPC9PQdmlD E3hN7WekhbaatVmflkTG0nIaX3XnoDkAF3JicCGHGlj74lE=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsK/WejJyFsHe66TLcHJ7AzJnUyHPOyMyayZdTB?= =?utf-8?q?n2Rpf250UtX2FnI5aQg53e6sMCJmVY5hlSM1ChAGnQnanXc=3D?=
X-Received: by 2002:ab0:21ce:: with SMTP id u14mr14614437uan.23.1584983375455; Mon, 23 Mar 2020 10:09:35 -0700 (PDT)
MIME-Version: 1.0
References: =?utf-8?q?=3CBYAPR06MB4391FBC64E195E87003061B8FBF00=40BYAPR06MB4?= =?utf-8?q?391=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CBYAPR06MB4391FBC64E195E87003061B8FBF00=40BYAPR06MB?= =?utf-8?q?4391=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?=
From: Justin Uberti <>
Date: Mon, 23 Mar 2020 10:09:22 -0700
Message-ID: <>
To: Jonathan Rosenberg <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000012347205a188b3fa"
Archived-At: <>
Subject: Re: [V3] Thoughts on scope for ript
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2020 17:09:43 -0000

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

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
d) a replacement for SDP (i.e., the details of how media formats are
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

On Mon, Mar 23, 2020 at 7:21 AM Jonathan Rosenberg <>

> 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