Internet DRAFT - draft-rosenberg-dispatch-cloudsip
draft-rosenberg-dispatch-cloudsip
Network Working Group J. Rosenberg
Internet-Draft Five9
Expires: August 25, 2021 C. Jennings
Cisco
T. Asveren
Ribbon Communications
February 21, 2021
SIP Extensions for High Availability and Load Balancing for Public Cloud
draft-rosenberg-dispatch-cloudsip-00
Abstract
Software making use of the Session Initiation Protocol (SIP) faces
challenges in achieving high availability, especially for call
stateful applications like softswitches, Session Border Controllers
(SBCs), and IP-based call centers applications. The state maintained
in the SIP, SDP and SRTP layers changes frequently, and is difficult
to replicate. For this reason, commercial systems have often relied
on complex active-standby configurations making use of IP address
takeover. These solutions are also ill-suited for usage in modern
public cloud environments. This document defines a SIP extension
facilitating HA, including keeping calls active, which is optimized
for server-to-server communication where one or both sides are in
public cloud.
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 25, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rosenberg, et al. Expires August 25, 2021 [Page 1]
Internet-Draft Cloud SIP February 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Relationship to RIPT . . . . . . . . . . . . . . . . . . . . 5
5. Reference Architecture . . . . . . . . . . . . . . . . . . . 5
6. Solution Applicability . . . . . . . . . . . . . . . . . . . 6
7. Overview of Solution . . . . . . . . . . . . . . . . . . . . 7
8. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 8
9. SIP Behavioral Requirements . . . . . . . . . . . . . . . . . 9
9.1. Calling Server . . . . . . . . . . . . . . . . . . . . . 9
9.1.1. Health Probing . . . . . . . . . . . . . . . . . . . 9
9.1.2. Utilization Measurement . . . . . . . . . . . . . . . 9
9.1.3. New Call Initiation . . . . . . . . . . . . . . . . . 10
9.1.4. Instance Failure . . . . . . . . . . . . . . . . . . 10
9.1.5. Instance to Inactive . . . . . . . . . . . . . . . . 10
9.1.6. Receiving a REFER . . . . . . . . . . . . . . . . . . 11
9.2. Cluster Instances . . . . . . . . . . . . . . . . . . . . 11
9.2.1. Sending Utilization Values . . . . . . . . . . . . . 11
9.2.2. Receiving INVITE w. Replaces . . . . . . . . . . . . 12
9.2.3. Graceful Shutdown with Migration . . . . . . . . . . 12
9.2.4. Graceful Shutdown without Migration . . . . . . . . . 12
9.3. Moving a Dialog . . . . . . . . . . . . . . . . . . . . . 13
10. Cloud SIP Trunk Configuration File . . . . . . . . . . . . . 13
11. Webhook Registration Object . . . . . . . . . . . . . . . . . 14
12. Instance-Utilization Header Field . . . . . . . . . . . . . . 14
13. Why not DNS . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
15. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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
Rosenberg, et al. Expires August 25, 2021 [Page 2]
Internet-Draft Cloud SIP February 2021
[RFC2119] and indicate requirement levels for compliant CoAP
implementations.
Software making use of the Session Initiation Protocol (SIP)
[RFC3261] faces challenges in achieving high availability, especially
for call stateful applications like softswitches, Session Border
Controllers (SBCs), and IP-based call centers applications. The
state maintained in the SIP, Session Description Protocol (SDP)
Offer/Answer [RFC3264] and Secure Real Time Transport Protocol (SRTP)
[RFC3711] layers changes frequently, and is difficult to replicate.
For this reason, commercial systems have often relied on complex
active-standby configurations making use of IP address takeover.
These solutions are also ill-suited for usage in modern public cloud
environments. SIP assumed server-side components would not maintain
call state, and thus it never had built-in mechanisms to facilitate
server side HA. In practice, the vast majority of server deployments
are B2BUAs and maintain call state.
Besides the challenges in replicating call state, SIP also struggles
in achieving HA in modern cloud deployments making use of elastic
compute. In these environments, the underlying cloud platform (such
as kubernetes), can automatically add and remove instances to a
cluster based on usage. Similarly, they will remove elements from
the cluster which fail health checks. This information needs to
propagate quickly to upstream elements, in order to avoid sending
calls to failed or overloaded instances. SIP envisioned that a DNS-
based solution using SRV records, [RFC3263] would be sufficient.
However, DNS changes are slow to propagate and unpredictable.
Commercial implementations have made use of SIP OPTIONS probing to
assess liveliness, without standardized behavior. There is also no
standardized way to communicate or update the IP addresses used in a
cluster of servers.
This specification seeks to remedy these gaps. It defines a simple
SIP extension, which is largely a definition of mandatory behaviors
for SIP elements, that enable rapid detection and recovery from a
failed instance while ensuring that calls do not drop. It also
defines a small protocol for retrieving and pushing the set of
instances in a cluster so support elastic expansion and contraction
of a cluster in a fully automated fashion.
2. Applicability
This extension is focused on server-to-server use cases, where one or
both sides are a cluster of servers deployed in a public cloud
environment. Examples of these situations include SIP trunks between
a PSTN carrier and an enterprise, a PSTN carrier and a VOIP provider
(such as a cloud contact center), or between VOIP providers providing
Rosenberg, et al. Expires August 25, 2021 [Page 3]
Internet-Draft Cloud SIP February 2021
peering. The extension also assumes usage in bilateral peering
arrangements, and as such, provides no mechanism for discovery.
Rather, it assumes both sides have agreed to use this extension as
part of configuration provided through techniques outside the scope
of this specification.
3. Requirements
o The solution must enable a call to be recovered in less than 2
seconds. This time represents the amount of time before which a
user would hangup because they cannot hear the other party.
o A recovered call means that media continues to flow, and future
signaling for features or call hangup, can be performed
o The HA technique must not require servers in the cluster to
replicate any SIP/SDP/RTP state beyond the dialog identifiers for
calls
o The solution should minimize the changes required to the SIP and
RTP protocols and their respective implementations
o The solution must support the case where the telco is using
traditional SBCs and is not deploying kubernetes or using public
cloud
o The solution must enable fully automated elastic expansion and
contraction of clusters
o The solution must support availability, so that when an instance
in a cluster fails, new calls are distributed across the remaining
N instances
o The solution must support availability, so that when an instance
of a cluster fails, all of the active calls that were being
handled by that instance are spread across the remaining nodes in
the cluster, within 2 seconds
o The solution must support clusters wherein each instance of a
cluster has a differing amount of capacity for call handling
o The solution must support the ability for instances of a cluster
to gracefully shut down without dropping calls
Rosenberg, et al. Expires August 25, 2021 [Page 4]
Internet-Draft Cloud SIP February 2021
4. Relationship to RIPT
This protocol is similar in goals to RIPT - enabling SIP servers to
run in public cloud environments, and achieve HA through techniques
employed by web applications. RIPT attempted to solve this problem
by utilizing HTTP/3 and fully redefining SIP, repairing many of its
problems in the process. This specification is less ambitious,
focusing on the minimum changes to SIP required to facilitate HA.
As such, this specification does not alleviate the value in a full-
fledged replacement for SIP.
5. Reference Architecture
Cloud SIP uses an assymetric relationship between peers. One side
acts as the caller, and the other as the call recipient. New SIP
calls can only be placed by the caller, not by the call recipient.
If a deployment requires calls to flow in both directions, each side
acts as both caller and call recipient.
Caller Call Recipient
SIP Server Cluster
......................
. +------------+ .
+------.----| Instance 1 | .
| . +------------+ .
| . . +------------+
+---------+ | . +------------+ . | Downstream |
| Calling |----+------.----| Instance 2 |--.---------| SIP |
| Server | | . +------------+ . | UA |
+---------+ | . . +------------+
| . +------------+ .
+------.----| Instance 3 | .
. +------------+ .
......................
| |
| |
+---------+ +---------+ +---------+
| Config |<------------->| Config | | Shared |
| Sync | | Source | | DB |
+---------+ +---------+ +---------+
The calling server wishes to send calls to a cluster, which has a set
of instances. The calling server is a B2BUA, and is capable of
initiating calls, typically in response to an upstream INVITE it
receives. The calling server itself may be a member of a cluster.
Rosenberg, et al. Expires August 25, 2021 [Page 5]
Internet-Draft Cloud SIP February 2021
When the calling server wishes to generate a new INVITE for a new
call, it load balances them amongst the instances in the cluster.
Consider a specific call that was sent to instance 2, and was then
forwarded through zero or more SIP proxies (not shown) before landing
at a UA, referred to here as the downstream SIP UA. The downstream
SIP UA may itself be another B2BUA that is a member of a cluster, or
even be an end user client. This specification requires the
downstream UA to implement the SIP Replaces header field [RFC3891].
When instance 2 fails, we wish to have the call taken over by one of
the other instances in the cluster, which can then re-establish media
with the downstream SIP UA using INVITE/Replaces.
There is a logical function associated with the cluster, called the
config source, which is aware of the configuration of the cluster.
Specifically, it knows the IP/port of each instance, and whether that
instance is healthy. This config source learns this information
through non-standardized means, unique to the cloud environment in
which the cluster resides. The config source communicates that
information to a config sync associated with the upstream calling
server. This communication is bidirectional, using HTTP requests.
The config sync distributes this information to the calling server
(and any other calling servers should they themselves be a cluster).
There is a shared database of some sorts, accessible by all instances
in the cluster. This is used to store the dialog state needed for
operation of this extension.
6. Solution Applicability
This specification is applicable in two scenarios:
1. The calling server (and other members in its cluster) and the
config sync service are controlled by one entity, and the cluster
and the downstream UA are controlled by a second. A common
example of this is where the calling server and config sync are
part of a telecom carrier, and the cluster and downstream UA are
part of an enterprise or SaaS provider that has purchased SIP
trunking services from the carrier.
2. The calling server, cluster, and downstream UA are all controlled
by a single administrative entity.
3. The instances which make up the cluster are assumed to be
provided by the same vendor. This allows for vendor-specific
solutions to replicate state and messaging as required by this
specification.
Rosenberg, et al. Expires August 25, 2021 [Page 6]
Internet-Draft Cloud SIP February 2021
This specification also requires that the calling server be a UA
(including B2BUAs), and that the instances in the cluster are B2BUAs
and the downstream UA is under the administrative control of the same
entity that operates the cluster.
7. Overview of Solution
The solution is pretty straightforward.
The calling server will maintain, through the HTTP-based protocol
described below, a list of instances in the cluster. These instances
are identified by both IP and port. The inclusion of a port allows
the instances to share a common IP but vary by port. Such a
configuration is useful inside of public cloud environments which can
be fronted by a network load balancer which allows each instance to
actually have the same IP, but utilize different ports.
The calling server continuously validates that each instance in the
cluster is alive, every 250ms. New calls are delivered only to
instances which are healthy based on the algorithm defined here. It
can ascertain health via reverse RTP traffic, rapid RTCP receiver
reports, or via SIP OPTIONS. If SIP OPTIONS are used, these are
performed at a rate of a new transaction every 250ms. This is very
fast, but it is critical for rapid detection of failures.
If the calling server is itself a member of a cluster, the work of
ascertaining the health of each instance can be distributed across
the calling servers, in order to avoid a full-mesh of OPTION probing,
and then the resulting state distributed through means outside of
this specification.
When a call is initially established - to instance 2 in this case -
instance 2 will place an entry into the database which contains three
pieces of information - (1) the dialogID of the SIP leg from the
caller to itself, (2) the dialog ID of the downstream SIP leg from
itself to the downstream SIP UA, (3) the IP address and port of the
downstream SIP UA.
If an instance transitions from healthy to unhealthy, the calling
server 'moves' the existing instance 2 calls uniformly across to the
remaining healthy instances in the cluster. To avoid a flood of
instant traffic, it moves these calls over a window of at least 200ms
and at most one second. To move the calls, the calling server sends
an INVITE w. Replaces header field for each such call. Because this
is a fresh SIP dialog, a new SDP offer/answer and SRTP is
established. This is what avoids the need for replication of RTP
state, SDP state and other lower-layer states across the instances in
the cluster. When the INVITE/Replaces arrives at one of the
Rosenberg, et al. Expires August 25, 2021 [Page 7]
Internet-Draft Cloud SIP February 2021
instances in the cluster (say, instance 3), the instance takes the
dialogID in the Replaces header field, and looks it up in the shared
DB. It will find that there is a matching dialog, and it will
retrieve the outbound dialogID and downstream SIP UA. Instance 3
sends an INVITE/Replaces to the downstream UA, using the dialogID it
retrieved from the database.
Establishment of a new SIP dialog between the calling server and
instance 3 can take place in parallel with the establishment of the
new dialog between instance 3 and the downstream UA. Thus the time
required to failover the live call is equal to the time to detect
instance failure, plus the time to establish a new SIP call.
8. Configuration
A cloud SIP "trunk" is configured in the config sync service through
means outside of the scope of this specification. Each such trunk is
defined by an HTTPS URI - the trunk config URI - which points to the
config source service representing that cluster. This is the only
configuration required to establish a cloud SIP trunk.
Once configured with this URI, the config sync MUST perform a GET
against this URI. The config source MUST return a JSON document
conformant to the schema defined in this specification. This
document MUST provide the config sync with a list of instances, each
with IP address and port. The JSON document MUST also contain a
cluster name, formatted as a hostname, and a webhook registration
URI.
Once retrieved, the config sync MUST perform a POST against the
webhook registration URI. The POST MUST contain a JSON document
conformant to the schema defined in this specification. That
document MUST contain an HTTPS webhook URI used by the config sync to
receive webhook callbacks that push an updated cluster configuration
from the config source.
The config sync MUST refresh its webhook registration at least once a
day to ensure that an up to date value for the webhook URI exists.
The config source MUST perform a POST against the webhook URI
whenever the cluster configuration changes, including when it
detects, on its own, that an instance is unhealthy, removing it from
the list.
Rosenberg, et al. Expires August 25, 2021 [Page 8]
Internet-Draft Cloud SIP February 2021
9. SIP Behavioral Requirements
9.1. Calling Server
9.1.1. Health Probing
The calling server MUST be capable of detecting the failure of any
instance of the cluster within 1.5 + RTT seconds. The specific means
for doing this detection can vary by implementation. It is also
expected that some implementations may have failure detection
computed from one instance of a calling server, and the resulting
state shared with other instances of the calling server through some
means outside the scope of this specification.
One suggested technique for detecting failure is to utilize a SIP
OPTIONS probe. The OPTIONS request can be sent every 250ms, directed
to each instance of the cluster. To facilitate high scale and
determination of RTT, a single OPTIONS request can be sent for each
transaction (since retransmits are largely useless due to the short
timeout defined for this use case). With such an interval, the
calling server can consider an instance unhealthy at time T if, at
time T, zero OPTIONS responses have been received for a time equal to
the RTT to the instance plus 6 * 250ms = 1.5s. The calling server
can maintain the RTT in any fashion it desires. If the OPTIONS
requests for a specific transaction are not retransmitted, the time
between transmission of the request and receipt of the response can
be used to measure RTT.
A MUST strength for 1.5s + RTT is specified to ensure that the
cluster can count on consistent and predictable behavior from the
upstream calling server. An instance is considered healthy if it is
not unhealthy.
OPEN ISSUE: SHould we put a Require header field in the OPTIONS?
Should we specify any other behaviors in the OPTIONS?
9.1.2. Utilization Measurement
The instances can place a SIP header, Instance-Utilization, into all
responses sent to the calling server. These values indicate the
utilization of that instance, as an integral value from 0 to 100.
They are used by the calling server to weight the traffic in
proportion to utilization.
The calling server MUST remove this header field before propagating
it in any upstream responses, as they only have significance on the
link between the calling server and cluster.
Rosenberg, et al. Expires August 25, 2021 [Page 9]
Internet-Draft Cloud SIP February 2021
If this header field is present in a response, the calling server
MUST remember the most recent value received from that instance
(ordered by the wall clock time at which the response is received).
The calling server MUST NOT utilize the source IP of the response to
identify the instance. Instead, it MUST correlate the response to a
request, and remember the instance to which the request was sent.
If no value has been received for 5 seconds, or no value was ever
received, the default value of 50 MUST be used as the utilization.
9.1.3. New Call Initiation
The calling server MUST NOT place a new SIP call to an instance in
the cluster which is unhealthy at the time the call is to be placed.
The calling server MUST select an instance for the call using a
random function across the instances which are healthy. The calling
server MUST weight the probability of selecting that instance in
proportion to (100 - the utilization of that instance) . It MUST then
direct the call to this instance, by sending the SIP INVITE to the IP
address and port of this instance.
As an example, if a cluster has three instances with utilizations at
50, 75 and 100, and all three instances are healthy, no INVITEs are
sent to the third instance, 66% are sent to instance one, and 33% are
sent to instance 2. Note that, in this case, since instance 3 is not
handling new calls, further utilization values can only be learned
via responses to OPTION pings, which the calling server MUST send for
instances with over 90% utilization.
9.1.4. Instance Failure
When the calling server detects the failure of an instance, it MUST
identify all calls which are still active, which were sent to that
instance. For each such call, it MUST select a new instance for that
call, by choosing one using a uniformly distributed random function
amongst the healthy instances. The calling server MUST generate a
new INVITE (not a re-INVITE), establishing a new SIP dialog. This
INVITE MUST contain a Replaces header field. The Replaces header
field MUST contain the dialogID of the call which is being failed
over. The INVITE requests MUST be sent uniformly across a 500ms
window of time.
9.1.5. Instance to Inactive
If the config sync receives an updated configuration file, and one of
the instances from the cluster has been marked as inactive, the
calling server MUST NOT send new calls to that instance. However, it
Rosenberg, et al. Expires August 25, 2021 [Page 10]
Internet-Draft Cloud SIP February 2021
MUST keep existing calls up, and MUST continue to send OPTIONS probes
to that instance.
9.1.6. Receiving a REFER
If the calling server receives a REFER request, and the Refer-To URI
has a domain portion equal to the IP address of a cluster instance or
the FQDN of the cluster, and the Refer-To URI contains an embedded
Replaces header field containing a dialogID of a call managed by the
calling server, then this REFER is meant to trigger a movement of the
call.
The calling server MUST authenticate that this request came from an
instance in the cluster. The request is authorized if the domain
portion of the Refer-To URI contains an IP address of a cluster
instance, or the FQDN of the instance. Furthermore the dialogID in
the embedded Refer-To header field matches a dialog that is in
progress to that cluster.
If the domain portion of the URI contains an IP address, the calling
server MUST perform the requested INVITE/Replaces to that cluster
instance. If the domain portion contains the FQDN of the cluster,
the calling server MUST send the INVITE/Replacs to one of the other
cluster instances, besides the one to which the dialog is currently
connected. It MUST select amongst the other instances as if the
currently connected instance were inactive, and then round robin
using the utilization measures for the remaining instances.
TODO: better explanation, more details
9.2. Cluster Instances
9.2.1. Sending Utilization Values
It is RECOMMENDED that if any one instance of a cluster send values
for Cluster-Utilization, all instances do. If none send it, calls
will be uniformly balanced across the cluster. Thus, the usage of
this header field is only meant for cases where uniform load
balancing will not produce uniform utilization.
If an instance is configured to send utilization, it MUST place an
Instance-Utilization header field in all responses it sends to all
transactions, and include its current measure of utilization. The
utilization measure MUST be an integer between 0 and 100 inclusive.
Since absolute ordering of responses cannot be guaranteed, the
measure SHOULD NOT change more frequently than once a second.
Rosenberg, et al. Expires August 25, 2021 [Page 11]
Internet-Draft Cloud SIP February 2021
9.2.2. Receiving INVITE w. Replaces
If an instance in the cluster receives an INVITE for a call, and that
call has a Replaces header field containing a dialogID for a call
that the instance knows is in progress within the cluster, it will
know that this is a failover call. It may happen that the failover
call is one being handled by the instance receiving the INVITE with
Replaces. This is a race condition, but in this case the instance
MUST still follow the procedures defined here.
If this is a failover call, the instance MUST authenticate that the
INVITE came from the upstream calling server.
There may be cases where the cluster instance receives an INVITE with
Replaces header field, but the dialogID does not match a dialog known
to the cluster. In such a case, the INVITE MUST be treated as a
normal INVITE with a Replaces header field as defined by [RFC3891].
In many cases this may be propagated downstream, or challenged for
credentials, neither of which are done if the dialogID is a match for
a dialog known to the cluster.
Any downstream SIP dialogs associated with the call MUST be sent an
INVITE with Replaces, moving the call to this instance. This will
necessarily require the cluster to store the dialogIDs for all
dialogs in and out of the cluster, along with any application state
needed to reconstruct the dialogs at a new instance.
9.2.3. Graceful Shutdown with Migration
In cases where an instance in the cluster wishes to shut down quickly
(perhaps to facilitate a rolling upgrade across the cluster), it can
do so by ceasing to respond to OPTIONS requests targeted to itself.
The upstream caller will see this as a failure, and move all of the
calls off of the instance, onto the remaining instances in the
cluster. When the instance reboots, it will begin responding to the
OPTIONS probes, enabling it to begin to receive new calls.
9.2.4. Graceful Shutdown without Migration
Another common use case for graceful restart is to cease accepting
new calls, but to allow the calls in progress to complete. Once all
of the calls have completed, the instance can shut down and restart
if desired.
To accomplish this, the cluster config service will mark the instance
as inactive in the config file, and pass the updated file to the
config sync via webhook. This will cause the calling server to stop
Rosenberg, et al. Expires August 25, 2021 [Page 12]
Internet-Draft Cloud SIP February 2021
sending new calls to the instance. However, calls in progress will
not be dropped.
9.3. Moving a Dialog
Another common case is that an instance is overloaded and wishes to
shed a few calls. To facilitate this, a cluster instance MAY send a
REFER to the calling server, requesting it to send an INVITE with a
Replaces header field. The Refer-To header field embedded in the
Refer-To URI MUST contain the dialogID of the call from the calling
server to that instance, which is to be moved. To move the call to a
specific other instance in the cluster, the domain portion of the URI
is set to be equal to the IP address of that instance. Note that the
calling server will validate that this IP address is another member
of the cluster before authorizing the REFER. Alternatively, the
REFER can request the calling server to send the call to any one of
the other instances in the cluster, not including itself. To do
that, it sets the domain portion of the SIP URI equal to the cluster
FQDN.
TODO: Probably need examples and some more details on in or out of
dialog REFER
10. Cloud SIP Trunk Configuration File
Something like:
{
"cloud-sip-trunk-name" : "trunk32.acme.com",
"uri" : "https://configs.sip.acme.com/trunk32",
"version": 23,
"webhook-registration" : "https://webhooks.sip.acme.com/trunk32",
"instances" : [
{
"IP" : "1.2.3.4",
"port" : "5061",
"status" : "active"
},
{
"IP" : "1.2.3.7",
"port" : "5061",
"status" : "inactive"
}
]
}
Rosenberg, et al. Expires August 25, 2021 [Page 13]
Internet-Draft Cloud SIP February 2021
11. Webhook Registration Object
Something like:
{
"webhook" : "https://webhook-receipt.sip.acme.com"
}
12. Instance-Utilization Header Field
Something like:
{
Instance-Utilization: 34
}
IANA registration and formal syntax TBD.
13. Why not DNS
The usage of DNS - and specifically [RFC3263] - might appear to be an
alternative to the mechanism in this specification for communicating
the IP addresses for the instances of the cluster. However, DNS does
not meet the requirements outlined above.
Firstly, DNS is not fast enough to be responsive to the need to add
or remove an instance from the cluster. Changes in DNS can take time
to propagate. At the time [RFC3263] was conceived, the notion of
elastic (and automated) expansion and contraction of clusters did not
exist. Cluster instance IPs were extremely static and therefore DNS
was sufficient. This is no longer the case.
Secondly, DNS cannot convey state - in particular, information about
whether the cluster instances are active or inactive. This is needed
to facilitate graceful shutdown of instances. [RFC3263] did not have
to concern itself with this problem, because at the time it was
believed SIP servers would not contain call state, and therefore, we
would not need to worry about this problem.
In addition, because we need to failover extremely quickly - in under
two seconds - the calling server needs to perform rapid health
probing against all instances in the cluster. This requires the
calling server to know all of the IP addresses of the all the
instances in the cluster. Typically, DNS queries for an FQDN return
one or perhaps a handful of A records, and not every single A record.
We expect this specification to be used with clusters that have
Rosenberg, et al. Expires August 25, 2021 [Page 14]
Internet-Draft Cloud SIP February 2021
instances counts in the hundreds, which is wholly inappropriate to
convey via DNS.
14. TODO
Reconcile this with draft-kinamdar-dispatch-sip-audo-peer.
15. Informative References
[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>.
[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>.
[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>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
DOI 10.17487/RFC3891, September 2004,
<https://www.rfc-editor.org/info/rfc3891>.
Authors' Addresses
Jonathan Rosenberg
Five9
Email: jdrosen@jdrosen.net
Rosenberg, et al. Expires August 25, 2021 [Page 15]
Internet-Draft Cloud SIP February 2021
Cullen Jennings
Cisco
Email: fluffy@cisco.com
Tolga Asveren
Ribbon Communications
Email: tasveren@rbbn.com
Rosenberg, et al. Expires August 25, 2021 [Page 16]
