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]
