Re: [V3] Thoughts on scope for ript

Justin Uberti <> Mon, 23 March 2020 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0652E3A0BDA for <>; Mon, 23 Mar 2020 15:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.489
X-Spam-Status: No, score=-17.489 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, 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, 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 iNaNpp913XqL for <>; Mon, 23 Mar 2020 15:43:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9ED133A05AC for <>; Mon, 23 Mar 2020 15:43:13 -0700 (PDT)
Received: by with SMTP id o124so4309868vkc.4 for <>; Mon, 23 Mar 2020 15:43:13 -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=ycPAtK00Fr2ZZ5+iW0R3GBsa4E6b9BoH5l5D+ob3jus=; b=pPINqh90zyKq05FqUFqZhMoTPXkjgSf3J0gPuHLivOngR2IOCAqqy4guGvKHaVgjNI /Ttr/9eFjjgIn87G6p+v8ED3fD3Vm213da3cTlvZwVDW/QuI7fIcBgFsemU6UAa1ijnl QigLI5MJipE5MdA+8olDV/pUkXvhtLR16Pm01SfJwOBD9M+BuVrUqomJmR/XwbQx0Aw3 0j0SoebNFVvIASNE1LoAqKf0ED3pMFWO3/d9wh2BvQQsISDL71kVRew6s9vNGEe7eLtR 68GADF3aBGJNk0TdCNvkmdHxZ/K3YxWScxBla2DI/rtvtIgyzj8MZ0Vknctl8VdGyOcZ kUPg==
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=ycPAtK00Fr2ZZ5+iW0R3GBsa4E6b9BoH5l5D+ob3jus=; b=AvHDTzmqYIhDHtx47d3v6dOHzFLIsGyOYbyzYby+AHDeP2sbTUhreE7EBu8+gAw4bS R9lyaFmJZoeh6TPZokKZdNZJ0c4nCJttgQKvBs434ulq7cAnO1lX5vw0dgvXijMSwe8a sRTLV7or8k1eQTHuUoethdHOazjv8JAjaHVdEVX2KfLBb0v+akf921IFb9XCgwFlPDmK J5TDO1jyesXsIB/0kze7GmYvDxPgGIrPtJ66N7HGq82RY/kKetn4I+IbQ8MHaL5FlBCB +KWPN18z9zdB7QQeofnxXQC2Oed/dbxhMhlv6cwf7hFtkBoCw5mASEgA/uQ4fKAhgXvy TxaA==
X-Gm-Message-State: ANhLgQ2XTtk9xHPkhcDwbnXLcIIoR1eopkZnG1WYR6JsO7XBaS4YIj2W c61vL5n/GQeny9b1SxYz98YfLxLelbyhp/uRR5yyPA==
X-Google-Smtp-Source: ADFU+vtknME3X8W/GfCrR9ThztOK3fCiUUQhwobSGuS1SvuQPfNBnMvJu0o0HKq0GP2jaulnPdltLVqUNFkA4XN8s2U=
X-Received: by 2002:a05:6122:2d0:: with SMTP id k16mr3124937vki.54.1585003391822; Mon, 23 Mar 2020 15:43:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Mon, 23 Mar 2020 15:43:00 -0700
Message-ID: <>
To: Anthony Minessale <>
Cc: Jonathan Rosenberg <>, "" <>
Content-Type: multipart/related; boundary="000000000000246d5005a18d5c43"
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 22:43:18 -0000

On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale <>

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

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