draft-ietf-asap-sip-auto-peer-02.txt   draft-ietf-asap-sip-auto-peer-03.txt 
ASAP K. Inamdar ASAP K. Inamdar
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track S. Narayanan Intended status: Standards Track S. Narayanan
Expires: 9 December 2021 C. Jennings Expires: 27 April 2022 C. Jennings
Cisco Systems Cisco Systems
7 June 2021 24 October 2021
Automatic Peering for SIP Trunks Automatic Peering for SIP Trunks
draft-ietf-asap-sip-auto-peer-02 draft-ietf-asap-sip-auto-peer-03
Abstract Abstract
This draft specifies a configuration workflow to enable enterprise This draft specifies a configuration workflow to enable enterprise
Session Initiation Protocol (SIP) networks to solicit the capability Session Initiation Protocol (SIP) networks to solicit the capability
set of a SIP service provider network. The capability set can set of a SIP service provider network. The capability set can
subsequently be used to configure features and services on the subsequently be used to configure features and services on the
enterprise edge element, such as a Session Border Controller (SBC), enterprise edge element, such as a Session Border Controller (SBC),
to ensure smooth peering between enterprise and service provider to ensure smooth peering between enterprise and service provider
networks. networks.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 December 2021. This Internet-Draft will expire on 27 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of Operations . . . . . . . . . . . . . . . . . . . 4 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 3
2.1. Reference Architecture . . . . . . . . . . . . . . . . . 4 2.1. Reference Architecture . . . . . . . . . . . . . . . . . 3
2.2. Configuration Workflow . . . . . . . . . . . . . . . . . 5 2.2. Configuration Workflow . . . . . . . . . . . . . . . . . 5
2.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 8 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 8
4. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8 4. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8 4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8 4.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8
4.3. Authenticated Client Identity . . . . . . . . . . . . . . 9 4.3. Authenticated Client Identity . . . . . . . . . . . . . . 8
4.4. Encoding the Request . . . . . . . . . . . . . . . . . . 9 4.4. Encoding the Request . . . . . . . . . . . . . . . . . . 11
4.5. Identifying the Request Target . . . . . . . . . . . . . 9 4.5. Identifying the Request Target . . . . . . . . . . . . . 11
4.6. Generating the response . . . . . . . . . . . . . . . . . 10 4.6. Generating the response . . . . . . . . . . . . . . . . . 12
5. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 11 5. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Encoding the Service Provider Capability Set . . . . . . . . 11 6. Encoding the Service Provider Capability Set . . . . . . . . 13
7. Data Model for Capability Set . . . . . . . . . . . . . . . . 12 7. Data Model for Capability Set . . . . . . . . . . . . . . . . 13
7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13
7.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 20 7.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 22
7.4. Extending the Capability Set . . . . . . . . . . . . . . 29 7.4. Extending the Capability Set . . . . . . . . . . . . . . 32
8. Processing the Capability Set Response . . . . . . . . . . . 30 8. Processing the Capability Set Response . . . . . . . . . . . 33
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. XML Capability Set Document . . . . . . . . . . . . . . . 31 9.1. JSON Capability Set Document . . . . . . . . . . . . . . 34
9.2. Example Exchange . . . . . . . . . . . . . . . . . . . . 33 9.2. Example Exchange . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
12. Normative References . . . . . . . . . . . . . . . . . . . . 33 12. Normative References . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The deployment of a Session Initiation Protocol [RFC 3261 The deployment of a Session Initiation Protocol [RFC3261] (SIP)-based
(https://tools.ietf.org/html/rfc3261)] (SIP)-based infrastructure in infrastructure in enterprise and service provider communication
enterprise and service provider communication networks is increasing networks is increasing at a rapid pace. Consequently, direct IP
at a rapid pace. Consequently, direct IP peering between enterprise peering between enterprise and service provider networks is quickly
and service provider networks is quickly replacing traditional replacing traditional methods of interconnection between enterprise
methods of interconnection between enterprise and service provider and service provider networks. Currently published standards provide
networks. Currently published standards provide a strong foundation a strong foundation over which direct IP peering can be realized.
over which direct IP peering can be realized. However, given the However, given the sheer number of these standards, it is often not
sheer number of these standards, it is often not clear which clear which behavioral subsets, extensions to baseline protocols and
behavioral subsets, extensions to baseline protocols and operating operating principles ought to be implemented by service provider and
principles ought to be implemented by service provider and enterprise enterprise networks to ensure successful peering.
networks to ensure successful peering.
The SIP Connect technical recommendations The SIP Connect technical recommendations [SIP-Connect-TR] aim to
(https://www.sipforum.org/download/sipconnect-technical- solve this problem by providing a master reference that promotes
recommendation-version-2-0/?wpdmdl=2818) aim to solve this problem by seamless peering between enterprise and service provider SIP
providing a master reference that promotes seamless peering between networks. However, despite the extensive set of implementation rules
enterprise and service provider SIP networks. However, despite the and operating guidelines, interoperability issues between service
extensive set of implementation rules and operating guidelines, provider and enterprise networks persist. This is in large part
interoperability issues between service provider and enterprise because service providers and equipment manufacturers aren't required
networks persist. This is in large part because service providers to enforce the guidelines of the technical specifications and have a
and equipment manufacturers aren't required to enforce the guidelines fair degree of freedom to deviate from them. Consequently,
of the technical specifications and have a fair degree of freedom to enterprise administrators usually undertake a fairly rigorous regimen
deviate from them. Consequently, enterprise administrators usually of testing, analysis and troubleshooting to arrive at a configuration
undertake a fairly rigorous regimen of testing, analysis and block that ensures seamless service provider peering. However, this
troubleshooting to arrive at a configuration block that ensures workflow complements the SIP Connect technical recommendations, in
seamless service provider peering. However, this workflow that both endeavours aim to promote/achieve interop between the
complements the SIP Connect technical recommendations, in that both enterprise and service provider.
endeavours aim to promote/achieve interop between the enterprise and
service provider.
Another set of interoperability problems arise when enterprise Another set of interoperability problems arise when enterprise
administrators are required to translate a set of technical administrators are required to translate a set of technical
recommendations from service providers to configuration blocks across recommendations from service providers to configuration blocks across
one or more devices in the enterprise, which is usually an error one or more devices in the enterprise, which is usually an error
prone exercise. Additionally, such technical recommendations might prone exercise. Additionally, such technical recommendations might
not be nuanced enough to intuitively allow the generation of specific not be nuanced enough to intuitively allow the generation of specific
configuration blocks. configuration blocks.
This draft introduces a mechanism using which an enterprise network This draft introduces a mechanism using which an enterprise network
skipping to change at page 4, line 15 skipping to change at page 3, line 46
2. Overview of Operations 2. Overview of Operations
This section details the configuration workflow proposed by this This section details the configuration workflow proposed by this
draft. draft.
2.1. Reference Architecture 2.1. Reference Architecture
Figure 1 illustrates a reference architecture that may be deployed to Figure 1 illustrates a reference architecture that may be deployed to
support the mechanism described in this document. The enterprise support the mechanism described in this document. The enterprise
network consists of a SIP-PBX, media endpoints and a Session Border network consists of a SIP-PBX, media endpoints and a Session Border
Controller [RFC 7092 (https://tools.ietf.org/html/rfc7092)]. It may Controller [RFC7092]. It may also include additional components such
also include additional components such as application servers for as application servers for voicemail, recording, fax etc. At a high
voicemail, recording, fax etc. At a high level, the service provider level, the service provider consists of a SIP signaling entity (SP-
consists of a SIP signaling entity (SP-SSE), a media entity and a SSE), a media entity and a HTTPS [RFC7231] server.
HTTPS [RFC 7231 (https://tools.ietf.org/html/rfc7231)] server.
+-----------------------------------------------------+ +-----------------------------------------------------+
| +---------------+ +-----------------------+ | | +---------------+ +-----------------------+ |
| | | | | | | | | | | |
| | +----------+ | | +-------+ | | | | +----------+ | | +-------+ | |
| | | Cap | | HTTPS | | | | | | | | Cap | | HTTPS | | | | |
| | | Server |<-|---------|-->| | | | | | | Server |<-|---------|-->| | | |
| | | | | | | | +-----+ | | | | | | | | | | +-----+ | |
| | +----------+ | | | | | SIP | | | | | +----------+ | | | | | SIP | | |
| | | | | |<->| PBX | | | | | | | | |<->| PBX | | |
skipping to change at page 5, line 8 skipping to change at page 4, line 41
* Enterprise Network: A communications network infrastructure * Enterprise Network: A communications network infrastructure
deployed by an enterprise which interconnects with the service deployed by an enterprise which interconnects with the service
provider network over SIP. The enterprise network could include provider network over SIP. The enterprise network could include
devices such as application servers, endpoints, call agents and devices such as application servers, endpoints, call agents and
edge devices, among others. edge devices, among others.
* Edge Device: A device that is the last hop in the enterprise * Edge Device: A device that is the last hop in the enterprise
network and that is the transit point for traffic entering and network and that is the transit point for traffic entering and
leaving the enterprise. An edge device is typically a back-to- leaving the enterprise. An edge device is typically a back-to-
back user agent (B2BUA) [RFC 7092 (https://tools.ietf.org/html/ back user agent (B2BUA) [RFC7092] such as a Session Border
rfc7092)] such as a Session Border Controller (SBC). Controller (SBC).
* Service Provider Network: A communications network infrastructure * Service Provider Network: A communications network infrastructure
deployed by service providers. In the context of this draft, the deployed by service providers. In the context of this draft, the
service provider network is accessible over SIP for the service provider network is accessible over SIP for the
establishment, modification and termination of calls and establishment, modification and termination of calls and
accessible over HTTPS for the transfer of the capability set accessible over HTTPS for the transfer of the capability set
document. The service provider network is also referred to as a document. The service provider network is also referred to as a
SIP Service Provider (SSP) or Internet Telephony Service Provider SIP Service Provider (SSP) or Internet Telephony Service Provider
(ITSP) network. (ITSP) network.
skipping to change at page 6, line 27 skipping to change at page 6, line 11
enterprise network can solicit and ultimately obtain the service enterprise network can solicit and ultimately obtain the service
provider capability set. The enterprise network creates a well provider capability set. The enterprise network creates a well
formed HTTPS GET request to solicit the service provider capability formed HTTPS GET request to solicit the service provider capability
set. Subsequently, the HTTPS response from the SIP service provider set. Subsequently, the HTTPS response from the SIP service provider
includes the capability set. The capability set is encoded in either includes the capability set. The capability set is encoded in either
XML or JSON, thus ensuring that the response can be easily parsed by XML or JSON, thus ensuring that the response can be easily parsed by
automaton. automaton.
There are alternative mechanisms using which the SIP service provider There are alternative mechanisms using which the SIP service provider
can offload its capability set. For example, the Session Initiation can offload its capability set. For example, the Session Initiation
Protocol (SIP) can be extended to define a new event package [RFC Protocol (SIP) can be extended to define a new event package
6665 (https://tools.ietf.org/html/rfc6665)], such that the enterprise [RFC6665], such that the enterprise network can establish a SIP
network can establish a SIP subscription with the service provider subscription with the service provider for its capability set; the
for its capability set; the SIP service provider can subsequently use SIP service provider can subsequently use the SIP NOTIFY request to
the SIP NOTIFY request to communicate its capability set or any state communicate its capability set or any state deltas to its baseline
deltas to its baseline capability set. capability set.
This mechanism is likely to result in a barrier to adoption for SIP This mechanism is likely to result in a barrier to adoption for SIP
service providers and enterprise networks as equipment manufacturers service providers and enterprise networks as equipment manufacturers
would have to first add support for such a SIP extension. A HTTPS- would have to first add support for such a SIP extension. A HTTPS-
based approach would be relatively easier to adopt as most edge based approach would be relatively easier to adopt as most edge
devices deployed in enterprise networks today already support HTTPS; devices deployed in enterprise networks today already support HTTPS;
from the perspective of service provider networks, all that is from the perspective of service provider networks, all that is
required is for them to deploy HTTPS servers that function as required is for them to deploy HTTPS servers that function as
capability servers. Additionally, most SIP service providers require capability servers. Additionally, most SIP service providers require
enterprise networks to register with them (using a SIP REGISTER enterprise networks to register with them (using a SIP REGISTER
message) before any other SIP methods that initiate subscriptions message) before any other SIP methods that initiate subscriptions
(SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a (SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a
SIP-based framework to obtain a capability set would require SIP-based framework to obtain a capability set would require
operational changes on the part of service provider networks. operational changes on the part of service provider networks.
Yet another example of an alternative mechanism would be for service Yet another example of an alternative mechanism would be for service
providers and enterprise equipment manufacturers to agree on YANG providers and enterprise equipment manufacturers to agree on YANG
models [RFC 6020 (https://tools.ietf.org/html/rfc6020)] that enable models [RFC6020] that enable configuration to be pushed over NETCONF
configuration to be pushed over NETCONF [RFC 6241 [RFC6241] to enterprise networks from a centralised source hosted in
(https://tools.ietf.org/html/rfc6241)] to enterprise networks from a service provider networks. The presence of proprietary software
centralised source hosted in service provider networks. The presence logic for call and media handling in enterprise devices would
of proprietary software logic for call and media handling in preclude the generation of a "one-size-fits-all" YANG model.
enterprise devices would preclude the generation of a "one-size-fits- Additionally, service provider networks pushing configuration to
all" YANG model. Additionally, service provider networks pushing enterprises devices might lead to the loss of implementation autonomy
configuration to enterprises devices might lead to the loss of on the part of the enterprise network.
implementation autonomy on the part of the enterprise network.
2.3. Transport 2.3. Transport
To solicit the capability set of a SIP service provider, the edge To solicit the capability set of a SIP service provider, the edge
element in an enterprise network generates a well-formed HTTPS GET element in an enterprise network generates a well-formed HTTPS GET
request. There are two reasons why it makes sense for the enterprise request. There are two reasons why it makes sense for the enterprise
edge element to generate the HTTPS request: edge element to generate the HTTPS request:
1. Edge elements are devices that normalise any mismatches between 1. Edge elements are devices that normalise any mismatches between
the enterprise and service provider networks in the media and the enterprise and service provider networks in the media and
skipping to change at page 8, line 40 skipping to change at page 8, line 30
The workflow defined in this document leverages the HTTPS GET method The workflow defined in this document leverages the HTTPS GET method
and its corresponding response(s) to request for and subsequently and its corresponding response(s) to request for and subsequently
obtain the service provider capability set document. obtain the service provider capability set document.
4.2. Integrity and Confidentiality 4.2. Integrity and Confidentiality
Peering requests and responses are defined over HTTPS. However, due Peering requests and responses are defined over HTTPS. However, due
to the sensitive nature of information transmitted between client and to the sensitive nature of information transmitted between client and
server, it is required to secure HTTP using Transport Layer Security server, it is required to secure HTTP using Transport Layer Security
[RFC 5246 (https://tools.ietf.org/html/rfc5246)]. The enterprise [RFC5246]. The enterprise edge element and capability server MUST be
edge element and capability server MUST be compliant with RFC 7235 compliant with [RFC7235]. The enterprise edge element and capability
(https://tools.ietf.org/html/rfc7235). The enterprise edge element server MUST support the use of the HTTPS uri scheme as defined in RFC
and capability server MUST support the use of the HTTPS uri scheme as 7230 (https://tools.ietf.org/html/rfc7230).
defined in RFC 7230 (https://tools.ietf.org/html/rfc7230).
4.3. Authenticated Client Identity 4.3. Authenticated Client Identity
It is only required for the SIP service provider to authenticate the HTTP usually adopts asymmetric methods of authentication. For
client (enterprise edge element). How the SIP service provider example, clients typically use certificate based authentication to
authenticates the client is out of the scope of this document, verify the server they are talking to, whereas, servers typically use
however, methods such as HTTP Digest Authentication or validation of methods such as HTTP digest authentication or OAuth2.0 to
the hostname presented in the certificate during the TLS exchange may authenticate clients. Though OAuth2.0 is not an authentication
be used. protocol, it nonetheless allows for client authentication to be
carried out with the use of OAuth tokens.
Figure 2 elucidates the use of this grant type.
In the context of the SIP Auto Peer framework, OAuth2.0 MUST be used
to carry out client authentication. Enterprise edge elements that
obtain the capability set document from SIP service providers could
have differing capabilities in terms of adhering to a specific
OAuth2.0 authorisation grant flow. For example, an SBC that is
configured and managed through a CLI and that does not have the
ability to launch a web-browser wouldn't be able to obtain an
authorisation code and subsequently an access token. Alternatively,
an SBC that is configured and managed via a GUI could redirect an
administrator to an appropriate OAuth2.0 authorisation server to
obtain an authorisation grant and subsequently an access token. In
order to ensure that OAuth2.0-based client authentication can be
carried out irrespective of enterprise edge element capabilities,
this draft requires that the Resource Owner Password Credentials
grant type be supported.
Using the resource owner password credentials grant type requires the
existence of a trust relationship between the resource owner(in this
context, the administrator/enterprise network) and the client(in this
context, an edge element such as an SBC). In SIP trunking
deployments between enterprise and service provider networks, such a
trust relationship between the administrator/resource owner/
enterprise network and the client(edge element) already exists, as
SIP trunk registration (and refreshing registrations) require
credentials - typically a username and password, that are configured
on the edge element by the administrator.
The use of the resource owner credential grant type in the context of
the SIP Auto Peer framework, provides two advantages:
1. It enables OAuth2.0-based client authentication even in
deployments in wherein the edge element is not capable of
launching a web-browser to set in motion the authorisation code
grant flow of OAuth2.0
2. For situations in which a refresh token is not provided by the
authorisation endpoint, human/administrator involvement is not
required to obtain fresh tokens once an existing token expires.
Figure 2 provides a high-level diagrammatic illustration of how
OAuth2.0-based client authentication is achieved using resource
owner credentials in the context of SIP Auto Peer.
+--------------+
| Resource |
| Owner |
| (Enterprise) |
+--------------+
v
| Resource Owner
(1) Password Credentials
|
v
+---------+ +---------------+
| |>--(2)---- Resource Owner ------->| Service |
| Client | Password Credentials | Provider |
| | | Authorization |
| (SBC) |<--(3)---- Access Token ---------<| Server |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
^ v
| |
| | +--------------+
| -------(4)---- Access Token --------->| Capability |
-----------(5)---- Capability set -------<| Server |
+--------------+
Figure 2: Client Authentication Mechanism
The flow illustrated in Figure 2 includes the following steps:
1. The enterprise SBC stores the enterprise credentials required to
authenticate with the authorization server located in the service
provider network. These credentials may be passed to the
enterprise from the service provider in an out-of-band fashion
such as an email or a self-management service provided by the
service provider to the enterprise.
2. The enterprise SBC contacts the service provider authorization
server to obtain an access token using the credentials acquired
in Step 1.
3. The service provider authorization server ratifies the
credentials and grants the access token to the enterprise SBC.
The server could also provide a refresh token to the SBC to
regenerate the access token in the future.
4. The enterprise SBC then contacts the capability server located in
the service provider network with an HTTPS GET request along with
the access token to retrieve the capability set document.
5. The capability server checks for a valid access token and returns
the capability set document to the enterprise SBC.
4.4. Encoding the Request 4.4. Encoding the Request
The edge element in the enterprise network generates a HTTPS GET The edge element in the enterprise network generates a HTTPS GET
request such that the request-target is obtained using the procedure request such that the request-target is obtained using the procedure
outlined in section 6.6 The MIME types for the capability set outlined in section 6.6 The MIME types for the capability set
document defined in this draft are "application/peering-info+json" document defined in this draft are "application/peering-info+json"
and "application/peering-info+xml". Accordingly, the Accept header and "application/peering-info+xml". Accordingly, the Accept header
field value MUST be restricted only to these MIME types. It is field value MUST be restricted only to these MIME types. It is
possible that the edge element supports responses formatted in both possible that the edge element supports responses formatted in both
skipping to change at page 10, line 9 skipping to change at page 12, line 5
interface - for example, a CLI or GUI. interface - for example, a CLI or GUI.
However, if the resource URL is unknown to the administrator (and by However, if the resource URL is unknown to the administrator (and by
extension of that to the edge element), the WebFinger protocol RFC extension of that to the edge element), the WebFinger protocol RFC
7033 (https://tools.ietf.org/html/rfc5764) may be leveraged. 7033 (https://tools.ietf.org/html/rfc5764) may be leveraged.
If an enterprise edge element attempts to discover the URL of the If an enterprise edge element attempts to discover the URL of the
endpoints hosted in the ssp1.example.com domain, it issues the endpoints hosted in the ssp1.example.com domain, it issues the
following request (line wraps are for display purposes only). following request (line wraps are for display purposes only).
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=http%3A%2F%2Fssp1.example.com resource=http%3A%2F%2Fssp1.example.com
rel=capabilitySet rel=capabilitySet
HTTP/1.1 HTTP/1.1
Host: ssp1.example.com Host: ssp1.example.com
HTTP/1.1 200 OK HTTP/1.1 200 OK
Access-Control-Allow-Origin: * Access-Control-Allow-Origin: *
Content-Type: application/jrd+json Content-Type: application/jrd+json
{ {
"subject" : "http://ssp1.example.com", "subject" : "http://ssp1.example.com",
"links" : "links" :
[ [
{ {
"rel" : "capabilitySet", "rel" : "capabilitySet",
"href" :"https://capserver.ssp1.com/capserver/capdoc.xml" "href" :
}, "https://capserver.ssp1.com/capserver/capdoc.json"
] },
} ]
}
Once the target URI is obtained by an enterprise telephony network, Once the target URI is obtained by an enterprise telephony network,
the URI may be dereferenced to obtain a unique capability set the URI may be dereferenced to obtain a unique capability set
document that is specific to that given enterprise telephony network. document that is specific to that given enterprise telephony network.
The ITSP may use credentials to determine the identity of the The ITSP may use credentials to determine the identity of the
enterprise telephony network and provide the appropriate capability enterprise telephony network and provide the appropriate capability
set document. set document.
TODO: Should we have a new link-relation type registered for ASAP?
4.6. Generating the response 4.6. Generating the response
Capability servers include the capability set documents in the body Capability servers include the capability set documents in the body
of a successful response. Capability set documents MUST be formatted of a successful response. Capability set documents MUST be formatted
in XML or JSON. For requests that are incorrectly formatted, the in XML or JSON. For requests that are incorrectly formatted, the
capability server must generate a "400 Bad Request" response. If the capability server must generate a "400 Bad Request" response. If the
client (enterprise edge element) includes any other MIME types in client (enterprise edge element) includes any other MIME types in
Accept header field other than "application/peering-info+json" or Accept header field other than "application/peering-info+json" or
"application/peering-info+xml", the capability set must reject the "application/peering-info+xml", the capability set must reject the
request with a "406 Not Acceptable" response. request with a "406 Not Acceptable" response.
skipping to change at page 12, line 14 skipping to change at page 13, line 49
7. Data Model for Capability Set 7. Data Model for Capability Set
This section defines a YANG module for encoding the service provider This section defines a YANG module for encoding the service provider
capability set. Section 9.1 provides the tree diagram, which is capability set. Section 9.1 provides the tree diagram, which is
followed by a description of the various nodes within the module followed by a description of the various nodes within the module
defined in this draft. defined in this draft.
7.1. Tree Diagram 7.1. Tree Diagram
This section provides a tree diagram [RFC 8340 This section provides a tree diagram [RFC8340] for the "ietf-
(https://tools.ietf.org/html/rfc8340)] for the "ietf-capability-set" capability-set" module. The interpretation of the symbols appearing
module. The interpretation of the symbols appearing in the tree in the tree diagram is as follows:
diagram is as follows:
* Brackets "[" and "]" enclose list keys. * Brackets "[" and "]" enclose list keys.
* Abbreviations before data node names: "rw" means configuration * Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only). (read-write), and "ro" means state data (read-only).
* Symbols after data node names: "?" means an optional node, "!" * Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list. means a presence container, and "*" denotes a list and leaf-list.
* Parentheses enclose choice and case nodes, and case nodes are also * Parentheses enclose choice and case nodes, and case nodes are also
skipping to change at page 13, line 8 skipping to change at page 14, line 25
* Ellipsis ("...") stands for contents of subtrees that are not * Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
The data model for the peering capability document has the following The data model for the peering capability document has the following
structure: structure:
module: ietf-sip-auto-peering module: ietf-sip-auto-peering
+--rw peering-info +--rw peering-info
+--rw variant string +--rw variant string
+--rw revision
| +--rw notBefore? string
| +--rw location? string
+--rw transport-info +--rw transport-info
| +--rw transport? enumeration | +--rw transport? enumeration
| +--rw registrar* host-port | +--rw registrar* host-port
| +--rw registrarRealm? string | +--rw registrarRealm? string
| +--rw callControl* host-port | +--rw callControl* host-port
| +--rw dns* inet:ip-address | +--rw dns* inet:ip-address
| +--rw outboundProxy? host-port | +--rw outboundProxy? host-port
+--rw call-specs +--rw call-specs
| +--rw earlyMedia? boolean | +--rw earlyMedia? boolean
| +--rw signalingForking? boolean | +--rw signalingForking? boolean
| +--rw supportedMethods? string | +--rw supportedMethods? string
| +--rw callerId
| | +--rw e164Format? boolean
| | +--rw preferredMethod? string
| +--rw numRange | +--rw numRange
| +--rw numRangeType? string | +--rw numRangeType? string
| +--rw count? int32 | +--rw count? int32
| +--rw value* string | +--rw value* string
+--rw media +--rw media
| +--rw mediaTypeAudio | +--rw mediaTypeAudio
| | +--rw mediaFormat* string | | +--rw mediaFormat* string
| +--rw fax | +--rw fax
| | +--rw protocol* enumeration | | +--rw protocol* enumeration
| +--rw rtp | +--rw rtp
skipping to change at page 14, line 9 skipping to change at page 15, line 28
| +--rw secureTelephonyIdentity | +--rw secureTelephonyIdentity
| +--rw STIRCompliance? boolean | +--rw STIRCompliance? boolean
| +--rw certDelegation? boolean | +--rw certDelegation? boolean
| +--rw ACMEDirectory? string | +--rw ACMEDirectory? string
+--rw extensions? string +--rw extensions? string
7.2. YANG Model 7.2. YANG Model
This section defines the YANG module for the peering capability set This section defines the YANG module for the peering capability set
document. It imports modules (ietf-yang-types and ietf-inet-types) document. It imports modules (ietf-yang-types and ietf-inet-types)
from [RFC 6991 (https://tools.ietf.org/html/rfc6991)]. from [RFC6991].
module ietf-sip-auto-peering { module ietf-sip-auto-peering {
namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering"; namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering";
prefix "peering"; prefix "peering";
description description
"Data model for transmitting peering parameters from SP to "Data model for transmitting peering parameters from SP to
Enterprise"; Enterprise";
revision 2019-05-06 { revision 2019-05-06 {
description "Initial revision of peering-response doc."; description "Initial revision of peering-response doc.";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
typedef ipv4-address-port { typedef ipv4-address-port {
type string { type string {
pattern "(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\" 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])" + "\.){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]" + ":^()([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])$"; + "{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 { description "The ipv4-address-port type represents an IPv4
pattern "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}" address in dotted-quad notation followed by a port number.";
+ "((([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.";
}
typedef ip-address-port { typedef ipv6-address-port {
type union { type string {
type ipv4-address-port; pattern "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}"
type ipv6-address-port; + "((([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}"
description + "(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))"
"The ip-address-port type represents an IP address:port number + ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]"
and is IP version neutral."; + "{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.";
}
typedef domain-name-port { typedef ip-address-port {
type string { type union {
pattern type ipv4-address-port;
"((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*" type ipv6-address-port;
+ "([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)" }
+ "|\." description
+ ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]" "The ip-address-port type represents an IP address:port number
+ "{2}655[1-2][0-9]|6553[1-5])$"; and is IP version neutral.";
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 { typedef domain-name-port {
type union { type string {
type ip-address-port; pattern
type domain-name-port; "((([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]\.?)"
description + "|\."
"The host type represents either an IP address or a DNS + ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]"
domain name followed by a port number."; + "{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.";
}
container peering-info { typedef host-port {
leaf variant { type union {
type string; type ip-address-port;
mandatory true; type domain-name-port;
description "Variant of peering-response document"; }
} description
container transport-info { "The host type represents either an IP address or a DNS
leaf transport { domain name followed by a port number.";
type enumeration { }
enum "TCP";
enum "TLS";
enum "UDP";
enum "TCP;TLS";
enum "TCP;TLS;UDP";
enum "TCP;UDP";
}
description "Transport Protocol(s) used in SIP
communication";
}
leaf-list registrar { container peering-info {
type host-port; leaf variant {
max-elements 3; type string;
description "List of service provider registrar servers"; mandatory true;
} description "Variant of peering-response document";
}
leaf registrarRealm { container revision {
type string; leaf notBefore {
description "Realm for REGISTER requests carrying type string;
credentials"; description "Time and date of activation of new
} capability set";
}
leaf-list callControl { leaf location {
type host-port; type string;
max-elements 3; description "Location of the new version of
description "List of service provider call control servers"; capability set document";
} }
}
leaf-list dns { container transport-info {
type inet:ip-address; leaf transport {
max-elements 2; type enumeration {
description "IP address of the DNS Server(s) hosted by the enum "TCP";
service provider"; enum "TLS";
} enum "UDP";
enum "TCP;TLS";
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 outboundProxy { leaf registrarRealm {
type host-port; type string;
description "SIP Outbound Proxy"; description "Realm for REGISTER requests carrying
} credentials";
} }
container call-specs { leaf-list callControl {
leaf earlyMedia { type host-port;
type boolean; max-elements 3;
description "Flag indicating whether the service provider description "List of service provider call control
is expected to deliver early media."; servers";
} }
leaf signalingForking { leaf-list dns {
type boolean; type inet:ip-address;
description "Flag indicating whether the service provider max-elements 2;
is capable of forking incoming calls "; description "IP address of the DNS Server(s) hosted by the
} service provider";
}
leaf supportedMethods { leaf outboundProxy {
type string; type host-port;
description "Leaf/Leaf List indicating the different SIP description "SIP Outbound Proxy";
methods support by the service provider."; }
} }
container numRange { container call-specs {
leaf numRangeType { leaf earlyMedia {
type string; type boolean;
description "String indicating whether the DID number description "Flag indicating whether the service provider
range is passed by value or by reference" is expected to deliver early media.";
} }
leaf count { leaf signalingForking {
when "../numRangeType = 'range' or type boolean;
../numRangeType = 'block'"; description "Flag indicating whether the service provider
type int32; is capable of forking incoming calls ";
description "Number of DID numbers present in the number }
range."
}
leaf-list value { leaf supportedMethods {
type string; type string;
description "Value of the DID number range or URL being description "Leaf/Leaf List indicating the different SIP
passed as reference." methods support by the service provider.";
} }
} container callerId {
} leaf e164Format {
type boolean;
description "Flag indicating whether enterprise must
format caller information into E.164";
}
container media { leaf preferredMethod {
container mediaTypeAudio { type string;
leaf-list mediaFormat { description "Field that instructs enterprise regarding
type string; which SIP header it must populate to communicate caller
description "Leaf List indicating the audio media formats information.";
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.";
}
}
container rtp { container numRange {
leaf RTPTrigger { leaf numRangeType {
type boolean; type string;
description "Flag indicating whether the service provider description "String indicating whether the DID number
expects to receive the first media packet."; range is passed by value or by reference";
} }
leaf symmetricRTP { leaf count {
type boolean; when "../numRangeType = 'range' or
description "Flag indicating whether the service provider ../numRangeType = 'block'";
expects symmetric RTP defined in [@RFC4961]"; type int32;
} description "Number of DID numbers present in the number
} range.";
}
container rtcp { leaf-list value {
leaf symmetricRTCP { type string;
type boolean; description "Value of the DID number range or URL being
description " Flag indicating whether the service passed as reference.";
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 { container media {
leaf payloadNumber { container mediaTypeAudio {
type int8 { leaf-list mediaFormat {
range "96..127"; type string;
} description "Leaf List indicating the audio media formats
description "Leaf that indicates the payload number(s) supported.";
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 fax {
container signaling { leaf-list protocol {
leaf type { type enumeration {
type string { enum "pass-through";
pattern "TLS"; enum "t38";
} }
description "Type of signaling security supported."; max-elements 2;
} description "Leaf List indicating the different fax
protocols supported by the service provider.";
}
}
leaf version { container rtp {
type string { leaf RTPTrigger {
pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)"; type boolean;
} description "Flag indicating whether the service provider
description "Indicates TLS version for SIP signaling"; expects to receive the first media packet.";
} }
}
container mediaSecurity { leaf symmetricRTP {
leaf keyManagement { type boolean;
type string { description "Flag indicating whether the service provider
pattern "(SDES(;DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]" expects symmetric RTP defined in [@RFC4961]";
+ "\.[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 { container rtcp {
type string; leaf symmetricRTCP {
description "Location of the service provider certificate type boolean;
chain for SIP over TLS."; description "Flag indicating whether the service
} provider expects symmetric RTP defined in [@RFC4961].";
}
container secureTelephonyIdentity { leaf RTCPfeedback {
leaf STIRCompliance { type boolean;
type boolean; description "Flag Indicating support for RTP profile
description "Indicates whether the SIP service provider extension for RTCP-based feedback, as defined in
is STIR compliant."; [@RFC4585]";
} }
}
}
leaf certDelegation { container dtmf {
type boolean; leaf payloadNumber {
description "Indicates whether a SIP service provider is type int8 {
willing to delegate authority to the enterprise network range "96..127";
over its allocated number range(s)"; }
} description "Leaf that indicates the payload number(s)
supported by the service provider for DTMF relay via
Named-Telephony-Events";
}
leaf ACMEDirectory { leaf iteration {
when "../certDelegation = 1 type boolean;
or ../certDelegation = 'true'"; description "Flag identifying whether the service provider
type string; supports NTE DTMF relay using the procedures of [@RFC2833]
description "Directory object URL, when de-referenced, or [@RFC4733] .";
provides a collection of field name-value pairs to }
kickstart ACME."; }
}
}
}
leaf extensions { container security {
type string; container signaling {
description "Lists the various SIP extensions supported by leaf type {
the service provider."; 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.";
}
container secureTelephonyIdentity {
leaf STIRCompliance {
type boolean;
description "Indicates whether the SIP service provider
is STIR compliant.";
}
leaf certDelegation {
type boolean;
description "Indicates whether a SIP service provider is
willing to delegate authority to the enterprise network
over its allocated number range(s)";
}
leaf ACMEDirectory {
when "../certDelegation = 1
or ../certDelegation = 'true'";
type string;
description "Directory object URL, when de-referenced,
provides a collection of field name-value pairs to
kickstart ACME.";
}
}
}
leaf extensions {
type string;
description "Lists the various SIP extensions supported by
the service provider.";
}
}
}
7.3. Node Definitions 7.3. Node Definitions
This sub-sections provides the definition and encoding rules of the This sub-sections provides the definition and encoding rules of the
various nodes of the YANG module defined in section 9.2 various nodes of the YANG module defined in section 9.2
*capability-set*: This node serves as a container for all the other *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 nodes in the YANG module; the capability-set node is akin to the root
element of an XML schema. element of an json document.
*variant*: This node identifies the version number of the capability *variant*: This node identifies the version number of the capability
set document. This draft defines the parameters for variant 1.0; set document. This draft defines the parameters for variant 1.0;
future specifications might define a richer parameter set, in which 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 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 extensions to the capability set document MUST also ensure that the
corresponding YANG module is defined. corresponding YANG module is defined.
*revision*: The revision node is a container that encapsulates
information regarding the availability of a new version of the
capability set document for the enterprise.
*notBefore*: The notBefore node indicates the date and time at which
the new capabilities go live in the service provider network.
*location*: This leaf node value provides the URL of the new revision
of the capability set document
*transport-info*: The transport-info node is a container that *transport-info*: The transport-info node is a container that
encapsulates transport characteristics of SIP sessions between encapsulates transport characteristics of SIP sessions between
enterprise and service provider networks. enterprise and service provider networks.
*transport*: A leaf node that enumerates the different Transport *transport*: A leaf node that enumerates the different Transport
Layer protocols supported by the SIP service provider. Valid Layer protocols supported by the SIP service provider. Valid
transport layer protocols include: UDP, TCP, TLS or a combination of transport layer protocols include: UDP, TCP, TLS or a combination of
them (with the exception of TLS and UDP). them (with the exception of TLS and UDP).
*registrar*: A leaf-list that specifies the transport address of one *registrar*: A leaf-list that specifies the transport address of one
skipping to change at page 22, line 49 skipping to change at page 25, line 30
from the enterprise. A value of 0/false indicates that the service from the enterprise. A value of 0/false indicates that the service
provider will not fork outbound call requests. provider will not fork outbound call requests.
*supportedMethods*: A leaf node that specifies the various SIP *supportedMethods*: A leaf node that specifies the various SIP
methods supported by the SIP service provider. The list of supported methods supported by the SIP service provider. The list of supported
methods help to appropriately configuration various devices within methods help to appropriately configuration various devices within
the enterprise network. For example, if the service provider the enterprise network. For example, if the service provider
enumerates support for the OPTIONS method, the enterprise network enumerates support for the OPTIONS method, the enterprise network
could periodically send OPTIONS requests as a keep-alive mechanism. could periodically send OPTIONS requests as a keep-alive mechanism.
*callerId*: This is a container that encodes the preferences of SIP
Service Providers in terms calling number presentation by the
enterprise network. Certain ITSPs require that the calling number be
formatted in E.164, whereas others place no such restrictions.
Additionally, some ITSPs require that the calling number be included
in a specific SIP header field, for example, the P-Asserted-ID header
field or the P-Asserted-ID field, whereas others place no
restrictions on the specific SIP header field used to convey the
calling number.
*e164Format*: A leaf node that indicates whether the service provider
requires enterprise to normalize the caller number into the E.164
format while communicating caller details. This node is of the
boolean type. A value of 'true' or '1' mandates the enterprise
format caller numbers into the E.164 format, while a 'false' or '0'
leaves the formatting of the caller number up to the enterprise.
*preferredMethod*: A leaf node that instructs the enterprise
regarding which SIP header to populate the caller information into
when communicating caller ID information. This node will contain the
name of the SIP Header.
*numRange*: Is a container that specifies the Direct Inward Dial *numRange*: Is a container that specifies the Direct Inward Dial
(DID) number range allocated to the enterprise network by the SIP (DID) number range allocated to the enterprise network by the SIP
service provider. The DID number range allocated by the service service provider. The DID number range allocated by the service
provider to the enterprise network might be a contiguous or a non- provider to the enterprise network might be a contiguous or a non-
contiguous block. The number range allocated to an enterprise can be contiguous block. The number range allocated to an enterprise can be
communicated as a value or as a reference. For large enterprise communicated as a value or as a reference. For large enterprise
networks, the size of the DID range might run into several hundred networks, the size of the DID range might run into several hundred
numbers. For situations in which the enterprise is allocated a large numbers. For situations in which the enterprise is allocated a large
DID number range or a non-contiguous number range it is RECOMMENDED DID number range or a non-contiguous number range it is RECOMMENDED
that the SIP service provider communicate this information by that the SIP service provider communicate this information by
skipping to change at page 24, line 7 skipping to change at page 27, line 13
supported by the SIP service provider. supported by the SIP service provider.
*mediaFormat*: A leaf-list encoding the various audio media formats *mediaFormat*: A leaf-list encoding the various audio media formats
supported by the SIP service provider. The relative ordering of supported by the SIP service provider. The relative ordering of
different media format leaf nodes from left to right indicates different media format leaf nodes from left to right indicates
preference from the perspective of the service provider. Each preference from the perspective of the service provider. Each
mediaFormat node begins with the encoding name of the media format, 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/ which is the same encoding name as used in the "RTP/AVP" and "RTP/
SAVP" profiles. The encoding name is followed by required and SAVP" profiles. The encoding name is followed by required and
optional parameters for the given media format as specified when the optional parameters for the given media format as specified when the
media format is registered [RFC 4855 (https://tools.ietf.org/html/ media format is registered [RFC4855]. Given that the parameters of
rfc4855)]. Given that the parameters of media formats can vary from media formats can vary from one communication session to another, for
one communication session to another, for example, across two example, across two separate communication sessions, the
separate communication sessions, the packetization time (ptime) used packetization time (ptime) used for the PCMU media format might vary
for the PCMU media format might vary from 10 to 30 ms, the parameters from 10 to 30 ms, the parameters included in the format element must
included in the format element must be the ones that are expected to be the ones that are expected to be invariant from the perspective of
be invariant from the perspective of the service provider. Providing the service provider. Providing information about supported media
information about supported media formats and their respective formats and their respective parameters, allows enterprise networks
parameters, allows enterprise networks to configure the media plane to configure the media plane characteristics of various devices such
characteristics of various devices such as endpoints and middleboxes. as endpoints and middleboxes. The encoding name, one or more
The encoding name, one or more required parameters, one or more required parameters, one or more optional parameters are all
optional parameters are all separated by a semicolon. The formatting separated by a semicolon. The formatting of a given media format
of a given media format parameter, must follow the formatting rules parameter, must follow the formatting rules as specified for that
as specified for that media format. media format.
*fax*: A container that encapsulates the fax protocol(s) supported by *fax*: A container that encapsulates the fax protocol(s) supported by
the SIP service provider. The fax container encloses a leaf-list the SIP service provider. The fax container encloses a leaf-list
(named protocol) that enumerates whether the service provider (named protocol) that enumerates whether the service provider
supports t38 relay, protocol-based fax passthrough or both. The supports t38 relay, protocol-based fax passthrough or both. The
relative ordering of leaf nodes within the leaf lists indicates relative ordering of leaf nodes within the leaf lists indicates
preference. preference.
*rtp*: A container that encapsulates generic characteristics of RTP *rtp*: A container that encapsulates generic characteristics of RTP
sessions between the enterprise and service provider network. This sessions between the enterprise and service provider network. This
skipping to change at page 25, line 29 skipping to change at page 28, line 15
While the practise of preserving the enterprise network in a While the practise of preserving the enterprise network in a
hairpinned call flow is fairly common, it is recommended that SIP hairpinned call flow is fairly common, it is recommended that SIP
service providers avoid this practise. In the context of a service providers avoid this practise. In the context of a
hairpinned call, the enterprise device retained in the call flow can hairpinned call, the enterprise device retained in the call flow can
easily eavesdrop on the conversation between the offnet parties. easily eavesdrop on the conversation between the offnet parties.
*symmetricRTP*: A leaf node indicating whether the SIP service *symmetricRTP*: A leaf node indicating whether the SIP service
provider expects the enterprise network to use symmetric RTP as provider expects the enterprise network to use symmetric RTP as
defined in RFC 4961 (https://tools.ietf.org/html/rfc4961). defined in RFC 4961 (https://tools.ietf.org/html/rfc4961).
Uncovering this expectation is useful in scenarios where "latching" Uncovering this expectation is useful in scenarios where "latching"
[RFC 7362 (https://tools.ietf.org/html/rfc7362)] is implemented in [RFC7362] is implemented in the service provider network. This node
the service provider network. This node is a Boolean type, a value is a Boolean type, a value of 1/true indicates that the service
of 1/true indicates that the service provider expects the enterprise provider expects the enterprise network to use symmetric RTP, whereas
network to use symmetric RTP, whereas a value of 0/false indicates a value of 0/false indicates that the enterprise network can use
that the enterprise network can use asymmetric RTP. asymmetric RTP.
*rtcp*: A container that encapsulates generic characteristics of RTCP *rtcp*: A container that encapsulates generic characteristics of RTCP
sessions between the enterprise and service provider network. This sessions between the enterprise and service provider network. This
node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf
nodes. nodes.
*RTCPFeedback*: A leaf node that indicates whether the SIP service *RTCPFeedback*: A leaf node that indicates whether the SIP service
provider supports the RTP profile extension for RTCP-based feedback provider supports the RTP profile extension for RTCP-based feedback
RFC 4585 (https://tools.ietf.org/html/rfc4585). Media sessions RFC 4585 (https://tools.ietf.org/html/rfc4585). Media sessions
spanning enterprise and service provider networks, are rarely made to spanning enterprise and service provider networks, are rarely made to
skipping to change at page 30, line 5 skipping to change at page 33, line 5
module to include information that further simplifies direct IP module to include information that further simplifies direct IP
peering. Such information could include: trunk group identifiers, peering. Such information could include: trunk group identifiers,
direct-inward-dial (DID) number ranges allocated to the enterprise, direct-inward-dial (DID) number ranges allocated to the enterprise,
customer/enterprise account numbers, service provider support customer/enterprise account numbers, service provider support
numbers, among others. Extension of the module can be achieved by numbers, among others. Extension of the module can be achieved by
importing the module defined in this draft. An example is provided importing the module defined in this draft. An example is provided
below: Consider a new YANG module "vendorA" specified for VendorA's below: Consider a new YANG module "vendorA" specified for VendorA's
enterprise SBC. The "vendorA-config" YANG module is configured as enterprise SBC. The "vendorA-config" YANG module is configured as
follows: follows:
module vendorA-config { module vendorA-config {
namespace "urn:ietf:params:xml:ns:yang:vendorA-config"; namespace "urn:ietf:params:xml:ns:yang:vendorA-config";
prefix "vendorA"; prefix "vendorA";
description description
"Data model for configuring VendorA Enterprise SBC"; "Data model for configuring VendorA Enterprise SBC";
revision 2020-05-06 { revision 2020-05-06 {
description "Initial revision of VendorA Enterprise SBC configuration data model"; description "Initial revision of VendorA Enterprise SBC
} configuration data model";
}
import ietf-peering { import ietf-peering {
prefix "peering"; prefix "peering";
} }
augment "/peering:peering-info" { augment "/peering:peering-info" {
container vendorAConfig { container vendorAConfig {
leaf vendorAConfigParam1 { leaf vendorAConfigParam1 {
type int32; type int32;
description "vendorA configuration parameter 1 (SBC Device ID)"; description "vendorA configuration parameter 1
} (SBC Device ID)";
}
leaf vendorAConfigParam2 { leaf vendorAConfigParam2 {
type string; type string;
description "vendorA configuration parameter 2 (SBC Device name)"; description "vendorA configuration parameter 2
} (SBC Device name)";
description "Container for vendorA SBC configuration"; }
} description "Container for vendorA SBC configuration";
} }
} }
}
In the example above, a custom module named "vendorA-config" uses the In the example above, a custom module named "vendorA-config" uses the
"augment" statement as defined in Section 4.2.8 of [RFC 7950 "augment" statement as defined in Section 4.2.8 of [RFC7950] to
(https://tools.ietf.org/html/rfc7950)] to extend the module defined extend the module defined in this draft.
in this draft.
8. Processing the Capability Set Response 8. Processing the Capability Set Response
This section provides a non-normative description of the procedures This section provides a non-normative description of the procedures
that could be carried out by the enterprise network after obtaining that could be carried out by the enterprise network after obtaining
the SIP service provider capability set. On obtaining the capability the SIP service provider capability set. On obtaining the capability
set, the enterprise edge element can parse the various fields within set, the enterprise edge element can parse the various fields within
the capability set and generate configuration blocks. For example, the capability set and generate configuration blocks. For example,
the configuration required to successfully register a SIP trunk with the configuration required to successfully register a SIP trunk with
the SIP registrar hosted in the service provider network, the the SIP registrar hosted in the service provider network, the
skipping to change at page 31, line 25 skipping to change at page 34, line 27
document might be used to communicate the specific fields of capacity document might be used to communicate the specific fields of capacity
set and their corresponding value. Alternatively, a human set and their corresponding value. Alternatively, a human
administrator could go through the capability set document and administrator could go through the capability set document and
configure the edge element (and if required, other devices in the configure the edge element (and if required, other devices in the
enterprise network appropriately. enterprise network appropriately.
9. Examples 9. Examples
This section provides examples of how capability set documents that This section provides examples of how capability set documents that
leverage the YANG module defined in this document can be encoded over leverage the YANG module defined in this document can be encoded over
JSON or XML as well as the exchange of messages between the JSON as well as the exchange of messages between the enterprise edge
enterprise edge element and the service provider to acquire the element and the service provider to acquire the capability set
capability set document. document.
9.1. XML Capability Set Document 9.1. JSON Capability Set Document
<peering-info xmlns="urn:ietf:params:xml:ns:yang:ietf-peering" {
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" "peering-info": {
xsi:schemaLocation="urn:ietf:params:xml:ns:yang:ietf-peering ietf-peering.xsd"> "variant": "1.0",
<variant>1.0</variant> "revision": {
<transport-info> "notBefore": "2021-10-16T00:00:00.00000Z",
<transport>TCP;TLS;UDP</transport> "location":
<registrar>registrar1.voip.example.com:5060</registrar> "https://capserver.ssp1.com/capserver/capdoc.json",
<registrar>registrar2.voip.example.com:5060</registrar> },
<registrarRealm>voip.example.com</registrarRealm> "transport-info": {
<callControl>callServer1.voip.example.com:5060</callControl> "transport": "TCP;TLS;UDP",
<callControl>192.168.12.25:5065</callControl> "registrar": ["registrar1.voip.example.com:5060",
<dns>8.8.8.8</dns> "registrar2.voip.example.com:5060"],
<dns>208.67.222.222</dns> "registerRealm": "voip.example.com",
<outboundProxy>0.0.0.0</outboundProxy> "callControl": ["callServer1.voip.example.com:5060",
</transport-info> "192.168.12.25:5065"],
<call-specs> "dns": ["8.8.8.8", "208.67.222.222"],
<earlyMedia>true</earlyMedia> "outboundProxy": "0.0.0.0"
<signalingForking>false</signalingForking> },
<supportedMethods>INVITE;OPTIONS;BYE;CANCEL;ACK;PRACK;SUBSCRIBE;NOTIFY;REGISTER</supportedMethods> "call-specs": {
<numRange> "earlyMedia": "true",
<type>range</type> "signalingForking": "false",
<count>20</count> "supportedMethods": "INVITE;OPTIONS;BYE;CANCEL;ACK;
<value>19725455000</value> PRACK;SUBSCRIBE;NOTIFY;REGISTER",
</numRange> "callerId": {
<numRange> "e164Format": "true",
<type>block</type> "preferredMethod": "P-Asserted-Identity"
<count>2</count> },
<value>1972546000</value> "numRange": {
<value>1972546001</value> "type": "range",
</numRange> "count": "20",
</call-specs> "value": "19725455000"
<media> },
<mediaTypeAudio> "numRange": {
<mediaFormat>PCMU;rate=8000;ptime=20</mediaFormat> "type": "block",
<mediaFormat> G729;rate=8000;annexb=yes</mediaFormat> "count": "2",
<mediaFormat>G722;rate=8000;bitrate=56k,64k</mediaFormat> "value": ["19725455000", "19725455001"]
</mediaTypeAudio> }
<fax> },
<protocol>pass-through</protocol> "media": {
<protocol>t38</protocol> "mediaTypeAudio": {
</fax> "mediaFormat": ["PCMU;rate=8000;ptime=20",
<rtp> "G729;rate=8000;annexb=yes",
<RTPTrigger>true</RTPTrigger> "G722;rate=8000;bitrate=56k,64k"]
<symmetricRTP>true</symmetricRTP> },
</rtp> "fax": {
<rtcp> "protocol": ["t38", "pass-through"]
<symmetricRTCP>true</symmetricRTCP> },
<RTCPFeedback>true</RTCPFeedback> "rtp": {
</rtcp> "RTPTrigger": "true",
</media> "symmetricRTP": "true"
<dtmf> },
<payloadNumber>101</payloadNumber> "rtcp": {
<iteration>0</iteration> "symmetricRTCP": "true",
</dtmf> "RTCPFeedback": "true"
<security> }
<signaling> },
<type>TLS</type> "dtmf": {
<version>1.0;1.2</version> "payloadNumber": "101",
</signaling> "iteration": "0"
<mediaSecurity> },
<keyManagement>SDES;DTLS-SRTP,version=1.2</keyManagement> "security": {
</mediaSecurity> "signaling": {
<certLocation>https://sipserviceprovider.com/certificateList.pem</certLocation> "type": "TLS",
<secureTelephonyIdentity> "version": "1.0;1.2"
<STIRCompliance>true</STIRCompliance> },
<certDelegation>true</certDelegation> "mediaSecurity": {
<ACMEDirectory>https://sipserviceprovider.com/acme.html</ACMEDirectory> "keyManagement": "SDES;DTLS-SRTP,version=1.2"
</secureTelephonyIdentity>
</security> },
<extensions>timer;rel100;gin;path</extensions> "certLocation":
</peering-response> "https://sipserviceprovider.com/certificateList.pem",
"secureTelephonyIdentity": {
"STIRCompliance": "true",
"certDelegation": "true",
"ACMEDirectory":
"https://sipserviceprovider.com/acme.html"
}
},
"extensions": "timer;rel100;gin;path"
}
}
9.2. Example Exchange 9.2. Example Exchange
This section depicts an example of the configuration flow that This section is an informational example depicting the configuration
ultimately results in the enterprise edge element obtaining the flow that ultimately results in the enterprise edge element obtaining
capability set document from the SIP service provider. Assuming the the capability set document from the SIP service provider. Assuming
enterprise edge element has been pre-configured with the request the enterprise edge element has been pre-configured with the request
target for the capability set document or has dynamically found the target for the capability set document or has dynamically found the
request target, the edge element generates a HTTPS GET request. This request target, the edge element generates a HTTPS GET request. This
request can be challenged by the service provider to authenticate the request can be challenged by the service provider to authenticate the
enterprise. enterprise.
GET /capdoc?trunkid=trunkent1456 HTTP/1.1 GET /capdoc?trunkid=trunkent1456 HTTP/1.1
Host: capserver.ssp1.com Host: capserver.ssp1.com
Accept:application/peering-info+xml Accept:application/peering-info+json
The capability set document is obtained in the body of the response The capability set document is obtained in the body of the response
and is encoded in XML. and is encoded in JSON.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/peering-info+xml Content-Type: application/peering-info+json
Content-Length: nnn Content-Length: nnn
<peering-info> {
… "peering-info": ...
</peering-info> }
10. Security Considerations 10. Security Considerations
[TBD] [TBD]
11. Acknowledgments 11. Acknowledgments
[TBD] [TBD]
12. Normative References 12. Normative References
skipping to change at page 35, line 13 skipping to change at page 38, line 26
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>. 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/info/rfc7092>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", Traversal (HNT) for Media in Real-Time Communication",
RFC 7362, DOI 10.17487/RFC7362, September 2014, RFC 7362, DOI 10.17487/RFC7362, September 2014,
<https://www.rfc-editor.org/info/rfc7362>. <https://www.rfc-editor.org/info/rfc7362>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[SIP-Connect-TR]
"SIP Connect Technical Recommendation",
<https://www.sipforum.org/download/sipconnect-technical-
recommendation-version-2-0/?wpdmdl=2818>.
Authors' Addresses Authors' Addresses
Kaustubh Inamdar Kaustubh Inamdar
Unaffiliated Unaffiliated
Email: kaustubh.ietf@gmail.com Email: kaustubh.ietf@gmail.com
Sreekanth Narayanan Sreekanth Narayanan
Cisco Systems Cisco Systems
 End of changes. 83 change blocks. 
522 lines changed or deleted 714 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/