Internet DRAFT - draft-rosenberg-dispatch-ript-sipdiffs

draft-rosenberg-dispatch-ript-sipdiffs







Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Standards Track                        February 7, 2020
Expires: August 10, 2020


  Real Time Internet Peering for Telephony (RIPT) Comparison with the
                    Session Initiaton Protocol (SIP)
               draft-rosenberg-dispatch-ript-sipdiffs-00

Abstract

   The Real-Time Internet Peering for Telephony (RIPT) protocol and its
   extension for inbound calls to single user devices provide an
   alternative to the Session Initiation Protocol (SIP) for several use
   cases.  This leads to many questions - how is RIPT different from SIP
   and why?  What should be standardized and what should not?  How much
   of SIP do those two specifications replace?  This document discusses
   the differences and their motivations, and presents an analysis
   across the set of SIP specifications, and analyzes whether the two
   RIPT documents replace each with similar capability, whether they
   eliminate the need for that specification, or whether some or all of
   that specification are not addressed by RIPT.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 10, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Rosenberg                Expires August 10, 2020                [Page 1]

Internet-Draft                RIPT vs. SIP                 February 2020


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  How is RIPT Different from SIPT?  . . . . . . . . . . . . . .   5
     2.1.  Ontop of HTTP, not Alongside of HTTP  . . . . . . . . . .   6
     2.2.  State Lives in Servers, not on Clients  . . . . . . . . .   7
     2.3.  Configuration is Automatic, not Manual  . . . . . . . . .   8
     2.4.  Secure CallerID Only, not Insecure  . . . . . . . . . . .   8
     2.5.  HTTP Load Balancing, not DNS or SIP Proxies . . . . . . .   9
     2.6.  Client-Server, not Multi-Element  . . . . . . . . . . . .  10
     2.7.  Client-Server, not Agent-to-Agent . . . . . . . . . . . .  11
     2.8.  Signaling and Media Together  . . . . . . . . . . . . . .  11
     2.9.  URIs not IPs  . . . . . . . . . . . . . . . . . . . . . .  12
     2.10. OAuth not MTLS or private IP  . . . . . . . . . . . . . .  12
     2.11. TLS not SRTP or SIPS  . . . . . . . . . . . . . . . . . .  13
     2.12. Calls Separate from Connections . . . . . . . . . . . . .  13
     2.13. Path Validation, not ICE  . . . . . . . . . . . . . . . .  14
     2.14. Load Balancer Stickiness, not Contact header field and
           RTP IPs . . . . . . . . . . . . . . . . . . . . . . . . .  14
   3.  What should be Standardized?  . . . . . . . . . . . . . . . .  15
   4.  Can RIPT Really Replace SIP?  . . . . . . . . . . . . . . . .  17
     4.1.  Core Specifications . . . . . . . . . . . . . . . . . . .  17
       4.1.1.  The Main SIP Spec - RFC3261 . . . . . . . . . . . . .  17
       4.1.2.  RFC3262 - Reliability of Provisional Responses  . . .  19
       4.1.3.  RFC3263 - DNS SRV for SIP . . . . . . . . . . . . . .  19
       4.1.4.  RFC3264 - Offer/Answer  . . . . . . . . . . . . . . .  19
       4.1.5.  RFC3265 - SIP Events  . . . . . . . . . . . . . . . .  20
     4.2.  SIP Extensions  . . . . . . . . . . . . . . . . . . . . .  21
       4.2.1.  SIP INFO (RFC 2976) . . . . . . . . . . . . . . . . .  21
       4.2.2.  UPDATE (RFC 3311) . . . . . . . . . . . . . . . . . .  21
       4.2.3.  Resource Management and SIP (RFC 3312)  . . . . . . .  22
       4.2.4.  Privacy Header (RFC 3323) . . . . . . . . . . . . . .  22
       4.2.5.  P-Asserted-ID (RFC 3325)  . . . . . . . . . . . . . .  22
       4.2.6.  Reason header field (RFC 3326)  . . . . . . . . . . .  22
       4.2.7.  Service-Route (RFC 3327)  . . . . . . . . . . . . . .  22
       4.2.8.  REFER (RFC 3515)  . . . . . . . . . . . . . . . . . .  22
       4.2.9.  Symmetric Response Routing (RFC 3581) . . . . . . . .  22
       4.2.10. Registration Event Package (RFC 3680) . . . . . . . .  22
       4.2.11. Third Party Call Controll (RFC 3725)  . . . . . . . .  22
       4.2.12. E.164 and SIP (RFC 3824)  . . . . . . . . . . . . . .  22



Rosenberg                Expires August 10, 2020                [Page 2]

Internet-Draft                RIPT vs. SIP                 February 2020


       4.2.13. UA Capabilities (RFC 3840)  . . . . . . . . . . . . .  22
       4.2.14. Caller Prefs (RFC 3841) . . . . . . . . . . . . . . .  23
       4.2.15. Replaces Header Field (RFC 3891)  . . . . . . . . . .  23
       4.2.16. Referred-By (RFC 3892)  . . . . . . . . . . . . . . .  23
       4.2.17. PUBLISH method (RFC 3903) . . . . . . . . . . . . . .  23
       4.2.18. Join Header Field (RFC 3911)  . . . . . . . . . . . .  23
       4.2.19. Early Media (RFC 3960)  . . . . . . . . . . . . . . .  23
       4.2.20. Session Timers (RFC 4028) . . . . . . . . . . . . . .  23
       4.2.21. INVITE Dialog Event Package (RFC 4235)  . . . . . . .  23
       4.2.22. Request History (RFC 4244)  . . . . . . . . . . . . .  23
       4.2.23. Actions for non-INVITE?? (RFC 4320) . . . . . . . . .  23
       4.2.24. Pre-Emption Events (RFC 4411) . . . . . . . . . . . .  23
       4.2.25. Resource-Priority . . . . . . . . . . . . . . . . . .  24
       4.2.26. Suppression of Implied REFER Subscription (RFC 4488)   24
       4.2.27. Conveying Feature Tags (RFC 4508) . . . . . . . . . .  24
       4.2.28. Request Auth?? (RFC 4538) . . . . . . . . . . . . . .  24
       4.2.29. KPML (RFC 4730) . . . . . . . . . . . . . . . . . . .  24
       4.2.30. representing trunk groups (RFC 4904)  . . . . . . . .  24
       4.2.31. Connected Identity (RFC 4916) . . . . . . . . . . . .  24
       4.2.32. Dial String (RFC 4967)  . . . . . . . . . . . . . . .  24
       4.2.33. URN for emergency services (RFC 5031) . . . . . . . .  24
       4.2.34. Rejecting Anonymous Requests (RFC 5079) . . . . . . .  24
       4.2.35. Real-Time Text (RFC 5194) . . . . . . . . . . . . . .  24
       4.2.36. Answering Modes ?? (RFC 5373) . . . . . . . . . . . .  25
       4.2.37. SIP Outbound (RFC 5626) . . . . . . . . . . . . . . .  25
       4.2.38. GRUU (RFC 5627) . . . . . . . . . . . . . . . . . . .  25
       4.2.39. App Interaction Framework (RFC 5629)  . . . . . . . .  25
       4.2.40. SIP Session Mobility (RFC 5621) . . . . . . . . . . .  25
       4.2.41. Diversion (RFC 5806)  . . . . . . . . . . . . . . . .  25
       4.2.42. Domain Certs (RFC 5922) . . . . . . . . . . . . . . .  25
       4.2.43. Connection Reuse (RFC 5923) . . . . . . . . . . . . .  25
       4.2.44. UA Config (RFC 6011)  . . . . . . . . . . . . . . . .  25
       4.2.45. Event Package for Call Quality (RFC 6035) . . . . . .  25
       4.2.46. Certificate Management Service (RFC 6072) . . . . . .  25
       4.2.47. SIP e2e performance metrics (RFC 6076)  . . . . . . .  26
       4.2.48. UA Profile Delivery (RFC 6080)  . . . . . . . . . . .  26
       4.2.49. INFO method Package and Framework (RFC 6086)  . . . .  26
       4.2.50. ANAT? (RFC 6135)  . . . . . . . . . . . . . . . . . .  26
       4.2.51. registration of multiple numbersin SIP (RFC 6140) . .  26
       4.2.52. IPv6 Transition and SIP (RFC 6157)  . . . . . . . . .  26
       4.2.53. Indication of Support for Keepalive (RFC 6223)  . . .  26
       4.2.54. SIP Response for Indication of Terminated Dialog (RFC
               6228) . . . . . . . . . . . . . . . . . . . . . . . .  26
       4.2.55. Location Conveyance in SIP (RFC 6442) . . . . . . . .  26
       4.2.56. Notification for Rate Control (RFC 6446)  . . . . . .  26
       4.2.57. Filtering Location Notifications (RFC 6447) . . . . .  26
       4.2.58. SIP specific event notification (RFC 6665)  . . . . .  27
       4.2.59. Framework for Session Policy (RFC 6794) . . . . . . .  27



Rosenberg                Expires August 10, 2020                [Page 3]

Internet-Draft                RIPT vs. SIP                 February 2020


       4.2.60. SIP Events for Session Policy (RFC 6795)  . . . . . .  27
       4.2.61. UA Profile set for Media Policy (RFC 6796)  . . . . .  27
       4.2.62. Completion of Calls (RFC 6910)  . . . . . . . . . . .  27
       4.2.63. Fax over IP in SIP (RFC 6913) . . . . . . . . . . . .  27
       4.2.64. Request History (RFC 7044)  . . . . . . . . . . . . .  27
       4.2.65. SIP LOad Control Event Package (RFC 7200) . . . . . .  27
       4.2.66. Session Identifier in SIP (RFC 7329)  . . . . . . . .  27
       4.2.67. Loop Detection in SIP (RFC 7332)  . . . . . . . . . .  27
       4.2.68. SIP Overload Control (RFC 7339) . . . . . . . . . . .  27
       4.2.69. Media Traceroute (RFC 7403) . . . . . . . . . . . . .  28
       4.2.70. SIP Rate Control (RFC 7415) . . . . . . . . . . . . .  28
       4.2.71. Transporting UU Information in SIP (RFC 7433) . . . .  28
       4.2.72. URNs for Alert-Info (RFC 7462)  . . . . . . . . . . .  28
       4.2.73. Shared Appearances for an AOR (RFC 7463)  . . . . . .  28
       4.2.74. SIPREC (RFC 7866) . . . . . . . . . . . . . . . . . .  28
       4.2.75. E2E Session Identification (RFC 7989) . . . . . . . .  28
       4.2.76. Response Code for Unwanted Calls (RFC 8197) . . . . .  28
       4.2.77. Authenticated Identity Management (RFC 8224)  . . . .  28
       4.2.78. Passport (RFC 8225) . . . . . . . . . . . . . . . . .  28
       4.2.79. STIR Certs (RFC 8226) . . . . . . . . . . . . . . . .  28
       4.2.80. Content-ID (RFC 8262) . . . . . . . . . . . . . . . .  29
       4.2.81. Negotiating Human Language (RFC 8373) . . . . . . . .  29
       4.2.82. Passport for Resource Priority (RFC 8443) . . . . . .  29
       4.2.83. Marking SIP messages to be logged (RFC 8497)  . . . .  29
       4.2.84. Push Notification and SIP (RFC 8599)  . . . . . . . .  29
     4.3.  SDP Extensions  . . . . . . . . . . . . . . . . . . . . .  29
       4.3.1.  Grouping of m-lines (RFC 3388)  . . . . . . . . . . .  29
       4.3.2.  Media Auth (RFC 3521) . . . . . . . . . . . . . . . .  29
     4.4.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . .  29
       4.4.1.  STUN (RFC 5389) . . . . . . . . . . . . . . . . . . .  29
       4.4.2.  TURN (RFC 5766) . . . . . . . . . . . . . . . . . . .  29
       4.4.3.  CoMedia ( RFC 8122 )  . . . . . . . . . . . . . . . .  29
       4.4.4.  Indicating support for ICE in SDP (RFC 5768)  . . . .  30
       4.4.5.  ICE (RFC 5245)  . . . . . . . . . . . . . . . . . . .  30
       4.4.6.  ANAT (RFC 4091) . . . . . . . . . . . . . . . . . . .  30
       4.4.7.  TURN TCP (RFC 6062) . . . . . . . . . . . . . . . . .  30
       4.4.8.  TCP candidates with ICE (RFC 6544)  . . . . . . . . .  30
     4.5.  RTP Extensions (excepting Payload Types)  . . . . . . . .  30
       4.5.1.  Reduced-Size RTCP ( RFC5506 ) . . . . . . . . . . . .  30
       4.5.2.  RTP RTCP Mux  ( RFC5761 ) . . . . . . . . . . . . . .  30
       4.5.3.  SRTP ( RFC5763 )  . . . . . . . . . . . . . . . . . .  30
       4.5.4.  AVP ( RFC5104 ) . . . . . . . . . . . . . . . . . . .  30
       4.5.5.  Client to Mixer Level ( RFC  )  . . . . . . . . . . .  30
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  31
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  32






Rosenberg                Expires August 10, 2020                [Page 4]

Internet-Draft                RIPT vs. SIP                 February 2020


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119, BCP 14
   [RFC2119] and indicate requirement levels for compliant CoAP
   implementations.

   The Real-Time Internet Peering for Telephony (RIPT) protocol [TODO
   ref I-D.rosenbergjennings-dispatch-ript] and its extension for
   inbound calls to single user devices [TODO ref draft-rosenberg-
   dispatch-ript-inbound] provide an alternative to the Session
   Initiation Protocol (SIP) [RFC3261] for several use cases.

   This leads to three important questions:

   1.  How is RIPT different from SIP and why?

   2.  How much should be standardized, and how much should be
       proprietary?

   3.  How much of SIP do those two specifications replace?

   This document answers these questions.

   For the third question, it presents an analysis across the set of SIP
   specifications, and categorizes each specification as one of three
   types:

   1.  the two RIPT documents replace the document in whole with similar
       capability (replaced)

   2.  the two RIPT documents eliminate the need for that specification
       without providing a similar capability (not-needed)

   3.  the two RIPT documents do not eliminate the need for the
       capabilities of that specification, in whole or in part.  In such
       a case, a RIPT extension would be needed if this specification
       was desired as part of RIPT. (not-replaced)

2.  How is RIPT Different from SIPT?

   This section covers the many design differences and why.








Rosenberg                Expires August 10, 2020                [Page 5]

Internet-Draft                RIPT vs. SIP                 February 2020


2.1.  Ontop of HTTP, not Alongside of HTTP

   Perhaps the most important difference is that RIPT rides on top of
   HTTP, instead of being similar to (but not the same as) HTTP.

   Though SIP was inspired by HTTP, it is not HTTP itself.  SIP and HTTP
   are peers - application protocols running ontop of the Internet.  In
   the intervening years, HTTP evolved to become a general purpose
   substrate for delivering Internet applications.  It is fair to say
   that today, almost all applications users consume over the Internet
   run over HTTP (with obvious exception of inter-server email - much
   client to server email is also now run over HTTP).

   This resulted - in essence - a rift between telecommunications
   technologies and web technologies.  Both had their own protocol
   stacks, their own sets of products and services, and so on.  HTTP has
   its own set of load balancers, and SIP has different products which
   provide load balancing for it.  SIP applications have their
   techniques for HA, and HTTP applications have theirs.

   This rift has created two significant problems.  First, it has become
   increasingly difficult for SIP-based applications to be deployed into
   modern cloud platforms, which are focused on web-based applications,
   not SIP-based.  SIP-based applications are often deployed to VM or
   bare metal servers.  It is difficult to implement HA, scale,
   security, and so on in these environments.  The second (and related)
   problem is that SIP has not been able to take advantage of the
   significant innovations that have taken place for building modern,
   large scale, reliable web applications.  SIP application providers
   must build their own load balancing, HA, failover, clustering,
   security, and scaling technologies, rather than using the
   capabilities of these cloud platforms.  SIP apps are nearly
   impossible to run on Kubernetes; they cannot be built ontop of
   lambdas; they cannot sit behind global HTTP load balancers; they dont
   use OAuth for authorization - and so on.

   RIPT is an attempt to seal this rift by reunifying web and
   telecommunications technologies, with web as the "winner".

   The idea of re-converging HTTP and SIP is certainly not new, and
   indeed has been discussed in the hallways of IETF for many years.
   However, several significant limitations made this previously
   infeasible:

   1.  HTTP utilized TCP, which meant that it created head-of-line
       blocking which would delay lost packets rather than just discard
       them.  This will often provide intolerable latency for VoIP.




Rosenberg                Expires August 10, 2020                [Page 6]

Internet-Draft                RIPT vs. SIP                 February 2020


   2.  HTTP was request response, allowing the client to send requests
       and receive a response.  There as no way for a server to
       asynchronously send information to the client in an easy fashion.

   HTTP2 [RFC7540] addressed the second of these with the introduction
   of pushes and long running requests.  However, its usage of TCP was
   still a problem.  This has finally been addressed with the arrival of
   QUIC [I-D.ietf-quic-transport] and HTTP/3.  QUIC is based on UDP, and
   it introduces the concept of a stream that can be set up with zero
   RTT.  These streams are carried over UDP, and though are still
   reliable, there is no head of line blocking across streams.  This
   change has made it possible for HTTP to support real-time
   applications.

2.2.  State Lives in Servers, not on Clients

   SIP was designed with the concept that call and media state would
   live in clients at the edge, not on servers in the data center.  When
   call state lives on the edge, SIP systems were highly scalable and
   extremely reliable.  Failure of any server component did not drop
   calls or even prevent future signaling operations from taking place.

   However, this vision of SIP networks never came to pass.  In
   practice, SIP networks are full of state that resides in server
   intermediaries (softswitches, IP PBXs, SBCs, and so on), and has seen
   media transmitted through these intermediaries.  Unfortunately, the
   SIP protocol did not provide built-in mechanisms to achieve highly
   available calling in this model.  Failure of any server component
   would cause call drops.  To remedy this, many of these servers rely
   on layer 3 solutions (such as shared VIPs with proprietary state
   replication), which are expensive, hard to deploy, and of limited
   scale.  In other cases, they are absent, in which case a server
   failure will cause all calls to be dropped, requiring the end user
   themselves to re-initiate the call.

   The statefulness of most server components has also meant that
   software upgrade is a manual process.  To avoid dropped calls, it
   must be performed late at night, causing a risk of downtime.  Other
   implementations have waited for calls to drain, and then performed
   automated restarts.  This almost always requires a timeout (typically
   an hour or more) at which point calls longer than that get dropped.
   The result is that rolling software upgrades have caused some amount
   of call drops, and can take an extremely long time to propagate
   through a cluster.  This was acceptable perhaps in the era of
   traditional client-server applications where software upgrades were
   infrequent.  Modern software systems perform updates many times a
   day, which is incompatible with SIP-based systems.




Rosenberg                Expires August 10, 2020                [Page 7]

Internet-Draft                RIPT vs. SIP                 February 2020


   Consequently, RIPT is designed from ground up with the notion that
   the state lives on the server, not the client.  It then includes the
   capabilities needed to provide highly available calling, so that
   failure of a server component does not drop the call or even cause
   loss of media packets.

2.3.  Configuration is Automatic, not Manual

   The core SIP specification said nothing of configuration.  Though
   specifications were added later to cover some of it, they were not
   widely implemented, and more important, not designed with automation
   in mind.

   This has manifested most painfully in enterprise to carrier SIP
   trunking solutions, which have suffered from complex provisioning
   operations, oftentimes requiring the exchange of static IPs and ports
   and phone number ranges.  This was followed by manual configuration
   of call routing logic, selecting amongst trunk groups based on
   manually configured rules which needed to change every time some
   property of any trunk group changed.  These operations are almost
   never self-service and consequently, SIP trunk turn ups can take
   weeks on a provider and additional weeks for configuration and
   testing on the enterprise side.

   RIPT includes - as a core part of the protocol - the protocol
   exchanges needed to bootstrap a client (whether it be an IP phone or
   enterprise SBC) from nothing but the domain name of its provider, to
   fully functional interconnection, in a completely automated way.  It
   exchanges all of the information needed for automated routing logic,
   capabilities discovery, and policy validation.

2.4.  Secure CallerID Only, not Insecure

   Perhaps the biggest design mistake in SIP - which all of us who
   worked on SIP surely feel badly about - has been its abuse for the
   injection of robocalls.  The core problem is the lack of
   authenticated (aka secure) caller ID in SIP.  SIP began with
   completely unverified callerID in the form of the From header field,
   and specified nothing about how servers should handle this field.
   Multiple specifications over the years which followed attempted to
   remedy this problem.  Finally, the most recent work on STIR [RFC8224]
   brings hope to solve the problem.  However, SIP itself does not
   mandate STIR, and SIP doesn't provide the automated configuration
   needed to ensure that STIR can always be used for every call.

   RIPT remedies this in several ways.  First and foremost, the protoocl
   provides one and only one way to identify the caller - a passport.
   There is no separate unauthenticated identity which needs to



Rosenberg                Expires August 10, 2020                [Page 8]

Internet-Draft                RIPT vs. SIP                 February 2020


   sometimes be ignored or replaced.  A RIPT call always contains an
   authenticated caller ID, on any hop, and there is no other way to
   signal it.

   Furthermore, RIPT provides a simple certificate exchange which allows
   endpoints - such as an IP phone or browser client - which
   authenticates using normal web techniques ala OAuth - to obtain a
   certificate from its provider for the number that it has been
   allocated.  This means that RIPT does not depend on a server to act
   as verifier for the callerID on a call by call basis and then take
   active action to insert a passport.  Instead, it requires the client
   to obtain a certificate and insert a verified caller ID in the first
   place.  This reduces the computational burden from the servers, but
   far more importantly, it means that RIPT does not depend on any kind
   of processing of the call in order to ensure that the caller ID is
   authentic.  The caller ID is authentic and verified when the call is
   made from the originating client all the way to the terminating one.

   RIPT also provides the configuration needed in trunking scenarios for
   authenticated caller ID.  Entperprises receive configuration which
   tells them exactly what numbers they are allowed to utilize to inject
   calls.  This means there are no surprises about whether a call from
   an enterprise to a carrier will be accepted or rejected due to
   verification processes.

   In summary - there are four core problems which this specification is
   addressing in the traditional usage of SIP peering between entities:

   1.  The difficulty of deploying real-time communications servers into
       web-centric cloud platforms, which can enable modern solutions
       for load balancing, infinite scale, autoscaling, hitless software
       upgrade, and so on.

   2.  Lack of built-in protocol mechanisms for call preservation,
       scaling, software upgrade, and so on.

   3.  Lack of standardized and automated techniques for provisioning
       and configuration of SIP trunks

   4.  Lack of secure caller ID

2.5.  HTTP Load Balancing, not DNS or SIP Proxies

   Load balancing in SIP has been problematic from the start.  It was
   originally envisioned that clients would utilize DNS SRV records
   [RFC3263] for load balancing.  In practice, this suffered from two
   major problems.  Firstly, it made it difficult for service providers
   to dynamically adjust the set of servers.  This is due to highly



Rosenberg                Expires August 10, 2020                [Page 9]

Internet-Draft                RIPT vs. SIP                 February 2020


   unpredictable and slow DNS propagation.  Even using zero TTLs in DNS
   records did not guarantee that the addition or removal of a server
   would be immediately known to clients.

   The second problem is that DNS records couldn't easily account rapid
   detection of up/down state of the individual servers.

   This became remedied later on with the addition of SIP proxies for
   load balancing.  DNS A records would point to the proxies, and the
   proxies would use OPTIONS pigs to determine the up/down state of the
   servers.

   While this works OK in practice, it makess the SIP proxies a single
   point of failure.  It is difficult to scale them - they cannot
   utilize anycast, since this is incompatible with SIP behavior.
   Meanwhile, HTTP load balancing technology has evolved significantly,
   providing highly scalable load balancing based on geographic
   proximity, anycast routing, a variety of application layer health
   checks, and so on.  None of this load balancing technology can be
   used by SIP.

   For this reason, there is no notion of load balancing in RIPT itself,
   it is handled entirely by HTTP.

2.6.  Client-Server, not Multi-Element

   SIP was designed as a complete system architecture.  As such, it
   explicitly incorporates features which presume the existence of a
   network of elements - proxies and registrars in particular.  SIP
   provides many features to facilitate this - Via headers, record-
   routing, and so on.

   HTTP on the other hand - is strictly a client-to-server technology.
   Though it does support the notion of proxies (ala the CONNECT method
   for reverse proxies), the protocol is fundamentally designed to be
   between a client and an authoritative server.  What happens beyond
   that authoritative server is beyond the scope of HTTP, and can (and
   often does) include additional HTTP transactions.

   Consequently, in order to reside within HTTP, RIPT follows the same
   pattern and only concerns itself with client-server behaviours.  Like
   HTTP, a RIPT server can of course act as a RIPT client and further
   connect calls to downstream elements.  However, such behavior
   requires no additional specification and is therefore not discussed
   by RIPT.






Rosenberg                Expires August 10, 2020               [Page 10]

Internet-Draft                RIPT vs. SIP                 February 2020


2.7.  Client-Server, not Agent-to-Agent

   SIP is based fundamentally on the User Agent, and describes the
   communications between a pair of user agents.  Either user agent can
   initiate requests towards the other.  SIP defines the traditional
   role of client and server as bound to a specific transaction.

   HTTP does not operate this way.  In HTTP, one entity is a client, and
   the other is a server.  There is no way for the server to send
   messages asynchronously towards the client.  HTTP/3 does enable two
   distinct techniques that facilitate server messaging towards the
   client.  But to use them, RIPT must abide by HTTP/3 rules, and that
   means distinct roles for clients and servers.  Clients must always
   initiate connections and send requests, not servers.

   To handle this, RIPT specifies that the caller implements the RIPT
   client, and the side receiving the calls is the RIPT server.  For any
   particular call, the roles of client and server do not change.  To
   facilitate calls in either direction, an entity can implement both
   RIPT client and RIPT server roles.  However, there is no relationship
   between the two directions.

2.8.  Signaling and Media Together

   One of the most fundamental design properties of SIP was the
   separation of signalling and media.  This was fundamental to the
   success of SIP, since it enabled high quality, low latency media
   between endpoints within of an enterprise or consumer VoIP service.

   This design technique is quite hard to translate to HTTP, especially
   when considering load balancing and scaling techniques.  HTTP load
   balancing is effective because it treats each request/response pair
   as an independent action which can route to any number of backends.
   In essence, the request/response transaction is atomic, and
   consequentially RIPT needs to operate this way as well.

   Though SIP envisioned that signalling and media separation would also
   apply to inter-domain calls, in practice this has not happened.
   Inter-domain interconnect - including interconnection with the PSTN -
   is done traditionally with SBCs which terminate and re-originate
   media.  Since this specification is targeted at inter-domain peering
   cases, RIPT fundamentally combines signalling and media together on
   the same connection.  To ensure low latency, it uses multiple
   independent request/response transactions - each running in parallel
   over unique HTTP transactions (and thus unique QUIC streams) - to
   transmit media.





Rosenberg                Expires August 10, 2020               [Page 11]

Internet-Draft                RIPT vs. SIP                 February 2020


2.9.  URIs not IPs

   SIP is full of IP addresses and ports.  They are contained in Via
   headers, in Route and Record-Route headers.  In SDP.  In Contact
   headers.  The usage of IPs is one of the main reasons why SIP is so
   difficult to deploy into cloud platforms.  These platforms are based
   on the behavior of HTTP which has been based on TCP connections and
   therefore done most of its routing at the connection layer, and not
   the IP layer.

   Furthermore, modern cloud platforms are full of NATs and private IP
   space, making them inhospitable to SIP based applications which still
   struggle with NAT traversal.

   HTTP of course does not suffer from this.  In general, "addressing",
   to the degree it exists at all, is done with HTTP URIs.  RIPT follows
   this pattern.  RIPT - as a web application that uses HTTP/3 - does
   not use or convey any IP addresses or ports.  Furthermore, the client
   never provides addressing to the server - all traffic is sent in the
   reverse direction over the connection.

2.10.  OAuth not MTLS or private IP

   When used in peering arrangements today, authentication for the SIP
   connections is typically done using mutual TLS.  It is also often the
   case that security is done at the IP layer, and sometimes even via
   dedicated MPLS connections which require pre-provisioning.
   Unfortunately, these techniques are quite incompatible with how
   modern cloud platforms work.

   HTTP - due to its client-server nature, uses asymmetric techniques
   for authentication.  Most notably, certificate based authentication
   is done by the client to verify that it is speaking to the server it
   thinks it should be speaking to.  For the server to identify the
   client, modern platforms make use of OAuth2.0.  Though OAuth is not
   actually an authentication protocol, the use of OAuth has allowed
   authentication to be done out of band via separate identity servers
   which produce OAuth tokens which can then be used for authentication
   of the client.

   Consequently, RIPT follows this same approach.  The client initiates
   calls towards the server.  The server uses TLS to provide its
   identity to the client, and the client provides a token to the server
   to identify itself, with a login technique occuring elsewhere.  To
   facilitate bidirectional calls, an entity would just implement both
   the server and client roles.  For any one call, the entity placing
   the call acts as the client, and the one receiving it, as the server.
   To handle the common case where there is an asymmetric business



Rosenberg                Expires August 10, 2020               [Page 12]

Internet-Draft                RIPT vs. SIP                 February 2020


   relationship (one entity being a customer of the other), RIPT
   facilitates a simple provisioning process by which the customer can
   use an OAuth token to provision credentials for usage in the reverse
   direction.

   This specification also envisions a simple extension which would
   allow single-device clients to receive inbound calls from the server
   - however, such an extension is outside the scope of this document.

2.11.  TLS not SRTP or SIPS

   SIP has provided encryption of both signalling and media, through the
   usage of SIP over TLS and SIPS, and SRTP, respectively.
   Unfortunately, these have not been widely deployed.  The E2E nature
   of SRTP has made keying an ongoing challenge, with multiple
   technologies developed over the years.  SIP itself has seen greater
   uptake of TLS transport, but this remains uncommon largely due to the
   commonality of private IP peering as an alternative.

   Because of the HBH nature of RIPT, security is done fundamentally at
   the connection level - identically to HTTP.  Since media is also
   carrier over the HTTP connection, both signalling and media are
   covered by the connection security provided by HTTP/3.

   Because of the mandatory usage of TLS1.3 with HTTP/3, and the
   expected widespread deployment of HTTP/3, running VoIP on top of
   HTTP/3 will bring built-in encryption of media and signalling
   everywhere, which is a notable improvement over the current
   deployment situation.  It is also necessary in order to utilize
   HTTP/3.

   For reasons of interoperability, and to enable e2e media encryption
   in several cross-company or inter-provider use cases, RIPT assumes
   each media chunk may be encrypted, and if so, it contains a key ID
   which dereferences the encryption keys, ciphers and other information
   needed to decrypt the packet.  The exchange of these keys and ciphers
   is done entirely out of band of RIPT.

   However, RIPT does not support SRTP.  If a client receives a SIP call
   with SRTP, it must terminate the SRTP and decrypt media before
   sending it over RIPT.  This matches existing practice in many cases.

2.12.  Calls Separate from Connections

   In SIP, there is a fuzzy relationship between calls and connections.
   In some cases, connection failures cause call terminations, and vice
   a versa.




Rosenberg                Expires August 10, 2020               [Page 13]

Internet-Draft                RIPT vs. SIP                 February 2020


   HTTP, on the other hand, very clearly separates the state of the
   resource being manipulated, with the state of the HTTP connection
   used to manipulate it.  This design principle is inherited by RIPT.
   Consequently, call state on both client and server exist
   independently from the connections which manipulate them.  This
   allows for greater availability my enabling connections for the same
   call to move between machines in the case of failures.

2.13.  Path Validation, not ICE

   HTTP/3 is designed to work through NAT as a client-server protocol.
   It has built in techniques for dealing with NAT re-bindings, IP
   address changes due to a client moving between networks (e.g., wifi
   to cellular data).  It has built in path validation that ensures that
   HTTP cannot be used for amplification attacks.

   SIP has, over the years, solved these problems to some degree, but
   not efficiently nor completely.  To work with HTTP, RIPT must utilize
   the HTTP approaches for these problems.  Consequently, RIPT does not
   utilize ICE and has no specific considerations for NAT traversal, as
   these are handled by HTTP/3 itself.

2.14.  Load Balancer Stickiness, not Contact header field and RTP IPs

   In SIP-based systems, it is desirable for an initial INVITE to be
   load balanced across a farm of servers, but for subsequent SIP
   messages and the media to go to the server which was selected by the
   load balancer.  In SIP, this is handled by usage of the Contact
   header field for SIP and the RTP IP and ports for media.  This
   technique is utterly incompatible with HTTP load balancers, in
   addition to requiring a large number of public IPs - one for each
   server.  In HTTP systems, the origin servers utilize private IPs
   only, and a small number (often just one) public IP address is used.

   This means that SIP systems cannot use HTTP load balancers, expose
   public IPs of each server to the Internet (which is a no-no for
   modern security), and consume public IP address space in order to
   scale.  Worse yet, failure of a server means that the client can no
   longer reach the server and the call drops.

   RIPT utilizes HTTP, and therefore relies on HTTP based techniques -
   most notably, stickiness.  Most load balancers use a combination of
   session cookies and hashes of the five-tuple in order to route
   subsequent requests from the same client to the same server.  But, if
   that server has failed, requests can be routed to a different server.
   Similarly, if the farm of servers expands elastically, new requests
   get routed to the new servers but ones from existing clients "stick".
   This provides a far better solution, and means that RIPT can handle



Rosenberg                Expires August 10, 2020               [Page 14]

Internet-Draft                RIPT vs. SIP                 February 2020


   server failures gracefully.  Clients just re-initiate their requests
   and they get connected to a new server.

   That said, media processing is far better when there is locality of
   media.  As a result, RIPT provides an additional primitive that
   allows a server to explicitly move a call off of itself, or to a new
   URI.  This enables a variety of capabilities for optimization.

3.  What should be Standardized?

   Many have observed that we live in a 'post standards world'.  This
   means that a great deal of the applications users consume over the
   Internet do not require any kind of standardization efforts.  Rather,
   they utilize the Internet as a platform - with HTTP at its core - and
   build application functionality ontop of it.  Standards are not
   needed because the developer of the application develops and
   distributes the server code and any client code required for it.
   This is the formula for web and mobile applications today.

   This begs the question - if real-time communications is just another
   application, do we really need to standardize anything?

   We believe the answer is yes, and it comes down to the need for
   cross-vendor interoperability.  Communications technologies remain
   unique in that they require communication between users who utilize
   differing providers.  While this remains a requirement, there will
   remain a need for standardization.

   But where to draw the line?  We propose the following framework to
   answer this question:





















Rosenberg                Expires August 10, 2020               [Page 15]

Internet-Draft                RIPT vs. SIP                 February 2020


                                Provider 1                 Provider 2
                    +------------------------------+   +----------------
                    |                              |   |
 +-------------+    |   +--------+     +--------+  |   |   +--------+
 | Browser App |    |   |        |     |        |  |   |   |        |
 |-------------|+------>| Server |+--->| Server |+-------->| Server |
 |   Browser   |  . |   |        |  .  |        |  | . |   |        |
 +-------------+  . |   +--------+  .  +--------+  | . |   +--------+
                  . |               .              | . |
                  . +---------------.--------------+ . +----------------
                  .                 .                .
                  .                 .                .
             +----------+           .                .
   Browser   |   C->S   |           .                .
     App     | Non-Std  |      +----------+          .
 ----------  +----------+      |   S->S   |          .
   Browser   | RIPT-In  |      | Non-Std  |          .
             +----------+      +----------+     +----------+
             |   RIPT   |      |   RIPT   |     |   RIPT   |
             +----------+      +----------+     +----------+


   A communications protocol can run between the client and its provider
   (i.e., an IP phone and a VoIP service provider, or a browser
   application and its enterprise IP PBX).  It can be between server
   components within the same provider.  And it can be between
   providers.

   The one area where we absolutely require standards are on the inter-
   provider links.  Consequently, we argue that the minimum
   functionality needed to enable inter-provider voice and video
   (enterprise to carrier, or enterprise to enterprise, or carrier to
   carrier, or CCaaS to carrier, etc) represents the scope of
   functionality for the core RIPT specification.

   For the client to server, we can consider a few cases.  The most
   important one is that of a browser, which provides a separation
   between the app and the browser itself.  If RIPT were to be used
   there, we argue that the level of standardization effort should start
   and end with the minimum additions to RIPT needed for the browser to
   communicate to the server.  Everything which can exist as a browser
   application, should not be standardized.

   In the case of an IP phone, we postulate that in the coming years,
   all such hardware devices will have software architectures that
   resemble a browser - allowing the provider to customize the UI and
   client-side logic in Javascript, while the underlying firmware
   implements the browser as well as the RIPT specifications.



Rosenberg                Expires August 10, 2020               [Page 16]

Internet-Draft                RIPT vs. SIP                 February 2020


   Thick applications on mobile apps frequently dont utilize browsers.
   However, our goal is to enable all of the real-time communications
   functionality to be embedded into a library which can be added into
   any app.  The functionality of the library would be identical to the
   capabilities of the browser.

   This separation is similar to webRTC.  However, it pushes more
   functionality into the browser.  Capabilities, basic call control,
   media negotiation, call reliability and recovery from network drops,
   and so on - are all delegated to the browser.  If RIPT were to be
   implemented by a browser, its API would have primitives for placing
   calls, answering calls, and so on.

   The final component is server to server communications.  When a
   provider builds their own software, there is no need to standardize
   any of the additional capabilities ontop of RIPT.  When the provider
   utilizes off the shelf hardware (ala IMS systems), there may be such
   a need.  It is for the community to decide if such standards efforts
   are desired.

4.  Can RIPT Really Replace SIP?

   A great question!

4.1.  Core Specifications

   We first consider the core specifications - RFCs [RFC3261],
   [RFC3262], [RFC3263], [RFC3264] and [RFC3265].

4.1.1.  The Main SIP Spec - RFC3261

   There is a lot of content in this specification.  The best way to
   analyze it compared to RIPT is to examine each of the methods and
   header fields, and consider the functionality provided by them.

   The INVITE method is of course replaced by RIPT, as is the BYE
   (through the ended event).  Re-INVITE is also supported in RIPT,
   though only ever initiated by the server with a new directive.
   Clients can move calls around by specifying the usage of a different
   handler or through migrations.  Clients can change codecs mid-call,
   as long as they are within the bounds of the codecs allowed in the
   directive.

   CANCEL is replaced in [TODO ref draft-rosenberg-dispatch-ript-
   inbound] by broadcasting an event to all listeners informing them
   that the call has been answered.  The usage of CANCEL to end an
   unanswered call is replaced by the ended event in RIPT.  REGISTER is




Rosenberg                Expires August 10, 2020               [Page 17]

Internet-Draft                RIPT vs. SIP                 February 2020


   replaced by the handler construct.  ACK is not needed since RIPT is
   reliable.

   OPTIONS is replaced by the more robust and complete TG construct,
   allowing the client the ability to discover everything needed to
   interact with the services of a server.  Not just media capabilities,
   but supported phone numbers, timer values, and so on.

   Considering header fields, interestingly, a large number of them are
   focused on SIP routing features.  These include Via, Route, Record-
   Route, Contact, Max-Forwards.. These are not needed in RIPT, since
   RIPT focuses on a client to server construct.  A server can, in turn,
   re-initiate a request.  However, in SIP parlance, it would be a B2BUA
   and statefully know how to route return messages and forward requests
   later for the same call.  In such an architecture, it is not
   necessary to stash routing state into protocol headers, which is what
   these headers do.

   The SIP content headers - Accept, Accept-Encoding, Accept-Language,
   Content-Disposition, Content-Encoding, Content-Language, Content-
   Length, Content-Type, MIME-Version, are provided by underlying HTTP
   and thus are not needed in RIPT.

   The SIP diagnostic headers - Date, Organization, Server, User-Agent,
   Warning - are also provided by HTTP and not needed in RIPT.

   The SIP identifiers - To, From, Call-ID and the branch parameter, are
   replaced by the simpler single call URI which is the one and only
   identifier for a call.  This removes another piece of complexity from
   SIP - the convoluted algorithm for identifying calls, transactions,
   and call legs.  The To and From exist in RIPT, but are replaced with
   secure versions using passports.  The CSeq header field is not needed
   in RIPT since it utilizes reliable transport only, and this header
   field was only needed for transaction ordering.

   The SIP extensibility mechanisms - Require, Proxy-Require, Allow,
   Supported, and Unsupported, are not needed in RIPT.  These headers
   are necessary due to the symmetric nature of the relationship between
   entities.  In RIPT, the client uses the services of the server and
   cannot insist on anything.  The client can determine what services
   are supported through normal JSON extensibility constructs - similar
   to SIP headers - wherein unknown elements are ignored.

   The SIP security headers - Authentication-Info, Authorization, Proxy-
   Authenticate, Proxy-Authorization, WWW-Authenticate - are not needed
   in RIPT since they are all replaced with more modern security
   techniques used for HTTPS.




Rosenberg                Expires August 10, 2020               [Page 18]

Internet-Draft                RIPT vs. SIP                 February 2020


   The SIP user interface headers - Alert-Info, Priority, Reply-To, and
   Subject - which never saw widespread implementation, are not provided
   by RIPT.  Rather, per the discussion above, they would be part of the
   proprietary signaling between client and server, and not the subject
   of standardization.

   If we turn to semantics, we can consider SIP as concerning itself
   with (1) reliable message transmission and sequencing, transactions,
   success and error handling, transaction identification (2) call
   routing - including registration, forking, URI transformations, (3)
   call state management, (4) security, (5) extensibility.

   Of these - (1) is not needed in RIPT, since it is either provided by
   HTTP itself, or eliminated because RIPT doesnt concern itself with
   p2p signaling. (2) is covered in part by RIPT, and the parts not
   covered are not needed because RIPT is a client-server protocol.
   Note that, RIPT does allow a user to have multiple devices, and to
   make and receive calls on any of them.  This is accomplished by using
   the normal HTTP model wherein multiple clients can manipulate the
   resources on the server.  (3) RIPT is entirely concerned with call
   state and matches the functionality of SIP in this regard, (4) RIPT
   delegates security entirely to HTTP and other specifications like
   OAuth, and (5) RIPT

   Consequently, we believe that RIPT serves as a full replacement for
   the entirety of [RFC3261] and thus this specification is categorized
   as "replaced".

4.1.2.  RFC3262 - Reliability of Provisional Responses

   This specification is not needed in RIPT.  It was specified to handle
   complexities with UDP-based signaling transport.  RIPT only uses
   reliable transport for signaling.  This specification is therefore
   categorized as "not-needed".

4.1.3.  RFC3263 - DNS SRV for SIP

   This specification is not needed in RIPT.  DNS resolution is a
   function of HTTP and provided by A and AAAA records, not SRV.  The
   load balancing properties of the SRV record never worked well, and
   are replaced by the far more robust techniques used with HTTP.  This
   specification is therefore categorized as "not-needed".

4.1.4.  RFC3264 - Offer/Answer

   This specification, more than any other, is the one people love to
   hate.  It has also proven incredibly robust, extended dramatically
   beyond its humble origines.  RIPT abandons the offer/answer model



Rosenberg                Expires August 10, 2020               [Page 19]

Internet-Draft                RIPT vs. SIP                 February 2020


   entirely, favoring a model in which the server is always in control.
   Consequently, it is replaced by an "advertisement/directive" model.
   At its core, offer/answer allowed clients to indicate their
   capabilities and for media streams to be set up and configured.  RIPT
   provides this functionality, though differently.

   Much of the complexity of RFC3264 derives from the fact that calls
   can fork, creating a situation in which one offer can generate
   multiple answers.  This capability is removed from RIPT (which is
   strictly client to server for signaling and media), eliminating that
   complexity.  RFC3264 also concerns itself with matching of streams
   between offer and answer, and then how those are mapped to RTP
   concepts like IP addresses and ports.  All of that is replaced with
   explicit stream identifiers in RIPT.  Combined with the fact that
   media follows signaling, this eliminates the challenges in stream
   identification while also eliminating the usage of IP addresses and
   ports for stream identification - the latter being one of the reasons
   why SIP is so troublesome in network environments.

   RFC3264 also allows for the client to request all kinds of changes -
   adding a stream, removing a stream, modifying a stream, and so on.
   In RIPT, these are possible.  However, to perform them, the client
   signals the server with its desired operation - through mechanisms
   outside of the scope of standardization - and the server uses the set
   of capabilities it has to generate a new proposal that is sent to the
   client.  As an example, 'turn on video' would be accomplished by the
   client signaling such a desire to the server via non-standard means,
   and then the server providing a new proposal to the client that tells
   it to start sending video.

   Consequently, this specification is categorized as "replaced".

4.1.5.  RFC3265 - SIP Events

   This specification provided a generic mechanism for clients to
   subscribe to events and receive notifications for them.  This
   capability exists in RIPT using long-running GET to the /events
   endpoint on the call resource, and uses the lifecycle of the
   transaction to manage the lifecycle of the subscription.  RIPT does
   not provide a generic framework for eventing, and rather allows that
   to be handled by proprietary means.

   Consequently, this specification is categorized as "replaced".








Rosenberg                Expires August 10, 2020               [Page 20]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.  SIP Extensions

   There are many SIP extensions, we do not consider all of them.
   Extensions which are corrections to other specifications are not
   considered. 3GPP specific extensions are not considered.  Extensions
   specific to SIMPLE are not considered, and in general, presence and
   IM (which is out of scope for RIPT) is not considered.  Generally,
   informational and experimental specifications are not considered,
   though there are some exceptions when they have effectively become
   normative in nature.

4.2.1.  SIP INFO (RFC 2976)

   [RFC2976] provides a generic mechanism to carry information across
   the entire call path from one UA to another.  Of its originally
   envisioned use cases, the one that achieved widespread usage was for
   DTMF.  It has also become a repository for a large number of
   proprietary extensions to SIP.

   As a framework capability, there is no equivalent in RIPT.  This is
   because RIPT doesnt define procedures for how a server, upon
   receiving information from a client, passes it to downstream servers
   in outbound requests it initiates.  RIPT is strictly a client-server
   protocol.  Clients can add proprietary information in the JSON.

   For DTMF - RIPT requires [RFC2833].  Given that RIPT is a client-
   server protocol where media and signaling follow each other, there is
   no reason to have a separate way to signal DTMF from the client to
   the server outside of RFC2833, which - when used with RIPT - is also
   from client to server.

   As a result, this specification is characterized as "not needed".

4.2.2.  UPDATE (RFC 3311)

   [RFC3311] was specified to allow a client to modify the parameters of
   the media session without impacting the SIP dialog.  It was used to
   allow modification of media information before the call was answered,
   with a fresh SDP offer.

   In RIPT, this is not needed.  A client would signal to the server
   that it wishes to modify some aspect of the session - for example -
   adding video - and then the server would generate a new directive
   which the client follows.  That process can happen at any time in the
   lifecycle of the call.

   As a result, this specification is characterized as "not needed".




Rosenberg                Expires August 10, 2020               [Page 21]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.3.  Resource Management and SIP (RFC 3312)

   TODO

4.2.4.  Privacy Header (RFC 3323)

   TODO

4.2.5.  P-Asserted-ID (RFC 3325)

   TODO

4.2.6.  Reason header field (RFC 3326)

   TODO

4.2.7.  Service-Route (RFC 3327)

   TODO

4.2.8.  REFER (RFC 3515)

   TODO

4.2.9.  Symmetric Response Routing (RFC 3581)

   TODO

4.2.10.  Registration Event Package (RFC 3680)

   TODO

4.2.11.  Third Party Call Controll (RFC 3725)

   TODO

4.2.12.  E.164 and SIP (RFC 3824)

   TODO

4.2.13.  UA Capabilities (RFC 3840)

   TODO








Rosenberg                Expires August 10, 2020               [Page 22]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.14.  Caller Prefs (RFC 3841)

   TODO

4.2.15.  Replaces Header Field (RFC 3891)

   TODO

4.2.16.  Referred-By (RFC 3892)

   TODO

4.2.17.  PUBLISH method (RFC 3903)

   TODO

4.2.18.  Join Header Field (RFC 3911)

   TODO

4.2.19.  Early Media (RFC 3960)

   TODO

4.2.20.  Session Timers (RFC 4028)

   TODO

4.2.21.  INVITE Dialog Event Package (RFC 4235)

   TODO

4.2.22.  Request History (RFC 4244)

   TODO

4.2.23.  Actions for non-INVITE?? (RFC 4320)

   TODO

4.2.24.  Pre-Emption Events (RFC 4411)

   TODO








Rosenberg                Expires August 10, 2020               [Page 23]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.25.  Resource-Priority

   TODO

4.2.26.  Suppression of Implied REFER Subscription (RFC 4488)

   TODO

4.2.27.  Conveying Feature Tags (RFC 4508)

   TODO

4.2.28.  Request Auth?? (RFC 4538)

   TODO

4.2.29.  KPML (RFC 4730)

   TODO

4.2.30.  representing trunk groups (RFC 4904)

   TODO

4.2.31.  Connected Identity (RFC 4916)

   TODO

4.2.32.  Dial String (RFC 4967)

   TODO

4.2.33.  URN for emergency services (RFC 5031)

   TODO

4.2.34.  Rejecting Anonymous Requests (RFC 5079)

   TODO

4.2.35.  Real-Time Text (RFC 5194)

   TODO








Rosenberg                Expires August 10, 2020               [Page 24]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.36.  Answering Modes ?? (RFC 5373)

   TODO

4.2.37.  SIP Outbound (RFC 5626)

   TODO

4.2.38.  GRUU (RFC 5627)

   TODO

4.2.39.  App Interaction Framework (RFC 5629)

   TODO

4.2.40.  SIP Session Mobility (RFC 5621)

   TODO

4.2.41.  Diversion (RFC 5806)

   TODO

4.2.42.  Domain Certs (RFC 5922)

   TODO

4.2.43.  Connection Reuse (RFC 5923)

   TODO

4.2.44.  UA Config (RFC 6011)

   TODO

4.2.45.  Event Package for Call Quality (RFC 6035)

   TODO

4.2.46.  Certificate Management Service (RFC 6072)

   TODO








Rosenberg                Expires August 10, 2020               [Page 25]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.47.  SIP e2e performance metrics (RFC 6076)

   TODO

4.2.48.  UA Profile Delivery (RFC 6080)

   TODO

4.2.49.  INFO method Package and Framework (RFC 6086)

   TODO

4.2.50.  ANAT?  (RFC 6135)

   TODO

4.2.51.  registration of multiple numbersin SIP (RFC 6140)

   TODO

4.2.52.  IPv6 Transition and SIP (RFC 6157)

   TODO

4.2.53.  Indication of Support for Keepalive (RFC 6223)

   TODO

4.2.54.  SIP Response for Indication of Terminated Dialog (RFC 6228)

   TODO

4.2.55.  Location Conveyance in SIP (RFC 6442)

   TODO

4.2.56.  Notification for Rate Control (RFC 6446)

   TODO

4.2.57.  Filtering Location Notifications (RFC 6447)

   TODO








Rosenberg                Expires August 10, 2020               [Page 26]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.58.  SIP specific event notification (RFC 6665)

   TODO

4.2.59.  Framework for Session Policy (RFC 6794)

   TODO

4.2.60.  SIP Events for Session Policy (RFC 6795)

   TODO

4.2.61.  UA Profile set for Media Policy (RFC 6796)

   TODO

4.2.62.  Completion of Calls (RFC 6910)

   TODO

4.2.63.  Fax over IP in SIP (RFC 6913)

   TODO

4.2.64.  Request History (RFC 7044)

   TODO

4.2.65.  SIP LOad Control Event Package (RFC 7200)

   TODO

4.2.66.  Session Identifier in SIP (RFC 7329)

   TODO

4.2.67.  Loop Detection in SIP (RFC 7332)

   TODO

4.2.68.  SIP Overload Control (RFC 7339)

   TODO








Rosenberg                Expires August 10, 2020               [Page 27]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.69.  Media Traceroute (RFC 7403)

   TODO

4.2.70.  SIP Rate Control (RFC 7415)

   TODO

4.2.71.  Transporting UU Information in SIP (RFC 7433)

   TODO

4.2.72.  URNs for Alert-Info (RFC 7462)

   TODO

4.2.73.  Shared Appearances for an AOR (RFC 7463)

   TODO

4.2.74.  SIPREC (RFC 7866)

   TODO

4.2.75.  E2E Session Identification (RFC 7989)

   TODO

4.2.76.  Response Code for Unwanted Calls (RFC 8197)

   TODO

4.2.77.  Authenticated Identity Management (RFC 8224)

   TODO

4.2.78.  Passport (RFC 8225)

   TODO

4.2.79.  STIR Certs (RFC 8226)

   TODO








Rosenberg                Expires August 10, 2020               [Page 28]

Internet-Draft                RIPT vs. SIP                 February 2020


4.2.80.  Content-ID (RFC 8262)

   TODO

4.2.81.  Negotiating Human Language (RFC 8373)

   TODO

4.2.82.  Passport for Resource Priority (RFC 8443)

   TODO

4.2.83.  Marking SIP messages to be logged (RFC 8497)

   TODO

4.2.84.  Push Notification and SIP (RFC 8599)

   TODO

4.3.  SDP Extensions

4.3.1.  Grouping of m-lines (RFC 3388)

   TODO

4.3.2.  Media Auth (RFC 3521)

   TODO

4.4.  NAT Traversal

4.4.1.  STUN (RFC 5389)

   TODO

4.4.2.  TURN (RFC 5766)

   TODO

4.4.3.  CoMedia ( RFC 8122 )

   TODO








Rosenberg                Expires August 10, 2020               [Page 29]

Internet-Draft                RIPT vs. SIP                 February 2020


4.4.4.  Indicating support for ICE in SDP (RFC 5768)

   TODO

4.4.5.  ICE (RFC 5245)

   TODO

4.4.6.  ANAT (RFC 4091)

   TODO

4.4.7.  TURN TCP (RFC 6062)

   TODO

4.4.8.  TCP candidates with ICE (RFC 6544)

   TODO

4.5.  RTP Extensions (excepting Payload Types)

   TODO

4.5.1.  Reduced-Size RTCP ( RFC5506 )

   TODO

4.5.2.  RTP RTCP Mux ( RFC5761 )

   TODO

4.5.3.  SRTP ( RFC5763 )

   TODO

4.5.4.  AVP ( RFC5104 )

   TODO

4.5.5.  Client to Mixer Level ( RFC )

   TODO








Rosenberg                Expires August 10, 2020               [Page 30]

Internet-Draft                RIPT vs. SIP                 February 2020


5.  Informative References

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-25 (work
              in progress), January 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2833]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
              Digits, Telephony Tones and Telephony Signals", RFC 2833,
              DOI 10.17487/RFC2833, May 2000,
              <https://www.rfc-editor.org/info/rfc2833>.

   [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976,
              DOI 10.17487/RFC2976, October 2000,
              <https://www.rfc-editor.org/info/rfc2976>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
              <https://www.rfc-editor.org/info/rfc3262>.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              DOI 10.17487/RFC3263, June 2002,
              <https://www.rfc-editor.org/info/rfc3263>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <https://www.rfc-editor.org/info/rfc3264>.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, DOI 10.17487/RFC3265, June
              2002, <https://www.rfc-editor.org/info/rfc3265>.






Rosenberg                Expires August 10, 2020               [Page 31]

Internet-Draft                RIPT vs. SIP                 February 2020


   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
              2002, <https://www.rfc-editor.org/info/rfc3311>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,
              <https://www.rfc-editor.org/info/rfc8224>.

Author's Address

   Jonathan Rosenberg
   Five9

   Email: jdrosen@jdrosen.net






























Rosenberg                Expires August 10, 2020               [Page 32]