Re: [V3] Thoughts on scope for ript

[Anthony Minessale <[e-mail]>]

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.

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=
[e-mail]> 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 <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v3
>>
> --
> V3 mailing list
> [e-mail]
> 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: [e-mail]

Phone: [phone]

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