Re: [V3] Thoughts on scope for ript

Victor Vasiliev <> Wed, 25 March 2020 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA2533A0983 for <>; Wed, 25 Mar 2020 08:31:07 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xFNZEmEkxIOO for <>; Wed, 25 Mar 2020 08:31:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58D4E3A095D for <>; Wed, 25 Mar 2020 08:31:04 -0700 (PDT)
Received: by with SMTP id v16so2864547ljk.13 for <>; Wed, 25 Mar 2020 08:31:04 -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=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;; 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: <> <>
In-Reply-To: <>
From: Victor Vasiliev <>
Date: Wed, 25 Mar 2020 11:30:46 -0400
Message-ID: <>
To: Justin Uberti <>
Cc: Jonathan Rosenberg <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000023856305a1af8ece"
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: 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=> 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 <>
> 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 mailing list