Re: [V3] Thoughts on scope for ript

Anthony Minessale <> Mon, 23 March 2020 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B62D63A0F1A for <>; Mon, 23 Mar 2020 16:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hhuB4MvtCPwT for <>; Mon, 23 Mar 2020 16:38:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F92A3A0F1B for <>; Mon, 23 Mar 2020 16:38:37 -0700 (PDT)
Received: by with SMTP id r129so4334825vkr.6 for <>; Mon, 23 Mar 2020 16:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iin3A7MFlKfYNqc4xy134XpHrSPZKTylDhomEAEdbIo=; b=cc9RAAn7hhsLLz44TCmx0/Ixt3IR3YJUd5uCD0aBb6S8f4H/biitAcnH3vxNfsv/qb fReee4lKZS/+jlxsBCjygi76nQWmOJrX5/DN1uiYQEqbTEF8CS8ss8OuwC1b1GrCMa4s SLoIi1NmJbx9suSLK34H2zuzZzCCIhrF3YSbI=
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=iin3A7MFlKfYNqc4xy134XpHrSPZKTylDhomEAEdbIo=; b=kTYXKVZgDnrPmtY+bdg+xlSVUjWMvvhABvNZUjIO8TMnQiithI0l82cb4qq28f4db2 usYcC+YnVCDV615GUFi0R6C7WX5H5PF5Ah60fz3ILDNzW+EOvwWyshDEz8yddhN8MZqp kRoeLO8amQOrEssupHzLCAymO2nQWUPtrotWi05FKAmbbR+wb/G5mTWHT8lTTsdk9vzZ 98Rmkc+NZjsRebjjat1PuXFIsxhMBy2PaVj8REbXH/tYJjlKqjHQcbAGeyLjj1C/uV4O 5dZA1s7b49+/6GtXcYV5AKBTEWNo7bIcc9pagx2vxhtQxAF5ZzzB6GY4t26qia1vd4ce zZyA==
X-Gm-Message-State: ANhLgQ2E/T6c+W7xYtB5IM7dV+BduB0GlIKOikrkgCr+vLzbFipafX28 tpfsfQPqWbWD0ITqZNCLNXAmDIomxhE9t1L3teAsFtUW
X-Google-Smtp-Source: ADFU+vv925crYNSH4oCUIhavuvnWjNPZCMETzHQHmI32GERDhRd2IS3qDdy8+HroZts7RRB5mlWCDRQ7ytPNXFo4Q+g=
X-Received: by 2002:a1f:2c4b:: with SMTP id s72mr15275331vks.93.1585006715999; Mon, 23 Mar 2020 16:38:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Anthony Minessale <>
Date: Mon, 23 Mar 2020 18:38:24 -0500
Message-ID: <>
To: Justin Uberti <>
Cc: Jonathan Rosenberg <>, "" <>
Content-Type: multipart/related; boundary="00000000000046c2ac05a18e2204"
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 23:38:41 -0000

On Mon, Mar 23, 2020 at 5:43 PM Justin Uberti <> wrote:

> On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale <>
> wrote:
>> Also more consideration for live translation to sip/rtp/webrtc and
>> back-to-back scenarios.
>> If calls are being loaded balanced to many servers you still probably
>> will want a way to keep track of what calls are on what server in a way
>> that goes out of scope of HTTP so the application doing the clustering will
>> bear a pretty big burden of solving that problem from behind the cluster.
>> I read the memo about replacing SIP and was slightly disturbed that
>> RFC2833 (4733/4734) is the one thing salvaged ;)
>> That would be the first to go IMHO, its the leading cause of interop
>> issues in all of telephony and very rarely implemented to its full
>> potential not to mention there are some timestamp translation issues I
>> pointed out on the github discussion so that is it's own can of worms.
>> Also, the description seems to be evolving more towards considerations
>> about making calls behave like a web app which is fine because that's the
>> GOAL but there is little consideration of actual trunking so far.  SIP
>> trunking is just a made-up marketing term to mirror original TDM trunking
>> which was actual trunking (bundling many calls into one stream to reduce
>> overhead) In reality SIP trunking is often just (a lot of SIP calls) We
>> have our SIP setup so you can send many calls to many different phone
>> numbers over a single registration and that causes introp issues because
>> most people don't comprehend this lol.
>> So it seems like there could be some improvements that could clean up
>> issues with WebRTC and how web-app type environments can bust through nat
>> etc.
>> WebRTC is still compatible with SIP in the sense that you can carry a
>> WebRTC SDP over sip and set up calls but most of the time its SIP over
>> WebSockets (though FS and Kamailio can translate and negotiate WebRTC
>> sessions to other SIP transports)
>> From a server perspective with density being a major concern, removing
>> all the need for dialogs and route headers is a good thing. What I also
>> think is critical to preserve is the server's ability to limit the media
>> formats etc sent by the sender.  Killing Offer/Answer is ok but the
>> replacement should at least preserve the notions that a client can offer
>> what it can do, the server can narrow that scope with its own requirements
>> and the client must work within those shared formats.  The server is the
>> one who has to create thousands of connections etc and must not be treated
>> as a simple peer-to-peer agent.
>> Removing SRTP is another concern because it's pretty widely used now,
>> it's required in WebRTC and decryption in the middle was something I was
>> hoping we would go the other direction on and find ways to route encrypted
>> packets without needing to decode them.
> One reason we are focusing on client-to-server vs peer-to-peer is that it
> avoids the interop issues associated with p2p (i.e., the difference between
> connecting to the server that you control vs various peers that you don't
> control). Also, WebRTC already works well for the peer-to-peer case.

As a server, I appreciate that because it makes scaling much easier to have
the power to dictate things.

> I also think that whatever we come up with to replace SRTP will probably
> be able to gateway to SRTP easily for systems that expect SRTP.

>> I think if you want to replace SIP trunking more considerations have to
>> be made for the mass translation of TDM/SIP/SS7 and how that works with
>> routing and clustering.  I think some of that is how we got into that boat
>> with SIP because it was only later that this was tried and then workarounds
>> abounded for years.
>> On Mon, Mar 23, 2020 at 12: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
>> --
>> Anthony Minessale  | Founder and CEO
>> SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303
>> <,+Palo+Alto,+CA+94303&entry=gmail&source=g>*
>> * <>*
>> <>
>> Email:
>> Phone: 262-309-8501 <(262)%20309-8501>
>> Website: <>
>> <>
>> <>


Anthony Minessale  | Founder and CEO

SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303

* <>* <>


Phone: 262-309-8501

Website: <>