ASAP K. Inamdar
Internet-Draft S. Narayanan
Expires: July 31, 2021 C. Jennings
Cisco Systems
January 27, 2021
Automatic Peering for SIP Trunks
draft-kinamdar-dispatch-sip-auto-peer-05
Abstract
This draft specifies a configuration workflow to enable enterprise
Session Initiation Protocol (SIP) networks to solicit the capability
set of a SIP service provider network. The capability set can
subsequently be used to configure features and services on the
enterprise edge element, such as a Session Border Controller (SBC),
to ensure smooth peering between enterprise and service provider
networks.
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 July 31, 2021.
Copyright Notice
Copyright (c) 2021 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
(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
Inamdar, et al. Expires July 31, 2021 [Page 1]
Internet-Draft SIP Auto Peer January 2021
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Reference Architecture . . . . . . . . . . . . . . . . . . . 3
4. Configuration Workflow . . . . . . . . . . . . . . . . . . . 5
5. Overview of Operations . . . . . . . . . . . . . . . . . . . 6
6. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8
6.3. Authenticated Client Identity . . . . . . . . . . . . . . 8
6.4. Encoding the Request . . . . . . . . . . . . . . . . . . 8
6.5. Generating the response . . . . . . . . . . . . . . . . . 9
6.6. Identifying the Request Target . . . . . . . . . . . . . 9
7. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Encoding the Service Provider Capability Set . . . . . . . . 10
9. Data Model for Capability Set . . . . . . . . . . . . . . . . 10
9.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10
9.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 12
9.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 17
9.4. Extending the Capability Set . . . . . . . . . . . . . . 24
10. Example Capability Set Document Encoding . . . . . . . . . . 25
10.1. XML Capability Set Document . . . . . . . . . . . . . . 26
11. Example Exchange . . . . . . . . . . . . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 28
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
15.1. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The deployment of a Session Initiation Protocol [RFC 3261 [1]] (SIP)-
based infrastructure in enterprise and service provider communication
networks is increasing at a rapid pace. Consequently, direct IP
peering between enterprise and service provider networks is quickly
replacing traditional methods of interconnection between enterprise
and service provider networks. Currently published standards provide
a strong foundation over which direct IP peering can be realized.
However, given the sheer number of these standards, it is often not
clear which behavioral subsets, extensions to baseline protocols and
operating principles ought to be implemented by service provider and
enterprise networks to ensure successful peering.
Inamdar, et al. Expires July 31, 2021 [Page 2]
Internet-Draft SIP Auto Peer January 2021
The SIP Connect technical recommendations [2] aim to solve this
problem by providing a master reference that promotes seamless
peering between enterprise and service provider SIP networks.
However, despite the extensive set of implementation rules and
operating guidelines, interoperability issues between service
provider and enterprise networks persist. This is in large part
because service providers and equipment manufacturers aren't required
to enforce the guidelines of the technical specifications and have a
fair degree of freedom to deviate from them. Consequently,
enterprise administrators usually undertake a fairly rigorous regimen
of testing, analysis and troubleshooting to arrive at a configuration
block that ensures seamless service provider peering. However, this
workflow complements the SIP Connect technical recommendations, in
that both endeavours aim to promote/achieve interop between the
enterprise and service provider.
Another set of interoperability problems arise when enterprise
administrators are required to translate a set of technical
recommendations from service providers to configuration blocks across
one or more devices in the enterprise, which is usually an error
prone exercise. Additionally, such technical recommendations might
not be nuanced enough to intuitively allow the generation of specific
configuration blocks.
This draft introduces a mechanism using which an enterprise network
can solicit a detailed capability set from a SIP service provider;
the detailed capability set can subsequently be used by automaton or
an administrator to generate configuration blocks across one or more
devices within the enterprise to ensure successful service provider
peering.
2. Conventions and Terminology
The The keywords "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 [3]
3. Reference Architecture
Figure 1 illustrates a reference architecture that may be deployed to
support the mechanism described in this document. The enterprise
network consists of a SIP-PBX, media endpoints and a Session Border
Controller [RFC 7092 [4]]. It may also include additional components
such as application servers for voicemail, recording, fax etc. At a
high level, the service provider consists of a SIP signaling entity
(SP-SSE), a media entity and a HTTPS [RFC 7231 [5]] server.
Inamdar, et al. Expires July 31, 2021 [Page 3]
Internet-Draft SIP Auto Peer January 2021
+-----------------------------------------------------+
| +---------------+ +-----------------------+ |
| | | | | |
| | +----------+ | | +-------+ | |
| | | Cap | | HTTPS | | | | |
| | | Server |<-|---------|-->| | | |
| | | | | | | | +-----+ | |
| | +----------+ | | | | | SIP | | |
| | | | | |<->| PBX | | |
| | | | | | +-----+ | |
| | +----------+ | | | SBC | | |
| | | | | SIP | | | | |
| | | SP - SSE |<-|---------|-->| | +-----+ | |
| | | | | | | |<->| M.E.| | |
| | +----------+ | | | | | | | |
| | | | | | +-----+ | |
| | +----------+ | (S)RTP | | | | |
| | | Media |<-|---------|-->+-------+ | |
| | +----------+ | | | |
| +---------------+ +-----------------------+ |
| |
+-----------------------------------------------------+
Figure 1: Reference Architecture
This draft makes use of the following terminology:
o Enterprise Network: A communications network infrastructure
deployed by an enterprise which interconnects with the service
provider network over SIP. The enterprise network could include
devices such as application servers, endpoints, call agents and
edge devices, among others.
o Edge Device: A device that is the last hop in the enterprise
network and that is the transit point for traffic entering and
leaving the enterprise. An edge device is typically a back-to-
back user agent (B2BUA) [RFC 7092 [6]] such as a Session Border
Controller (SBC).
o Service Provider Network: A communications network infrastructure
deployed by service providers. In the context of this draft, the
service provider network is accessible over SIP for the
establishment, modification and termination of calls and
accessible over HTTPS for the transfer of the capability set
document. The service provider network is also referred to as a
SIP Service Provider (SSP) or Internet Telephony Service Provider
(ITSP) network.
Inamdar, et al. Expires July 31, 2021 [Page 4]
Internet-Draft SIP Auto Peer January 2021
o Call Control: Call Control within a telephony networks refers to
software that is responsible for delivering its core
functionality. Call control not only provides the basic
functionality of setting up, sustaining and terminating calls, but
also provides the necessary control and logic required for
additional services within the telephony network.
o Capability Server: A server hosted in the service provider
network, such that this server is the target for capability set
document requests from the enterprise network.
o Capability Set: This specification uses the term capability set
(or capability set document) to refer collectivity to a set of
characteristics within the service provider network, which when
communicated to the enterprise network, provides the enterprise
network the information required to interconnect with the service
provider network. The various parameters that constitute the
capability set relate to characteristics that are specific to
signalling, media, transport and security. Certain aspects of
interconnecting with service providers are out of scope of the
capability set. For example, the access technology used to
interconnect with service provider networks.
4. Configuration Workflow
A workflow that facilitates an enterprise network to solicit the
capability set of a SIP service provider ought to take into account
the following considerations:
o The configuration workflow must be based on a protocol or a set of
protocols commonly used between enterprise and service provider
telephony networks.
o The configuration workflow must be flexible enough to allow the
service provider network to dynamically offload different
capability sets to different enterprise networks based on the
identity of the enterprise network.
o Capability set documents obtained as a result of the configuration
workflow must be conducive to easy parsing by automaton.
Subsequently, automaton may be used for generation of appropriate
configuration blocks.
Taking the above considerations into account, this document proposes
a Hypertext Transfer Protocol (HTTP)-based workflow using which the
enterprise network can solicit and ultimately obtain the service
provider capability set. The enterprise network creates a well
Inamdar, et al. Expires July 31, 2021 [Page 5]
Internet-Draft SIP Auto Peer January 2021
formed HTTPS GET request to solicit the service provider capability
set. Subsequently, the HTTPS response from the SIP service provider
includes the capability set. The capability set is encoded in either
XML or JSON, thus ensuring that the response can be easily parsed by
automaton.
There are alternative mechanisms using which the SIP service provider
can offload its capability set. For example, the Session Initiation
Protocol (SIP) can be extended to define a new event package [RFC
6665 [7]], such that the enterprise network can establish a SIP
subscription with the service provider for its capability set; the
SIP service provider can subsequently use the SIP NOTIFY request to
communicate its capability set or any state deltas to its baseline
capability set.
This mechanism is likely to result in a barrier to adoption for SIP
service providers and enterprise networks as equipment manufacturers
would have to first add support for such a SIP extension. A HTTPS-
based approach would be relatively easier to adopt as most edge
devices deployed in enterprise networks today already support HTTPS;
from the perspective of service provider networks, all that is
required is for them to deploy HTTPS servers that function as
capability servers. Additionally, most SIP service providers require
enterprise networks to register with them (using a SIP REGISTER
message) before any other SIP methods that initiate subscriptions
(SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a
SIP-based framework to obtain a capability set would require
operational changes on the part of service provider networks.
Yet another example of an alternative mechanism would be for service
providers and enterprise equipment manufacturers to agree on YANG
models [RFC 6020 [8]] that enable configuration to be pushed over
NETCONF [RFC 6241 [9]] to enterprise networks from a centralised
source hosted in service provider networks. The presence of
proprietary software logic for call and media handling in enterprise
devices would preclude the generation of a "one-size-fits-all" YANG
model. Additionally, service provider networks pushing configuration
to enterprises devices might lead to the loss of implementation
autonomy on the part of the enterprise network.
5. Overview of Operations
To solicit the capability set of a SIP service provider, the edge
element in an enterprise network generates a well-formed HTTPS GET
request. There are two reasons why it makes sense for the enterprise
edge element to generate the HTTPs request:
Inamdar, et al. Expires July 31, 2021 [Page 6]
Internet-Draft SIP Auto Peer January 2021
1. Edge elements are devices that normalise any mismatches between
the enterprise and service provider networks in the media and
signaling planes. As a result, when the capability set is
received from the SIP service provider network, the edge element
can generate appropriate configuration blocks (possibly across
multiple devices) to enable interconnection.
2. Given that edge elements are configured to "talk" to networks
external to the enterprise, the complexity in terms of NAT
traversal and firewall configuration would be minimal.
The HTTPS GET request is targeted at a capability server that is
managed by the SIP service provider such that this server processes,
and on successfully processing the request, includes the capability
set document in the response. The capability set document is
constructed according the guidelines of the YANG model described in
this draft. The capability set document included in a successful
response is formatted in either XML or JSON. The formatting depends
on the value of the "Accept" header field of the HTTPS GET request.
More details about the formatting of the HTTPS request and response
are provided in Section 6.
There could be situations wherein an enterprise telephony network
interconnects with its SIP service provider such that traffic between
the two networks traverses an intermediary SIP service provider
network. This could be a result of interconnect agreements between
the terminating and transit SIP service provider networks. In such
situations, the capability set provided to the enterprise network by
its SIP service provider must account for the characteristics of the
transit SIP service provider network from a signalling and media
perspective. For example, if the terminating SIP service provider
network supports the G.729 codec and the transit SIP service provider
network does not, G.729 must not be advertised in the capability set.
As another example, if the transit SIP service provider network
doesn't support a SIP extension, for instance, the SIP extension for
Reliable Provisional Responses as defined in RFC 3262, the
terminating SIP service provider network must not advertise support
for this extension in the capability set provided to the enterprise
network. How a terminating SIP service provider obtains the
characteristics of the intermediary SIP service provider network is
out of the scope of this document; however, one method could be for
the terminating SIP service provider to obtain the characteristics of
the intermediary SIP service provider by leveraging the YANG model
introduced in this document.
Figure 1 provides a reference architecture in which this workflow may
be implemented. The architecture depicted in Figure 1 consists of an
enterprise telephony network and a SIP service provider network, such
Inamdar, et al. Expires July 31, 2021 [Page 7]
Internet-Draft SIP Auto Peer January 2021
that the enterprise network attempts to provision SIP trunking
services for the first time. For the sake of simplicity, the
enterprise and service provider networks are decomposed into their
core constituent elements.
6. HTTP Transport
This section describes the use of HTTPS as a transport protocol for
the peering workflow. This workflow is based on HTTP version 1.1,
and as such is compatible with any future version of HTTP that is
backward compatible with HTTP 1.1.
6.1. HTTP Methods
The workflow defined in this document leverages the HTTPS GET method
and its corresponding response(s) to request for and subsequently
obtain the service provider capability set document. The HTTPS POST
method and its corresponding response(s) is also used for client
authentication.
6.2. Integrity and Confidentiality
Peering requests and responses are defined over HTTPS. However, due
to the sensitive nature of information transmitted between client and
server, it is required to secure HTTP using Transport Layer Security
[RFC 5246 [10]]. The enterprise edge element and capability server
MUST be compliant with RFC 7235 [11]. The enterprise edge element
and capability server MUST support the use of the https uri scheme as
defined in RFC 7230 [12].
6.3. Authenticated Client Identity
It is only required for the SIP service provider to authenticate the
client (enterprise edge element). How the SIP service provider
authenticates the client is out of the scope of this document,
however, methods such as HTTP Digest Authentication may be used.
6.4. Encoding the Request
The edge element in the enterprise network generates a HTTPS GET
request such that the request-target is obtained using the procedure
outlined in section 6.6 The MIME types for the capability set
document defined in this draft are "application/peering-info+json"
and "application/peering-info+xml". Accordingly, the Accept header
field value MUST be restricted only to these MIME types. It is
possible that the edge element supports responses formatted in both
JSON and XML. In such situations, the edge element might generate a
Inamdar, et al. Expires July 31, 2021 [Page 8]
Internet-Draft SIP Auto Peer January 2021
HTTPS GET request such that the Accept header field includes both
MIME types along with the corresponding "qvalue" for each MIME type.
The generated HTTPS GET request must not use the "Expect" and "Range"
header fields. The requests must also not use any conditional
request.
6.5. Generating the response
Capability servers include the capability set documents in the body
of a successful response. Capability set documents MUST be formatted
in XML or JSON. For requests that are incorrectly formatted, the
capability server must generate a "400 Bad Request" response. If the
client (enterprise edge element) includes any other MIME types in
Accept header field other than "application/peering-info+json" or
"application/peering-info+xml", the capability set must reject the
request with a "406 Not Acceptable" response.
The capability server can respond to client requests with redirect
responses, specifically, the server can respond with the following
redirect responses:
1. 301 Moved Temporarily
2. 302 Found
3. 307 Temporary Redirect
The server SHOULD include the Location header field in such
responses.
6.6. Identifying the Request Target
HTTPS GET requests from enterprise edge elements MUST carry a valid
request-target. The enterprise edge element might obtain the URL of
the resource hosted on the capability server in one of two ways:
1. Manual Configuration
2. Discovery [TBD]
7. State Deltas
Given that the service provider capability set is largely expected to
remain static, the work needed to implement an asynchronous push
mechanism to encode minor changes in the capability set document
(state deltas) is not commensurate with the benefits. Rather,
enterprise edge elements can poll capability servers at pre-defined
Inamdar, et al. Expires July 31, 2021 [Page 9]
Internet-Draft SIP Auto Peer January 2021
intervals to obtain the full capability set document. It is
recommended that capability servers are polled every 24 hours.
8. Encoding the Service Provider Capability Set
In the context of this draft, the capability set of a service
provider refers collectively to a set of characteristics which when
communicated to an enterprise network, provides it with sufficient
information to directly peer with the service provider network. The
capability set document is not designed to encode extremely granular
details of all features, services, and protocol extensions that are
supported by the service provider network. For example, it is
sufficient to encode that the service provider uses T.38 relay for
faxing, it is not required to know the value of the
"T38FaxFillBitRemoval" parameter.
The parameters within the capability set document represent a wide
array of characteristics, such that these characteristics
collectively disseminate sufficient information to enable direct IP
peering between enterprise and service provider networks. The
various parameters represented in the capability set are chosen based
on existing practises and common problem sets typically seen between
enterprise and service provider SIP networks.
9. Data Model for Capability Set
This section defines a YANG module for encoding the service provider
capability set. Section 9.1 provides the tree diagram, which is
followed by a description of the various nodes within the module
defined in this draft.
9.1. Tree Diagram
This section provides a tree diagram [RFC 8340 [13]] for the "ietf-
capability-set" module. The interpretation of the symbols appearing
in the tree diagram is as follows:
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
Inamdar, et al. Expires July 31, 2021 [Page 10]
Internet-Draft SIP Auto Peer January 2021
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
The data model for the peering capability document has the following
structure:
+--rw peering-response
+--rw variant string
+--rw transport-info
| +--rw transport? enumeration
| +--rw registrar* host-port
| +--rw registrarRealm? string
| +--rw callControl* host-port
| +--rw dns* inet:ip-address
| +--rw outboundProxy? host-port
+--rw call-specs
| +--rw earlyMedia? boolean
| +--rw signalingForking? boolean
| +--rw supportedMethods? string
| +--rw numRange
| +--rw numRangeType* string
| +--rw count* int32
| +--rw value* string
+--rw media
| +--rw mediaTypeAudio
| | +--rw mediaFormat* string
| +--rw fax
| | +--rw protocol* enumeration
| +--rw rtp
| | +--rw RTPTrigger? boolean
| | +--rw symmetricRTP? boolean
| +--rw rtcp
| +--rw symmetricRTCP? boolean
| +--rw RTCPfeedback? boolean
+--rw dtmf
| +--rw payloadNumber? int8
| +--rw iteration? boolean
+--rw security
| +--rw signaling
| +--rw type* string
| +--rw version* string
| +--rw mediaSecurity
| +--rw keyManagement? string
| +--rw certLocation string
+--rw extensions? string
Inamdar, et al. Expires July 31, 2021 [Page 11]
Internet-Draft SIP Auto Peer January 2021
9.2. YANG Model
This section defines the YANG module for the peering capability set
document. It imports modules (ietf-yang-types and ietf-inet-types)
from [RFC 6991 [14]].
module ietf-sip-auto-peering {
namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering";
prefix "peering";
description
"Data model for transmitting peering parameters from SP to Enterprise";
revision 2019-05-06 {
description "Initial revision of peering-response doc.";
}
import ietf-inet-types {
prefix "inet";
}
typedef ipv4-address-port {
type string {
pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$';
}
description "The ipv4-address-port type represents an IPv4 address in
dotted-quad notation followed by a port number.";
}
typedef ipv6-address-port {
type string {
pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+ '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+ '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+ ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$';
pattern
'(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$';
}
description
"The ipv6-address type represents an IPv6 address in full,
mixed, shortened, and shortened-mixed notation followed by a port number.";
}
Inamdar, et al. Expires July 31, 2021 [Page 12]
Internet-Draft SIP Auto Peer January 2021
typedef ip-address-port {
type union {
type ipv4-address-port;
type ipv6-address-port;
}
description
"The ip-address-port type represents an IP address:port number
and is IP version neutral.";
}
typedef domain-name-port {
type string {
pattern
'((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.'
+ ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$';
length "1..258";
}
description
"The domain-name-port type represents a DNS domain name followed by a port number.
The name SHOULD be fully qualified whenever possible.";
}
typedef host-port {
type union {
type ip-address-port;
type domain-name-port;
}
description
"The host type represents either an IP address or a DNS
domain name followed by a port number.";
}
container peering-info {
leaf variant {
type string;
mandatory true;
description "Variant of peering-response document";
}
container transport-info {
leaf transport {
type enumeration {
enum "TCP";
enum "TLS";
enum "UDP";
enum "TCP;TLS";
Inamdar, et al. Expires July 31, 2021 [Page 13]
Internet-Draft SIP Auto Peer January 2021
enum "TCP;TLS;UDP";
enum "TCP;UDP";
}
description "Transport Protocol(s) used in SIP communication";
}
leaf-list registrar {
type host-port;
max-elements 3;
description "List of service provider registrar servers";
}
leaf registrarRealm {
type string;
description "Realm for REGISTER requests carrying credentials";
}
leaf-list callControl {
type host-port;
max-elements 3;
description "List of service provider call control servers";
}
leaf-list dns {
type inet:ip-address;
max-elements 2;
description "IP address of the DNS Server(s) hosted by the service provider";
}
leaf outboundProxy {
type host-port;
description "SIP Outbound Proxy";
}
}
container call-specs {
leaf earlyMedia {
type boolean;
description "Flag indicating whether the service provider is expected
to deliver early media.";
}
leaf signalingForking {
type boolean;
description "Flag indicating whether the service provider is capable
of forking incoming calls ";
}
Inamdar, et al. Expires July 31, 2021 [Page 14]
Internet-Draft SIP Auto Peer January 2021
leaf supportedMethods {
type string;
description "Leaf/Leaf List indicating the different SIP methods
support by the service provider.";
}
container numRange {
leaf numRangeType {
type string;
description "String indicating whether the DID number range is passed
by value or by reference"
}
leaf count {
when "../numRangeType = 'range' or ../numRangeType = 'block'";
type int32;
description "Number of DID numbers present in the number range."
}
leaf-list value {
type string;
description "Value of the DID number range or URL being passed as
reference."
}
}
}
container media {
container mediaTypeAudio {
leaf-list mediaFormat {
type string;
description "Leaf List indicating the audio media formats supported.";
}
}
container fax {
leaf-list protocol {
type enumeration {
enum "pass-through";
enum "t38";
}
max-elements 2;
description "Leaf List indicating the different fax protocols
supported by the service provider.";
}
}
Inamdar, et al. Expires July 31, 2021 [Page 15]
Internet-Draft SIP Auto Peer January 2021
container rtp {
leaf RTPTrigger {
type boolean;
description "Flag indicating whether the service provider expects to
receive the first media packet.";
}
leaf symmetricRTP {
type boolean;
description "Flag indicating whether the service provider expects
symmetric RTP defined in [@RFC4961]";
}
}
container rtcp {
leaf symmetricRTCP {
type boolean;
description " Flag indicating whether the service provider expects
symmetric RTP defined in [@RFC4961].";
}
leaf RTCPfeedback {
type boolean;
description "Flag Indicating support for RTP profile extension for
RTCP-based feedback, as defined in [@RFC4585]";
}
}
}
container dtmf {
leaf payloadNumber {
type int8 {
range "96..127";
}
description "Leaf that indicates the payload number(s) supported by
the service provider for DTMF relay via Named-Telephony-Events";
}
leaf iteration {
type boolean;
description "Flag identifying whether the service provider supports
NTE DTMF relay using the procedures of [@RFC2833] or [@RFC4733] .";
}
}
container security {
container signaling {
leaf type {
Inamdar, et al. Expires July 31, 2021 [Page 16]
Internet-Draft SIP Auto Peer January 2021
type string {
pattern "TLS";
}
description "Type of signaling security supported.";
}
leaf version {
type string {
pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)";
}
description "Indicates TLS version for SIP signaling";
}
}
container mediaSecurity {
leaf keyManagement {
type string {
pattern "(SDES(;DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]\.[0-9])?)?)|(DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]\.[0-9])?)|(NULL)";
}
description "Leaf that identifies the key management methods
supported by the service provider for SRTP.";
}
}
leaf certLocation {
type string;
description "Location of the service provider certificate chain for SIP over TLS.";
}
}
leaf extensions {
type string;
description "Lists the various SIP extensions supported by SP";
}
}
}
9.3. Node Definitions
This sub-sections provides the definition and encoding rules of the
various nodes of the YANG module defined in section 9.2
*capability-set*: This node serves as a container for all the other
nodes in the YANG module; the capability-set node is akin to the root
element of an XML schema.
*variant*: This node identifies the version number of the capability
set document. This draft defines the parameters for variant 1.0;
Inamdar, et al. Expires July 31, 2021 [Page 17]
Internet-Draft SIP Auto Peer January 2021
future specifications might define a richer parameter set, in which
case the variant must be changed to 2.0, 3.0 and so on. Future
extensions to the capability set document MUST also ensure that the
corresponding YANG module is defined.
*transport-info*: The transport-info node is a container that
encapsulates transport characteristics of SIP sessions between
enterprise and service provider networks.
*transport*: A leaf node that enumerates the different Transport
Layer protocols supported by the SIP service provider. Valid
transport layer protocols include: UDP, TCP, TLS or a combination of
them (with the exception of TLS and UDP).
*registrar*: A leaf-list that specifies the transport address of one
or more registrar servers in the service provider network. The
transport address of the registrar can be provided using a
combination of a valid IP address and port number, or a subdomain of
the SIP service provider network, or the fully qualified domain name
(FQDN) of the SIP service provider network. If the transport address
of a registrar is specified using either a subdomain or a fully
qualified domain name, the DNS element must be populated with one or
more valid DNS server IP addresses.
*callControl*: A leaf-list that specifies the transport address of
the call server(s) in the service provider network. The enterprise
network must use an applicable transport protocol in conjunction with
the call control server(s) transport address when transmitting call
setup requests. The transport address of a call server(s) within the
service provider network can be specified using a combination of a
valid IP address and port number, or a subdomain of the SIP service
provider network, or a fully qualified domain name of the SIP service
provider network. If the transport address of a call control
server(s) is specified using either a subdomain or a fully qualified
domain name, the DNS element must be populated with one or more valid
DNS server IP addresses. The transport address specified in this
element can also serve as the target for non-call requests such as
SIP OPTIONS.
*dns*: A leaf list that encodes the IP address of one or more DNS
servers hosted by the SIP service provider. If the enterprise
network is unaware of the IP address, port number, and transport
protocol of servers within the service provider network (for example,
the registrar and call control server), it must use DNS NAPTR and
SRV. Alternatively, if the enterprise network has the fully
qualified domain name of the SIP service provider network, it must
use DNS to resolve the said FQDN to an IP address. The dns element
encodes the IP address of one or more DNS servers hosted in the
Inamdar, et al. Expires July 31, 2021 [Page 18]
Internet-Draft SIP Auto Peer January 2021
service provider network. If however, either the registrar or
callControl elements or both are populated with a valid IP address
and port pair, the dns element must be set to the quadruple octet of
0.0.0.0
*outboundProxy*: A leaf list that specifies the transport address of
one or more outbound proxies. The transport address can be specified
by using a combination of an IP address and a port number, a
subdomain of the SIP service provider network, or a fully qualified
domain name and port number of the SIP service provider network. If
the outbound-proxy sub-element is populated with a valid transport
address, it represents the default destination for all outbound SIP
requests and therefore, the registrar and callControl elements must
be populated with the quadruple octet of 0.0.0.0
*call-specs*: A container that encapsulates information about call
specifications, restrictions and additional handling criteria for SIP
calls between the enterprise and service provider network.
*earlyMedia*: A leaf that specifies whether the service provider
network is expected to deliver in-band announcements/tones before
call connect. The P-Early-Media header field can be used to indicate
pre-connect delivery of tones and announcements on a per-call basis.
However, given that signalling and media could traverse a large
number of intermediaries with varying capabilities (in terms of
handling of the P-Early-Media header field) within the enterprise,
such devices can be appropriately configured for media cut through if
it is known before-hand that early media is expected for some or all
of the outbound calls. This element is a Boolean type, where a value
of 1/true signifies that the service provider is capable of early
media. A value of 0/false signifies that the service provider is not
expected to generate early media.
*signalingForking*: A leaf that specifies whether outbound call
requests from the enterprise might be forked on the service provider
network that MAY lead to multiple early dialogs. This information
would be useful to the enterprise network in appropriately handling
multiple early dialogs reliably and in enforcing local policy. This
element is a Boolen type, where a value of 1/true signifies that the
service provider network can potentially fork outbound call requests
from the enterprise. A value of 0/false indicates that the service
provider will not fork outbound call requests.
*supportedMethods*: A leaf node that specifies the various SIP
methods supported by the SIP service provider. The list of supported
methods help to appropriately configuration various devices within
the enterprise network. For example, if the service provider
Inamdar, et al. Expires July 31, 2021 [Page 19]
Internet-Draft SIP Auto Peer January 2021
enumerates support for the OPTIONS method, the enterprise network
could periodically send OPTIONS requests as a keep-alive mechanism.
*numRange*: Is a container that specifies the Direct Inward Dial
(DID) number range allocated to the enterprise network by the SIP
service provider. The DID number range allocated by the service
provider to the enterprise network might be a contiguous or a non-
contiguous block. The number range allocated to an enterprise can be
communicated as a value or as a reference. For large enterprise
networks, the size of the DID range might run into several hundred
numbers. For situations in which the enterprise is allocated a large
DID number range or a non-contiguous number range it is RECOMMENDED
that the SIP service provider communicate this information by
reference, that is, through a URL. The enterprise network is
required to de-reference this URL in order to obtain the DID number
range allocated by the SIP service provider. The numRange container
can be used more than once. Refer to the example provided in
Section 10.1.
*numRangeType*: A leaf node that indicates whether the DID range is
communicated by value or by reference. It can have a value of
'range', 'block' or 'reference'.
*count*: A leaf node that indicates the size of the DID number range.
The number range may be contiguous or non-contiguous. This leaf node
MUST NOT be included when using the 'reference' numRangeType value.
*value*: A leaf-list that encapsulates the DID number range allocated
to the enterprise. If the numRangeType value is set to 'range' or
'block', this is the list of numbers allocated to the enterprise. If
the numRangeType value is set to 'reference', this is the URL of the
resource containing the DID number range. To ensure ease of parsing,
it is RECOMMENDED that the resource contain a number range formatted
as if it were being passed as a block or range.
*media*: A container that is used to collectively encapsulate the
characteristics of UDP-based audio streams. A future extension to
this draft may extend the media container to describe other media
types. The media container is also used to encapsulate basic
information about Real-Time Transport Protocol (RTP) and Real-Time
Transport Control Protocol (RTCP) from the perspective of the service
provider network.
*mediaTypeAudio*: A container for the mediaFormat leaf-list. This
container collectively encapsulates the various audio media formats
supported by the SIP service provider.
Inamdar, et al. Expires July 31, 2021 [Page 20]
Internet-Draft SIP Auto Peer January 2021
*mediaFormat*: A leaf-list encoding the various audio media formats
supported by the SIP service provider. The relative ordering of
different media format leaf nodes from left to right indicates
preference from the perspective of the service provider. Each
mediaFormat node begins with the encoding name of the media format,
which is the same encoding name as used in the "RTP/AVP" and "RTP/
SAVP" profiles. The encoding name is followed by required and
optional parameters for the given media format as specified when the
media format is registered [RFC 4855 [15]]. Given that the
parameters of media formats can vary from one communication session
to another, for example, across two separate communication sessions,
the packetization time (ptime) used for the PCMU media format might
vary from 10 to 30 ms, the parameters included in the format element
must be the ones that are expected to be invariant from the
perspective of the service provider. Providing information about
supported media formats and their respective parameters, allows
enterprise networks to configure the media plane characteristics of
various devices such as endpoints and middleboxes. The encoding
name, one or more required parameters, one or more optional
parameters are all separated by a semicolon. The formatting of a
given media format parameter, must follow the formatting rules as
specified for that media format.
*fax*: A container that encapsulates the fax protocol(s) supported by
the SIP service provider. The fax container encloses a leaf-list
(named protocol) that enumerates whether the service provider
supports t38 relay, protocol-based fax passthrough or both. The
relative ordering of leaf nodes within the leaf lists indicates
preference.
*rtp*: A container that encapsulates generic characteristics of RTP
sessions between the enterprise and service provider network. This
node is a container for the "RTPTrigger" and "SymmetricRTP" leaf
nodes.
*RTPTrigger*: A leaf node indicating whether the SIP service provider
network always expects the enterprise network to send the first RTP
packet for an established communication session. This information is
useful in scenarios such as "hairpinned" calls, in which the caller
and callee are on the service provider network and because of sub-
optimal media routing, an enterprise device such as an SBC is
retained in the media path. Based on the encoding of this node, it
is possible to configure enterprise devices such as SBCs to start
streaming media (possibly filled with silence payloads) toward the
address:port tuples provided by caller and callee. This node is a
Boolean type. A value of 1/true indicates that the service provider
expects the enterprise network to send the first RTP packet, whereas
a value of 0/false indicates that the service provider network does
Inamdar, et al. Expires July 31, 2021 [Page 21]
Internet-Draft SIP Auto Peer January 2021
not require the enterprise network to send the first media packet.
While the practise of preserving the enterprise network in a
hairpinned call flow is fairly common, it is recommended that SIP
service providers avoid this practise. In the context of a
hairpinned call, the enterprise device retained in the call flow can
easily eavesdrop on the conversation between the offnet parties.
*symmetricRTP*: A leaf node indicating whether the SIP service
provider expects the enterprise network to use symmetric RTP as
defined in RFC 4961 [16]. Uncovering this expectation is useful in
scenarios where "latching" [RFC 7362 [17]] is implemented in the
service provider network. This node is a Boolean type, a value of 1/
true indicates that the service provider expects the enterprise
network to use symmetric RTP, whereas a value of 0/false indicates
that the enterprise network can use asymmetric RTP.
*rtcp*: A container that encapsulates generic characteristics of RTCP
sessions between the enterprise and service provider network. This
node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf
nodes.
*RTCPFeedback*: A leaf node that indicates whether the SIP service
provider supports the RTP profile extension for RTCP-based feedback
RFC 4585 [18]. Media sessions spanning enterprise and service
provider networks, are rarely made to flow directly between the
caller and callee, rather, it is often the case that media traffic
flows through network intermediaries such as SBCs. As a result, RTCP
traffic from the service provider network is intercepted by these
intermediaries, which in turn can either pass across RTCP traffic
unmodified or modify RTCP traffic before it is forwarded to the
endpoint in the enterprise network. Modification of RTCP traffic
would be required, for example, if the intermediary has performed
media payload transformation operations such as transcoding or
transrating. In a similar vein, for the RTCP-based feedback
mechanism as defined in RFC 4585 [19] to be truly effective,
intermediaries must ensure that feedback messages are passed reliably
and with the correct formatting to enterprise endpoints. This might
require additional configuration and considerations that need to be
dealt with at the time of provisioning the intermediary device. This
node is a Boolean type, a value of 1/true indicates that the service
provider supports the RTP profile extension for RTP-based feedback
and a value of 0/false indicates that the service provider does not
support the RTP profile extension for RTP-based feedback.
*symmetricRTCP*: A leaf node indicating whether the SIP service
provider expects the enterprise network to use symmetric RTCP as
defined in RFC 4961 [20]. This node is a Boolean type, a value of 1
indicates that the service provider expects symmetric RTCP reports,
Inamdar, et al. Expires July 31, 2021 [Page 22]
Internet-Draft SIP Auto Peer January 2021
whereas a value of 0 indicates that the enterprise can use asymmetric
RTCP.
*dtmf*: A container that describes the various aspects of DTMF relay
via RTP Named Telephony Events. The dtmf container allows SIP
service providers to specify two facets of DTMF relay via Named
Telephony Events:
1. The payload type number using the payloadNumber leaf node.
2. Support for RFC 2833 [21] or RFC 4733 [22] using the iteration
leaf node.
In the context of named telephony events, senders and receivers may
negotiate asymmetric payload type numbers. For example, the sender
might advertise payload type number 97 and the receiver might
advertise payload type number 101. In such instances, it is either
required for middleboxes to interwork payload type numbers or allow
the endpoints to send and receive asymmetric payload numbers. The
behaviour of middleboxes in this context is largely dependent on
endpoint capabilities or on service provider constraints. Therefore,
the payloadNumber leaf node can be used to determine middlebox
configuration before-hand.
RFC 4733 [23] iterates over RFC 2833 [24] by introducing certain
changes in the way NTE events are transmitted. SIP service providers
can indicate support for RFC 4733 [25] by setting the iteration flag
to 1 or indicating support for RFC 2833 [26] by setting the iteration
flag to 0.
*security*: A container that encapsulates characteristics about
encrypting signalling streams between the enterprise and SIP service
provider networks.
*signaling*: A container that encapsulates the type of security
protocol for the SIP communication between the enterprise SBC and the
service provider.
*type*: A leaf node that specifies the protocol used for protecting
SIP signalling messages between the enterprise and service provider
network. The value of the type leaf node is only defined for
Transport Layer Security (TLS). Accordingly, if TLS is allowed for
SIP sessions between the enterprise and service provider network, the
type leaf node is set to the string "tls".
*version*: A leaf node that specifies the version(s) of TLS supported
in decimal format. If multiple versions of TLS are supported, they
should be separated by semi-colons. If the service provide does not
Inamdar, et al. Expires July 31, 2021 [Page 23]
Internet-Draft SIP Auto Peer January 2021
support TLS for protecting SIP sessions, the signalling element is
set to the string "NULL".
*mediaSecurity*: A container that describes the various
characteristics of securing media streams between enterprise and
service provider networks.
*keyManagement*: A leaf node that specifies the key management method
used by the service provider. Possible values of this node include:
"SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP
service provider uses the methods defined in RFC 4568 [27] for the
purpose of key management. A value of "DTLS-SRTP" signifies that the
SIP service provider uses the methods defined in RFC 5764 [28] for
the purpose of key management. If the value of this leaf node is set
to "DTLS-SRTP", the various versions of DTLS supported by the SIP
service provider MUST be encoded as per the formatting rules of
Section 9.2. If the service provider does not support media
security, the keyManagement node MUST be set to "NULL".
*certLocation:*: If the enterprise network is required to exchange
SIP traffic over TLS with the SIP service provider, and if the SIP
service provider is capable of accepting TLS connections from the
enterprise network, it may be required for the SIP service provider
certificates to be pre-installed on the enterprise edge element. In
such situations, the certLocation leaf node is populated with a URL,
which when dereferenced, provides a single PEM encoded file that
contains all certificates in the chain of trust. This is an optional
leaf node.
*extensions*: A leaf node that is a semicolon separated list of all
possible SIP option tags supported by the service provider network.
These extensions must be referenced using name registered under IANA.
If the service provider network does not support any extensions to
baseline SIP, the extensions node must be set to "NULL".
9.4. Extending the Capability Set
There are situations in which equipment manufactures or service
providers would benefit from extending the YANG module defined in
this draft. For example, service providers could extend the YANG
module to include information that further simplifies direct IP
peering. Such information could include: trunk group identifiers,
direct-inward-dial (DID) number ranges allocated to the enterprise,
customer/enterprise account numbers, service provider support
numbers, among others. Extension of the module can be achieved by
importing the module defined in this draft. An example is provided
below: Consider a new YANG module "vendorA" specified for VendorA's
Inamdar, et al. Expires July 31, 2021 [Page 24]
Internet-Draft SIP Auto Peer January 2021
enterprise SBC. The "vendorA-config" YANG module is configured as
follows:
module vendorA-config {
namespace "urn:ietf:params:xml:ns:yang:vendorA-config";
prefix "vendorA";
description
"Data model for configuring VendorA Enterprise SBC";
revision 2020-05-06 {
description "Initial revision of VendorA Enterprise SBC configuration data model";
}
import ietf-peering {
prefix "peering";
}
augment "/peering:peering-info" {
container vendorAConfig {
leaf vendorAConfigParam1 {
type int32;
description "vendorA configuration parameter 1 (SBC Device ID)";
}
leaf vendorAConfigParam2 {
type string;
description "vendorA configuration parameter 2 (SBC Device name)";
}
description "Container for vendorA SBC configuration";
}
}
}
In the example above, a custom module named "vendorA-config" uses the
"augment" statement as defined in Section 4.2.8 of [RFC 7950 [29]] to
extend the module defined in this draft.
10. Example Capability Set Document Encoding
This section provides examples of how capability set documents that
leverage the YANG module defined in this document can be encoded over
JSON or XML.
Inamdar, et al. Expires July 31, 2021 [Page 25]
Internet-Draft SIP Auto Peer January 2021
10.1. XML Capability Set Document
<peering-info xmlns="urn:ietf:params:xml:ns:yang:ietf-peering"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:yang:ietf-peering ietf-peering.xsd">
<variant>1.0</variant>
<transport-info>
<transport>TCP;TLS;UDP</transport>
<registrar>registrar1.voip.example.com:5060</registrar>
<registrar>registrar2.voip.example.com:5060</registrar>
<registrarRealm>voip.example.com</registrarRealm>
<callControl>callServer1.voip.example.com:5060</callControl>
<callControl>192.168.12.25:5065</callControl>
<dns>8.8.8.8</dns>
<dns>208.67.222.222</dns>
<outboundProxy>0.0.0.0</outboundProxy>
</transport-info>
<call-specs>
<earlyMedia>true</earlyMedia>
<signalingForking>false</signalingForking>
<supportedMethods>INVITE;OPTIONS;BYE;CANCEL;ACK;PRACK;SUBSCRIBE;NOTIFY;REGISTER</supportedMethods>
<numRange>
<type>range</type>
<count>20</count>
<value>19725455000</value>
</numRange>
<numRange>
<type>block</type>
<count>2</count>
<value>1972546000</value>
<value>1972546001</value>
</numRange>
</call-specs>
<media>
<mediaTypeAudio>
<mediaFormat>PCMU;rate=8000;ptime=20</mediaFormat>
<mediaFormat> G729;rate=8000;annexb=yes</mediaFormat>
<mediaFormat>G722;rate=8000;bitrate=56k,64k</mediaFormat>
</mediaTypeAudio>
<fax>
<protocol>pass-through</protocol>
<protocol>t38</protocol>
</fax>
<rtp>
<RTPTrigger>true</RTPTrigger>
<symmetricRTP>true</symmetricRTP>
</rtp>
<rtcp>
Inamdar, et al. Expires July 31, 2021 [Page 26]
Internet-Draft SIP Auto Peer January 2021
<symmetricRTCP>true</symmetricRTCP>
<RTCPFeedback>true</RTCPFeedback>
</rtcp>
</media>
<dtmf>
<payloadNumber>101</payloadNumber>
<iteration>0</iteration>
</dtmf>
<security>
<signaling>
<type>TLS</type>
<version>1.0;1.2</version>
</signaling>
<mediaSecurity>
<keyManagement>SDES;DTLS-SRTP,version=1.2</keyManagement>
</mediaSecurity>
<certLocation>https://sipserviceprovider.com/certificateList.pem</certLocation>
</security>
<extensions>timer;rel100;gin;path</extensions>
</peering-response>
11. Example Exchange
This section depicts an example of the configuration flow that
ultimately results in the enterprise edge element obtaining the
capability set document from the SIP service provider. Assuming the
enterprise edge element has been pre-configured with the request
target for the capability set document or has dynamically found the
request target, the edge element generates a HTTPS GET request. This
request can be challenged by the service provider to authenticate the
enterprise.
GET //capdoc?trunkid=trunkent1456 HTTP/1.1
Host: capserver.ssp1.com
Accept:application/peering-info+xml
The capability set document is obtained in the body of the response
and is encoded in XML.
HTTP/1.1 200 OK
Content-Type: application/peering-info+xml
Content-Length: nnn
<peering-info>
...
</peering-info>
Inamdar, et al. Expires July 31, 2021 [Page 27]
Internet-Draft SIP Auto Peer January 2021
12. Security Considerations
[TBD]
13. References
13.1. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119 [30], March 1997.
[4] Bjorklund, M., "YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)", RFC 6020 [31], October 2010.
[8] Schoenwaelder, J., "Common YANG Data Types", RFC 6991 [32], July
2013.
13.2. Informative References
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261 [33], June 2002.
[3] Roach, A. B., "SIP-Specific Event Notification", RFC 6665 [34],
July 2012.
[5] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231 [35], June 2014.
[6] Enns, R., Bjorklund, M., Schoenwaelder, J., Bierman, A., "Network
Configuration Protocol (NETCONF)", RFC 6241 [36], June 2011.
[7] Bjorklund, M., Berger, L., "YANG Tree Diagrams", RFC 8340 [37],
March 2018.
[9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", RFC 4961
[38], July 2007.
[10] Ott, J., Wenger, S., Sato, N., Burmeister, C., Matsushita,
"Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585 [39], July 2006.
[11] Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833 [40], May 2000.
[12] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits,
Telephony Tones, and Telephony Signals", RFC 4733 [41], December,
2006.
Inamdar, et al. Expires July 31, 2021 [Page 28]
Internet-Draft SIP Auto Peer January 2021
[13] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855 [42], February 2007.
[14] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246 [43], August 2008.
[15] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446 [44], August 2018.
[17] Ivov, E., Kaplan, H., Wing, D., "Latching: Hosted NAT Traversal
(HNT) for Media in Real-Time Communication", RFC 7362 [45], September
2014.
[18] Jones, P., Salgueiro, G., Jones, M., Smarr, J., "WebFinger",
[RFC 7033 [46]], September 2013.
[19] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC
6749 [47]], October 2012.
[20] "SIP-PBX / Service Provider Interoperability SIPconnect 2.0 -
Technical Recommendation", SIP Forum, SIP CONNECT 2.0 [48], December
7, 2016
14. Acknowledgments
[TBD]
15. References
15.1. URIs
[1] https://tools.ietf.org/html/rfc3261
[2] https://www.sipforum.org/download/sipconnect-technical-
recommendation-version-2-0/?wpdmdl=2818
[3] https://tools.ietf.org/html/rfc2119
[4] https://tools.ietf.org/html/rfc7092
[5] https://tools.ietf.org/html/rfc7231
[6] https://tools.ietf.org/html/rfc7092
[7] https://tools.ietf.org/html/rfc6665
[8] https://tools.ietf.org/html/rfc6020
Inamdar, et al. Expires July 31, 2021 [Page 29]
Internet-Draft SIP Auto Peer January 2021
[9] https://tools.ietf.org/html/rfc6241
[10] https://tools.ietf.org/html/rfc5246
[11] https://tools.ietf.org/html/rfc7235
[12] https://tools.ietf.org/html/rfc7230
[13] https://tools.ietf.org/html/rfc8340
[14] https://tools.ietf.org/html/rfc6991
[15] https://tools.ietf.org/html/rfc4855
[16] https://tools.ietf.org/html/rfc4961
[17] https://tools.ietf.org/html/rfc7362
[18] https://tools.ietf.org/html/rfc4585
[19] https://tools.ietf.org/html/rfc4585
[20] https://tools.ietf.org/html/rfc4961
[21] https://tools.ietf.org/html/rfc2833
[22] https://tools.ietf.org/html/rfc4733
[23] https://tools.ietf.org/html/rfc4733
[24] https://tools.ietf.org/html/rfc2833
[25] https://tools.ietf.org/html/rfc4733
[26] https://tools.ietf.org/html/rfc2833
[27] https://tools.ietf.org/html/rfc4568
[28] https://tools.ietf.org/html/rfc5764
[29] https://tools.ietf.org/html/rfc7950
[30] https://tools.ietf.org/html/rfc2119
[31] https://tools.ietf.org/html/rfc6020
[32] https://tools.ietf.org/html/rfc6991
Inamdar, et al. Expires July 31, 2021 [Page 30]
Internet-Draft SIP Auto Peer January 2021
[33] https://tools.ietf.org/html/rfc3261
[34] https://tools.ietf.org/html/rfc6665
[35] https://tools.ietf.org/html/rfc7231
[36] https://tools.ietf.org/html/rfc6241
[37] https://tools.ietf.org/html/rfc8040
[38] https://tools.ietf.org/html/rfc4961
[39] https://tools.ietf.org/html/rfc4585
[40] https://tools.ietf.org/html/rfc2833
[41] https://tools.ietf.org/html/rfc4733
[42] https://tools.ietf.org/html/rfc4855
[43] https://tools.ietf.org/html/rfc5246
[44] https://tools.ietf.org/html/rfc8446
[45] https://tools.ietf.org/html/rfc7362
[46] https://tools.ietf.org/html/rfc7033
[47] https://tools.ietf.org/html/rfc6749
[48] https://www.sipforum.org/download/sipconnect-technical-
recommendation-version-2-0-2/
Authors' Addresses
Kaustubh Inamdar
Cisco Systems
Email: kinamdar@cisco.com
Sreekanth Narayanan
Cisco Systems
Email: sreenara@cisco.com
Inamdar, et al. Expires July 31, 2021 [Page 31]
Internet-Draft SIP Auto Peer January 2021
Cullen Jennings
Cisco Systems
Email: fluffy@iii.ca
Inamdar, et al. Expires July 31, 2021 [Page 32]
