Re: [V3] Thoughts on scope for ript

Anthony Minessale <anthm@signalwire.com> Mon, 23 March 2020 23:38 UTC

Return-Path: <anthm@signalwire.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 B62D63A0F1A for <v3@ietfa.amsl.com>; Mon, 23 Mar 2020 16:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=signalwire.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 hhuB4MvtCPwT for <v3@ietfa.amsl.com>; Mon, 23 Mar 2020 16:38:37 -0700 (PDT)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 7F92A3A0F1B for <v3@ietf.org>; Mon, 23 Mar 2020 16:38:37 -0700 (PDT)
Received: by mail-vk1-xa33.google.com with SMTP id r129so4334825vkr.6 for <v3@ietf.org>; Mon, 23 Mar 2020 16:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signalwire.com; 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; d=1e100.net; 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: <BYAPR06MB4391FBC64E195E87003061B8FBF00@BYAPR06MB4391.namprd06.prod.outlook.com> <CAOJ7v-0MP4p=tpzgNJu1Mxgt8cv4PL01PbQWhTzN6bYSQR9Yuw@mail.gmail.com> <CAMcSUfGZcTPLNQvFC9YRViPqa=VWM4Ba9XOWTZCpia9MT8K-Fg@mail.gmail.com> <CAOJ7v-1t=WHFNuxSGV=ErXMhPTMEpsyx0KWH=3+RsLMyw+1abg@mail.gmail.com>
In-Reply-To: <CAOJ7v-1t=WHFNuxSGV=ErXMhPTMEpsyx0KWH=3+RsLMyw+1abg@mail.gmail.com>
From: Anthony Minessale <anthm@signalwire.com>
Date: Mon, 23 Mar 2020 18:38:24 -0500
Message-ID: <CAMcSUfE2tOujtWuHu9Evserbn31f+uWohw0tJmqcGv46Pn5mnA@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Jonathan Rosenberg <jdrosen@five9.com>, "v3@ietf.org" <v3@ietf.org>
Content-Type: multipart/related; boundary="00000000000046c2ac05a18e2204"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/OZ96fFrWffGmEzkFgDxSfUk2leE>
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: Mon, 23 Mar 2020 23:38:41 -0000

On Mon, Mar 23, 2020 at 5:43 PM Justin Uberti <juberti@google.com> wrote:

>
> On Mon, Mar 23, 2020 at 3:24 PM Anthony Minessale <anthm@signalwire.com>
> 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=
>> 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
>>>
>>
>>
>> --
>>
>>
>> Anthony Minessale  | Founder and CEO
>>
>> SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303
>> <https://maps.google.com/?q=228+Hamilton+Ave+3rd+Floor,+Palo+Alto,+CA+94303&entry=gmail&source=g>*
>>
>> *https://youtu.be/WKjZkzgK4pc <https://youtu.be/WKjZkzgK4pc>*
>>
>> https://youtu.be/MwqpSl7luSM
>>
>> https://youtu.be/l82JtCECkog
>> <https://www.youtube.com/watch?v=l82JtCECkog>
>>
>> Email: anthm@signalwire.com
>>
>> Phone: 262-309-8501 <(262)%20309-8501>
>>
>> Website: <https://www.freeswitch.com/>https://www.signalwire.com
>> <https://www.facebook.com/search/top/?q=signalwire>
>> <https://twitter.com/SignalWire>
>>
>>
>>

-- 


Anthony Minessale  | Founder and CEO

SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303
<https://maps.google.com/?q=228+Hamilton+Ave+3rd+Floor,+Palo+Alto,+CA+94303&entry=gmail&source=g>*

*https://youtu.be/WKjZkzgK4pc <https://youtu.be/WKjZkzgK4pc>*

https://youtu.be/MwqpSl7luSM

https://youtu.be/l82JtCECkog <https://www.youtube.com/watch?v=l82JtCECkog>

Email: anthm@signalwire.com

Phone: 262-309-8501

Website: <https://www.freeswitch.com/>https://www.signalwire.com
<https://www.facebook.com/search/top/?q=signalwire>
<https://twitter.com/SignalWire>