draft-ietf-asap-sip-auto-peer-00.txt   draft-ietf-asap-sip-auto-peer-01.txt 
ASAP K. Inamdar ASAP K. Inamdar
Internet-Draft S. Narayanan Internet-Draft Unaffiliated
Expires: October 3, 2021 C. Jennings Intended status: Standards Track .S. Narayanan
Expires: 9 December 2021 C. Jennings
Cisco Systems Cisco Systems
April 1, 2021 7 June 2021
Automatic Peering for SIP Trunks Automatic Peering for SIP Trunks
draft-ietf-asap-sip-auto-peer-00 draft-ietf-asap-sip-auto-peer-01
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 37 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 October 3, 2021. This Internet-Draft will expire on 9 December 2021.
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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 4
3. Reference Architecture . . . . . . . . . . . . . . . . . . . 3 2.1. Reference Architecture . . . . . . . . . . . . . . . . . 4
4. Configuration Workflow . . . . . . . . . . . . . . . . . . . 5 2.2. Configuration Workflow . . . . . . . . . . . . . . . . . 5
5. Overview of Operations . . . . . . . . . . . . . . . . . . . 6 2.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 7
6. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 8
6.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8 4. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8 4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Authenticated Client Identity . . . . . . . . . . . . . . 8 4.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8
6.4. Encoding the Request . . . . . . . . . . . . . . . . . . 8 4.3. Authenticated Client Identity . . . . . . . . . . . . . . 9
6.5. Generating the response . . . . . . . . . . . . . . . . . 9 4.4. Encoding the Request . . . . . . . . . . . . . . . . . . 9
6.6. Identifying the Request Target . . . . . . . . . . . . . 9 4.5. Identifying the Request Target . . . . . . . . . . . . . 9
7. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Generating the response . . . . . . . . . . . . . . . . . 10
8. Encoding the Service Provider Capability Set . . . . . . . . 10 5. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Data Model for Capability Set . . . . . . . . . . . . . . . . 10 6. Encoding the Service Provider Capability Set . . . . . . . . 11
9.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 7. Data Model for Capability Set . . . . . . . . . . . . . . . . 12
9.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12
9.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 17 7.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 14
9.4. Extending the Capability Set . . . . . . . . . . . . . . 24 7.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 20
10. Example Capability Set Document Encoding . . . . . . . . . . 25 7.4. Extending the Capability Set . . . . . . . . . . . . . . 29
10.1. XML Capability Set Document . . . . . . . . . . . . . . 26 8. Processing the Capability Set Response . . . . . . . . . . . 30
11. Example Exchange . . . . . . . . . . . . . . . . . . . . . . 27 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9.1. XML Capability Set Document . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Example Exchange . . . . . . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Normative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The deployment of a Session Initiation Protocol [RFC 3261 [1]] (SIP)- The deployment of a Session Initiation Protocol [RFC 3261
based infrastructure in enterprise and service provider communication (https://tools.ietf.org/html/rfc3261)] (SIP)-based infrastructure in
networks is increasing at a rapid pace. Consequently, direct IP enterprise and service provider communication networks is increasing
peering between enterprise and service provider networks is quickly at a rapid pace. Consequently, direct IP peering between enterprise
replacing traditional methods of interconnection between enterprise and service provider networks is quickly replacing traditional
and service provider networks. Currently published standards provide methods of interconnection between enterprise and service provider
a strong foundation over which direct IP peering can be realized. networks. Currently published standards provide a strong foundation
However, given the sheer number of these standards, it is often not over which direct IP peering can be realized. However, given the
clear which behavioral subsets, extensions to baseline protocols and sheer number of these standards, it is often not clear which
operating principles ought to be implemented by service provider and behavioral subsets, extensions to baseline protocols and operating
enterprise networks to ensure successful peering. principles ought to be implemented by service provider and enterprise
networks to ensure successful peering.
The SIP Connect technical recommendations [2] aim to solve this The SIP Connect technical recommendations
problem by providing a master reference that promotes seamless (https://www.sipforum.org/download/sipconnect-technical-
peering between enterprise and service provider SIP networks. recommendation-version-2-0/?wpdmdl=2818) aim to solve this problem by
However, despite the extensive set of implementation rules and providing a master reference that promotes seamless peering between
operating guidelines, interoperability issues between service enterprise and service provider SIP networks. However, despite the
provider and enterprise networks persist. This is in large part extensive set of implementation rules and operating guidelines,
because service providers and equipment manufacturers aren't required interoperability issues between service provider and enterprise
to enforce the guidelines of the technical specifications and have a networks persist. This is in large part because service providers
fair degree of freedom to deviate from them. Consequently, and equipment manufacturers aren't required to enforce the guidelines
enterprise administrators usually undertake a fairly rigorous regimen of the technical specifications and have a fair degree of freedom to
of testing, analysis and troubleshooting to arrive at a configuration deviate from them. Consequently, enterprise administrators usually
block that ensures seamless service provider peering. However, this undertake a fairly rigorous regimen of testing, analysis and
workflow complements the SIP Connect technical recommendations, in troubleshooting to arrive at a configuration block that ensures
that both endeavours aim to promote/achieve interop between the seamless service provider peering. However, this workflow
enterprise and service provider. 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 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
can solicit a detailed capability set from a SIP service provider; can solicit a detailed capability set from a SIP service provider;
the detailed capability set can subsequently be used by automaton or the detailed capability set can subsequently be used by automaton or
an administrator to generate configuration blocks across one or more an administrator to generate configuration blocks across one or more
devices within the enterprise to ensure successful service provider devices within the enterprise to ensure successful service provider
peering. peering.
2. Conventions and Terminology 2. Overview of Operations
The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL This section details the configuration workflow proposed by this
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in draft.
this document are to be interpreted as described in RFC 2119 [3]
3. 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 [4]]. It may also include additional components Controller [RFC 7092 (https://tools.ietf.org/html/rfc7092)]. It may
such as application servers for voicemail, recording, fax etc. At a also include additional components such as application servers for
high level, the service provider consists of a SIP signaling entity voicemail, recording, fax etc. At a high level, the service provider
(SP-SSE), a media entity and a HTTPS [RFC 7231 [5]] server. consists of a SIP signaling entity (SP-SSE), a media entity and a
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 4, line 32 skipping to change at page 4, line 48
| | | Media |<-|---------|-->+-------+ | | | | | Media |<-|---------|-->+-------+ | |
| | +----------+ | | | | | | +----------+ | | | |
| +---------------+ +-----------------------+ | | +---------------+ +-----------------------+ |
| | | |
+-----------------------------------------------------+ +-----------------------------------------------------+
Figure 1: Reference Architecture Figure 1: Reference Architecture
This draft makes use of the following terminology: This draft makes use of the following terminology:
o 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.
o 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 [6]] such as a Session Border back user agent (B2BUA) [RFC 7092 (https://tools.ietf.org/html/
Controller (SBC). rfc7092)] such as a Session Border Controller (SBC).
o 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.
o Call Control: Call Control within a telephony networks refers to * Call Control: Call Control within a telephony networks refers to
software that is responsible for delivering its core software that is responsible for delivering its core
functionality. Call control not only provides the basic functionality. Call control not only provides the basic
functionality of setting up, sustaining and terminating calls, but functionality of setting up, sustaining and terminating calls, but
also provides the necessary control and logic required for also provides the necessary control and logic required for
additional services within the telephony network. additional services within the telephony network.
o Capability Server: A server hosted in the service provider * Capability Server: A server hosted in the service provider
network, such that this server is the target for capability set network, such that this server is the target for capability set
document requests from the enterprise network. document requests from the enterprise network.
o Capability Set: This specification uses the term capability set * Capability Set: The term capability set (or capability set
(or capability set document) to refer collectivity to a set of document) refers collectively to a set of characteristics within
characteristics within the service provider network, which when the service provider network, which when communicated to the
communicated to the enterprise network, provides the enterprise enterprise network, provides the enterprise network the
network the information required to interconnect with the service information required to interconnect with the service provider
provider network. The various parameters that constitute the network. The various parameters that constitute the capability
capability set relate to characteristics that are specific to set relate to characteristics that are specific to signalling,
signalling, media, transport and security. Certain aspects of media, transport and security. Certain aspects of interconnecting
interconnecting with service providers are out of scope of the with service providers are out of scope of the capability set.
capability set. For example, the access technology used to For example, the access technology used to interconnect with
interconnect with service provider networks. service provider networks.
4. Configuration Workflow 2.2. Configuration Workflow
A workflow that facilitates an enterprise network to solicit the A workflow that facilitates an enterprise network to solicit the
capability set of a SIP service provider ought to take into account capability set of a SIP service provider ought to take into account
the following considerations: the following considerations:
o The configuration workflow must be based on a protocol or a set of * The configuration workflow must be based on a protocol or a set of
protocols commonly used between enterprise and service provider protocols commonly used between enterprise and service provider
telephony networks. telephony networks.
o The configuration workflow must be flexible enough to allow the * The configuration workflow must be flexible enough to allow the
service provider network to dynamically offload different service provider network to dynamically offload different
capability sets to different enterprise networks based on the capability sets to different enterprise networks based on the
identity of the enterprise network. identity of the enterprise network.
o Capability set documents obtained as a result of the configuration * Capability set documents obtained as a result of the configuration
workflow must be conducive to easy parsing by automaton. workflow must be conducive to easy parsing by automaton.
Subsequently, automaton may be used for generation of appropriate Subsequently, automaton may be used for generation of appropriate
configuration blocks. configuration blocks.
Taking the above considerations into account, this document proposes Taking the above considerations into account, this document proposes
a Hypertext Transfer Protocol (HTTP)-based workflow using which the a Hypertext Transfer Protocol (HTTP)-based workflow using which the
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 [RFC
6665 [7]], such that the enterprise network can establish a SIP 6665 (https://tools.ietf.org/html/rfc6665)], such that the enterprise
subscription with the service provider for its capability set; the network can establish a SIP subscription with the service provider
SIP service provider can subsequently use the SIP NOTIFY request to for its capability set; the SIP service provider can subsequently use
communicate its capability set or any state deltas to its baseline the SIP NOTIFY request to communicate its capability set or any state
capability set. deltas to its baseline 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 [8]] that enable configuration to be pushed over models [RFC 6020 (https://tools.ietf.org/html/rfc6020)] that enable
NETCONF [RFC 6241 [9]] to enterprise networks from a centralised configuration to be pushed over NETCONF [RFC 6241
source hosted in service provider networks. The presence of (https://tools.ietf.org/html/rfc6241)] to enterprise networks from a
proprietary software logic for call and media handling in enterprise centralised source hosted in service provider networks. The presence
devices would preclude the generation of a "one-size-fits-all" YANG of proprietary software logic for call and media handling in
model. Additionally, service provider networks pushing configuration enterprise devices would preclude the generation of a "one-size-fits-
to enterprises devices might lead to the loss of implementation all" YANG model. Additionally, service provider networks pushing
autonomy on the part of the enterprise network. configuration to enterprises devices might lead to the loss of
implementation autonomy on the part of the enterprise network.
5. Overview of Operations 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
signaling planes. As a result, when the capability set is signaling planes. As a result, when the capability set is
received from the SIP service provider network, the edge element received from the SIP service provider network, the edge element
can generate appropriate configuration blocks (possibly across can generate appropriate configuration blocks (possibly across
multiple devices) to enable interconnection. multiple devices) to enable interconnection.
2. Given that edge elements are configured to "talk" to networks 2. Given that edge elements are configured to "talk" to networks
external to the enterprise, the complexity in terms of NAT external to the enterprise, the complexity in terms of NAT
skipping to change at page 7, line 25 skipping to change at page 7, line 38
The HTTPS GET request is targeted at a capability server that is The HTTPS GET request is targeted at a capability server that is
managed by the SIP service provider such that this server processes, managed by the SIP service provider such that this server processes,
and on successfully processing the request, includes the capability and on successfully processing the request, includes the capability
set document in the response. The capability set document is set document in the response. The capability set document is
constructed according the guidelines of the YANG model described in constructed according the guidelines of the YANG model described in
this draft. The capability set document included in a successful this draft. The capability set document included in a successful
response is formatted in either XML or JSON. The formatting depends response is formatted in either XML or JSON. The formatting depends
on the value of the "Accept" header field of the HTTP GET request. on the value of the "Accept" header field of the HTTP GET request.
More details about the formatting of the HTTP request and response More details about the formatting of the HTTP request and response
are provided in Section 6. are provided in Section 4.
There could be situations wherein an enterprise telephony network There could be situations wherein an enterprise telephony network
interconnects with its SIP service provider such that traffic between interconnects with its SIP service provider such that traffic between
the two networks traverses an intermediary SIP service provider the two networks traverses an intermediary SIP service provider
network. This could be a result of interconnect agreements between network. This could be a result of interconnect agreements between
the terminating and transit SIP service provider networks. In such the terminating and transit SIP service provider networks. In such
situations, the capability set provided to the enterprise network by situations, the capability set provided to the enterprise network by
its SIP service provider must account for the characteristics of the its SIP service provider must account for the characteristics of the
transit SIP service provider network from a signalling and media transit SIP service provider network from a signalling and media
perspective. For example, if the terminating SIP service provider perspective. For example, if the terminating SIP service provider
skipping to change at page 7, line 50 skipping to change at page 8, line 15
Reliable Provisional Responses as defined in RFC 3262, the Reliable Provisional Responses as defined in RFC 3262, the
terminating SIP service provider network must not advertise support terminating SIP service provider network must not advertise support
for this extension in the capability set provided to the enterprise for this extension in the capability set provided to the enterprise
network. How a terminating SIP service provider obtains the network. How a terminating SIP service provider obtains the
characteristics of the intermediary SIP service provider network is characteristics of the intermediary SIP service provider network is
out of the scope of this document; however, one method could be for out of the scope of this document; however, one method could be for
the terminating SIP service provider to obtain the characteristics of the terminating SIP service provider to obtain the characteristics of
the intermediary SIP service provider by leveraging the YANG model the intermediary SIP service provider by leveraging the YANG model
introduced in this document. introduced in this document.
Figure 1 provides a reference architecture in which this workflow may 3. Conventions and Terminology
be implemented. The architecture depicted in Figure 1 consists of an
enterprise telephony network and a SIP service provider network, such
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 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 BCP 14
(https://www.rfc-editor.org/refs/ref-bcp14.txt)
4. HTTP Transport
This section describes the use of HTTPS as a transport protocol for This section describes the use of HTTPS as a transport protocol for
the peering workflow. This workflow is based on HTTP version 1.1, 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 and as such is compatible with any future version of HTTP that is
backward compatible with HTTP 1.1. backward compatible with HTTP 1.1.
6.1. HTTP Methods 4.1. HTTP Methods
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. The HTTPS POST obtain the service provider capability set document.
method and its corresponding response(s) is also used for client
authentication.
6.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 [10]]. The enterprise edge element and capability server [RFC 5246 (https://tools.ietf.org/html/rfc5246)]. The enterprise
MUST be compliant with RFC 7235 [11]. The enterprise edge element edge element and capability server MUST be compliant with RFC 7235
and capability server MUST support the use of the https uri scheme as (https://tools.ietf.org/html/rfc7235). The enterprise edge element
defined in RFC 7230 [12]. and capability server MUST support the use of the HTTPS uri scheme as
defined in RFC 7230 (https://tools.ietf.org/html/rfc7230).
6.3. Authenticated Client Identity 4.3. Authenticated Client Identity
It is only required for the SIP service provider to authenticate the It is only required for the SIP service provider to authenticate the
client (enterprise edge element). How the SIP service provider client (enterprise edge element). How the SIP service provider
authenticates the client is out of the scope of this document, authenticates the client is out of the scope of this document,
however, methods such as HTTP Digest Authentication may be used. however, methods such as HTTP Digest Authentication or validation of
the hostname presented in the certificate during the TLS exchange may
be used.
6.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
JSON and XML. In such situations, the edge element might generate a JSON and XML. In such situations, the edge element might generate a
HTTPS GET request such that the Accept header field includes both HTTPS GET request such that the Accept header field includes both
MIME types along with the corresponding "qvalue" for each MIME type. MIME types along with the corresponding "qvalue" for each MIME type.
The generated HTTPS GET request must not use the "Expect" and "Range" The generated HTTPS GET request MUST NOT use the "Expect" and "Range"
header fields. The requests must also not use any conditional header fields. The requests MUST also not use any conditional
request. request.
6.5. Generating the response 4.5. 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 using the Webfinger Protocol
The complete HTTPS URLs to be used when authenticating the enterprise
edge element (optional) and obtaining the SIP service provider
capability set can be obtained from the SIP service provider
beforehand and entered into the edge element manually via some
interface - for example, a CLI or GUI.
However, if the resource URL is unknown to the administrator (and by
extension of that to the edge element), the WebFinger protocol RFC
7033 (https://tools.ietf.org/html/rfc5764) may be leveraged.
If an enterprise edge element attempts to discover the URL of the
endpoints hosted in the ssp1.example.com domain, it issues the
following request (line wraps are for display purposes only).
GET /.well-known/webfinger?
resource=http%3A%2F%2Fssp1.example.com
rel=capabilitySet
HTTP/1.1
Host: ssp1.example.com
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
"subject" : "http://ssp1.example.com",
"links" :
[
{
"rel" : "capabilitySet",
"href" :"https://capserver.ssp1.com/capserver/capdoc.xml"
},
]
}
Once the target URI is obtained by an enterprise telephony network,
the URI may be dereferenced to obtain a unique capability set
document that is specific to that given enterprise telephony network.
The ITSP may use credentials to determine the identity of the
enterprise telephony network and provide the appropriate capability
set document.
TODO: Should we have a new link-relation type registered for ASAP?
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 9, line 35 skipping to change at page 11, line 18
1. 301 Moved Temporarily 1. 301 Moved Temporarily
2. 302 Found 2. 302 Found
3. 307 Temporary Redirect 3. 307 Temporary Redirect
The server SHOULD include the Location header field in such The server SHOULD include the Location header field in such
responses. responses.
6.6. Identifying the Request Target 5. State Deltas
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. 1. Manual Configuration
2. 2. Discovery [TBD]
7. State Deltas
Given that the service provider capability set is largely expected to Given that the service provider capability set is largely expected to
remain static, the work needed to implement an asynchronous push remain static, the work needed to implement an asynchronous push
mechanism to encode minor changes in the capability set document mechanism to encode minor changes in the capability set document
(state deltas) is not commensurate with the benefits. Rather, (state deltas) is not commensurate with the benefits. Rather,
enterprise edge elements can poll capability servers at pre-defined enterprise edge elements can poll capability servers at pre-defined
intervals to obtain the full capability set document. It is intervals to obtain the full capability set document. It is
recommended that capability servers are polled every 24 hours. recommended that capability servers are polled every 24 hours.
8. Encoding the Service Provider Capability Set 6. Encoding the Service Provider Capability Set
In the context of this draft, the capability set of a service In the context of this draft, the capability set of a service
provider refers collectively to a set of characteristics which when provider refers collectively to a set of characteristics which when
communicated to an enterprise network, provides it with sufficient communicated to an enterprise network, provides it with sufficient
information to directly peer with the service provider network. The information to directly peer with the service provider network. The
capability set document is not designed to encode extremely granular capability set document is not designed to encode extremely granular
details of all features, services, and protocol extensions that are details of all features, services, and protocol extensions that are
supported by the service provider network. For example, it is supported by the service provider network. For example, it is
sufficient to encode that the service provider uses T.38 relay for sufficient to encode that the service provider uses T.38 relay for
faxing, it is not required to know the value of the faxing, it is not required to know the value of the
"T38FaxFillBitRemoval" parameter. "T38FaxFillBitRemoval" parameter.
The parameters within the capability set document represent a wide The parameters within the capability set document represent a wide
array of characteristics, such that these characteristics array of characteristics, such that these characteristics
collectively disseminate sufficient information to enable direct IP collectively disseminate sufficient information to enable direct IP
peering between enterprise and service provider networks. The peering between enterprise and service provider networks. The
various parameters represented in the capability set are chosen based various parameters represented in the capability set are chosen based
on existing practises and common problem sets typically seen between on existing practises and common problem sets typically seen between
enterprise and service provider SIP networks. enterprise and service provider SIP networks.
9. 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.
9.1. Tree Diagram 7.1. Tree Diagram
This section provides a tree diagram [RFC 8340 [13]] for the "ietf- This section provides a tree diagram [RFC 8340
capability-set" module. The interpretation of the symbols appearing (https://tools.ietf.org/html/rfc8340)] for the "ietf-capability-set"
in the tree diagram is as follows: module. The interpretation of the symbols appearing in the tree
diagram is as follows:
o Brackets "[" and "]" enclose list keys. * Brackets "[" and "]" enclose list keys.
o 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).
o 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.
o Parentheses enclose choice and case nodes, and case nodes are also * Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o 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:
+--rw peering-response +--rw peering-response
+--rw variant string +--rw variant 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 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
| | +--rw RTPTrigger? boolean | | +--rw RTPTrigger? boolean
| | +--rw symmetricRTP? boolean | | +--rw symmetricRTP? boolean
| +--rw rtcp | +--rw rtcp
| +--rw symmetricRTCP? boolean | +--rw symmetricRTCP? boolean
| +--rw RTCPfeedback? boolean | +--rw RTCPfeedback? boolean
+--rw dtmf +--rw dtmf
| +--rw payloadNumber? int8 | +--rw payloadNumber? int8
| +--rw iteration? boolean | +--rw iteration? boolean
+--rw security +--rw security
| +--rw signaling | +--rw signaling
| +--rw type* string | +--rw type* string
| +--rw version* string | +--rw version* string
| +--rw mediaSecurity | +--rw mediaSecurity
| +--rw keyManagement? string | +--rw keyManagement? string
| +--rw certLocation string | +--rw certLocation string
+--rw extensions? string | +--rw secureTelephonyIdentity
| +--rw STIRCompliance boolean
| +--rw certDelegation boolean
| +--rw ACMEDirectory string
+--rw extensions? string
9.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 [14]]. from [RFC 6991 (https://tools.ietf.org/html/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 Enterprise"; "Data model for transmitting peering parameters from SP to 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])\.){3}' 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])' + "([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])$'; + ":^()([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 description "The ipv4-address-port type represents an IPv4 address in
dotted-quad notation followed by a port number."; dotted-quad notation followed by a port number.";
} }
typedef ipv6-address-port { typedef ipv6-address-port {
type string { type string {
pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 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}))|' + "((([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])\.){3}"
+ '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + "(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])$'; + ":^()([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 pattern
'(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' "(([^:]+:){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])$'; + ":^()([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 description
"The ipv6-address type represents an IPv6 address in full, "The ipv6-address type represents an IPv6 address in full,
mixed, shortened, and shortened-mixed notation followed by a port number."; mixed, shortened, and shortened-mixed notation followed by a port
number.";
} }
typedef ip-address-port { typedef ip-address-port {
type union { type union {
type ipv4-address-port; type ipv4-address-port;
type ipv6-address-port; type ipv6-address-port;
} }
description description
"The ip-address-port type represents an IP address:port number "The ip-address-port type represents an IP address:port number
and is IP version neutral."; and is IP version neutral.";
} }
skipping to change at page 13, line 17 skipping to change at page 15, line 21
type ipv6-address-port; type ipv6-address-port;
} }
description description
"The ip-address-port type represents an IP address:port number "The ip-address-port type represents an IP address:port number
and is IP version neutral."; and is IP version neutral.";
} }
typedef domain-name-port { typedef domain-name-port {
type string { type string {
pattern 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]\.)*"
+ '([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])$'; + ":^()([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"; length "1..258";
} }
description description
"The domain-name-port type represents a DNS domain name followed by a port number. "The domain-name-port type represents a DNS domain name followed by a
The name SHOULD be fully qualified whenever possible."; port number. The name SHOULD be fully qualified whenever possible.";
} }
typedef host-port { typedef host-port {
type union { type union {
type ip-address-port; type ip-address-port;
type domain-name-port; type domain-name-port;
} }
description description
"The host type represents either an IP address or a DNS "The host type represents either an IP address or a DNS
domain name followed by a port number."; domain name followed by a port number.";
skipping to change at page 14, line 30 skipping to change at page 16, line 35
leaf-list callControl { leaf-list callControl {
type host-port; type host-port;
max-elements 3; max-elements 3;
description "List of service provider call control servers"; description "List of service provider call control servers";
} }
leaf-list dns { leaf-list dns {
type inet:ip-address; type inet:ip-address;
max-elements 2; max-elements 2;
description "IP address of the DNS Server(s) hosted by the service provider"; description "IP address of the DNS Server(s) hosted by the service
provider";
} }
leaf outboundProxy { leaf outboundProxy {
type host-port; type host-port;
description "SIP Outbound Proxy"; description "SIP Outbound Proxy";
} }
} }
container call-specs { container call-specs {
leaf earlyMedia { leaf earlyMedia {
skipping to change at page 14, line 45 skipping to change at page 17, line 4
description "SIP Outbound Proxy"; description "SIP Outbound Proxy";
} }
} }
container call-specs { container call-specs {
leaf earlyMedia { leaf earlyMedia {
type boolean; type boolean;
description "Flag indicating whether the service provider is expected description "Flag indicating whether the service provider is expected
to deliver early media."; to deliver early media.";
} }
leaf signalingForking { leaf signalingForking {
type boolean; type boolean;
description "Flag indicating whether the service provider is capable description "Flag indicating whether the service provider is capable
of forking incoming calls "; of forking incoming calls ";
} }
leaf supportedMethods { leaf supportedMethods {
type string; type string;
description "Leaf/Leaf List indicating the different SIP methods description "Leaf/Leaf List indicating the different SIP methods
support by the service provider."; support by the service provider.";
} }
container numRange { container numRange {
leaf numRangeType { leaf numRangeType {
type string; type string;
description "String indicating whether the DID number range is passed description "String indicating whether the DID number range is
by value or by reference" passed by value or by reference"
} }
leaf count { leaf count {
when "../numRangeType = 'range' or ../numRangeType = 'block'"; when "../numRangeType = 'range' or ../numRangeType = 'block'";
type int32; type int32;
description "Number of DID numbers present in the number range." description "Number of DID numbers present in the number range."
} }
leaf-list value { leaf-list value {
type string; type string;
skipping to change at page 17, line 21 skipping to change at page 19, line 28
type string { type string {
pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)"; pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)";
} }
description "Indicates TLS version for SIP signaling"; description "Indicates TLS version for SIP signaling";
} }
} }
container mediaSecurity { container mediaSecurity {
leaf keyManagement { leaf keyManagement {
type string { 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)"; 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 description "Leaf that identifies the key management methods
supported by the service provider for SRTP."; supported by the service provider for SRTP.";
} }
} }
leaf certLocation { leaf certLocation {
type string; type string;
description "Location of the service provider certificate chain for SIP over TLS."; 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 { leaf extensions {
type string; type string;
description "Lists the various SIP extensions supported by SP"; description "Lists the various SIP extensions supported by SP";
} }
} }
} }
9.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 XML schema.
*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;
skipping to change at page 19, line 42 skipping to change at page 22, line 27
of the outbound calls. This element is a Boolean type, where a value 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 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 media. A value of 0/false signifies that the service provider is not
expected to generate early media. expected to generate early media.
*signalingForking*: A leaf that specifies whether outbound call *signalingForking*: A leaf that specifies whether outbound call
requests from the enterprise might be forked on the service provider requests from the enterprise might be forked on the service provider
network that MAY lead to multiple early dialogs. This information network that MAY lead to multiple early dialogs. This information
would be useful to the enterprise network in appropriately handling would be useful to the enterprise network in appropriately handling
multiple early dialogs reliably and in enforcing local policy. This multiple early dialogs reliably and in enforcing local policy. This
element is a Boolen type, where a value of 1/true signifies that the element is a Boolean type, where a value of 1/true signifies that the
service provider network can potentially fork outbound call requests service provider network can potentially fork outbound call requests
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.
skipping to change at page 20, line 45 skipping to change at page 23, line 43
resource containing the DID number range. To ensure ease of parsing, resource containing the DID number range. To ensure ease of parsing,
it is RECOMMENDED that the resource contain a number range formatted it is RECOMMENDED that the resource contain a number range formatted
as if it were being passed as a block or range. as if it were being passed as a block or range.
*media*: A container that is used to collectively encapsulate the *media*: A container that is used to collectively encapsulate the
characteristics of UDP-based audio streams. A future extension to characteristics of UDP-based audio streams. A future extension to
this draft may extend the media container to describe other media this draft may extend the media container to describe other media
types. The media container is also used to encapsulate basic types. The media container is also used to encapsulate basic
information about Real-Time Transport Protocol (RTP) and Real-Time information about Real-Time Transport Protocol (RTP) and Real-Time
Transport Control Protocol (RTCP) from the perspective of the service Transport Control Protocol (RTCP) from the perspective of the service
provider network. provider network. As of the date of writing this draft, video media
streams aren't exchanged between enterprise and service provider SIP
networks.
*mediaTypeAudio*: A container for the mediaFormat leaf-list. This *mediaTypeAudio*: A container for the mediaFormat leaf-list. This
container collectively encapsulates the various audio media formats container collectively encapsulates the various audio media formats
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 [15]]. Given that the media format is registered [RFC 4855 (https://tools.ietf.org/html/
parameters of media formats can vary from one communication session rfc4855)]. Given that the parameters of media formats can vary from
to another, for example, across two separate communication sessions, one communication session to another, for example, across two
the packetization time (ptime) used for the PCMU media format might separate communication sessions, the packetization time (ptime) used
vary from 10 to 30 ms, the parameters included in the format element for the PCMU media format might vary from 10 to 30 ms, the parameters
must be the ones that are expected to be invariant from the included in the format element must be the ones that are expected to
perspective of the service provider. Providing information about be invariant from the perspective of the service provider. Providing
supported media formats and their respective parameters, allows information about supported media formats and their respective
enterprise networks to configure the media plane characteristics of parameters, allows enterprise networks to configure the media plane
various devices such as endpoints and middleboxes. The encoding characteristics of various devices such as endpoints and middleboxes.
name, one or more required parameters, one or more optional The encoding name, one or more required parameters, one or more
parameters are all separated by a semicolon. The formatting of a optional parameters are all separated by a semicolon. The formatting
given media format parameter, must follow the formatting rules as of a given media format parameter, must follow the formatting rules
specified for that media format. as specified for that 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 22, line 13 skipping to change at page 25, line 13
a value of 0/false indicates that the service provider network does a value of 0/false indicates that the service provider network does
not require the enterprise network to send the first media packet. not require the enterprise network to send the first media packet.
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 [16]. Uncovering this expectation is useful in defined in RFC 4961 (https://tools.ietf.org/html/rfc4961).
scenarios where "latching" [RFC 7362 [17]] is implemented in the Uncovering this expectation is useful in scenarios where "latching"
service provider network. This node is a Boolean type, a value of 1/ [RFC 7362 (https://tools.ietf.org/html/rfc7362)] is implemented in
true indicates that the service provider expects the enterprise 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 network to use symmetric RTP, whereas a value of 0/false indicates
that the enterprise network can use asymmetric RTP. that the enterprise network can use 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 [18]. Media sessions spanning enterprise and service RFC 4585 (https://tools.ietf.org/html/rfc4585). Media sessions
provider networks, are rarely made to flow directly between the spanning enterprise and service provider networks, are rarely made to
caller and callee, rather, it is often the case that media traffic flow directly between the caller and callee, rather, it is often the
flows through network intermediaries such as SBCs. As a result, RTCP case that media traffic flows through network intermediaries such as
traffic from the service provider network is intercepted by these SBCs. As a result, RTCP traffic from the service provider network is
intermediaries, which in turn can either pass across RTCP traffic intercepted by these intermediaries, which in turn can either pass
unmodified or modify RTCP traffic before it is forwarded to the across RTCP traffic unmodified or modify RTCP traffic before it is
endpoint in the enterprise network. Modification of RTCP traffic forwarded to the endpoint in the enterprise network. Modification of
would be required, for example, if the intermediary has performed RTCP traffic would be required, for example, if the intermediary has
media payload transformation operations such as transcoding or performed media payload transformation operations such as transcoding
transrating. In a similar vein, for the RTCP-based feedback or transrating. In a similar vein, for the RTCP-based feedback
mechanism as defined in RFC 4585 [19] to be truly effective, mechanism as defined in RFC 4585 (https://tools.ietf.org/html/
intermediaries must ensure that feedback messages are passed reliably rfc4585) to be truly effective, intermediaries must ensure that
and with the correct formatting to enterprise endpoints. This might feedback messages are passed reliably and with the correct formatting
require additional configuration and considerations that need to be to enterprise endpoints. This might require additional configuration
dealt with at the time of provisioning the intermediary device. This and considerations that need to be dealt with at the time of
node is a Boolean type, a value of 1/true indicates that the service provisioning the intermediary device. This node is a Boolean type, a
provider supports the RTP profile extension for RTP-based feedback value of 1/true indicates that the service provider supports the RTP
and a value of 0/false indicates that the service provider does not profile extension for RTP-based feedback and a value of 0/false
support the RTP profile extension for RTP-based feedback. 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 *symmetricRTCP*: A leaf node indicating whether the SIP service
provider expects the enterprise network to use symmetric RTCP as 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 defined in RFC 4961 (https://tools.ietf.org/html/rfc4961). This node
indicates that the service provider expects symmetric RTCP reports, is a Boolean type, a value of 1 indicates that the service provider
whereas a value of 0 indicates that the enterprise can use asymmetric expects symmetric RTCP reports, whereas a value of 0 indicates that
RTCP. the enterprise can use asymmetric RTCP.
*dtmf*: A container that describes the various aspects of DTMF relay *dtmf*: A container that describes the various aspects of DTMF relay
via RTP Named Telephony Events. The dtmf container allows SIP via RTP Named Telephony Events. The dtmf container allows SIP
service providers to specify two facets of DTMF relay via Named service providers to specify two facets of DTMF relay via Named
Telephony Events: Telephony Events:
1. The payload type number using the payloadNumber leaf node. 1. The payload type number using the payloadNumber leaf node.
2. Support for RFC 2833 [21] or RFC 4733 [22] using the iteration 2. Support for RFC 2833 (https://tools.ietf.org/html/rfc2833) or RFC
4733 (https://tools.ietf.org/html/rfc4733) using the iteration
leaf node. leaf node.
In the context of named telephony events, senders and receivers may In the context of named telephony events, senders and receivers may
negotiate asymmetric payload type numbers. For example, the sender negotiate asymmetric payload type numbers. For example, the sender
might advertise payload type number 97 and the receiver might might advertise payload type number 97 and the receiver might
advertise payload type number 101. In such instances, it is either advertise payload type number 101. In such instances, it is either
required for middleboxes to interwork payload type numbers or allow required for middleboxes to interwork payload type numbers or allow
the endpoints to send and receive asymmetric payload numbers. The the endpoints to send and receive asymmetric payload numbers. The
behaviour of middleboxes in this context is largely dependent on behaviour of middleboxes in this context is largely dependent on
endpoint capabilities or on service provider constraints. Therefore, endpoint capabilities or on service provider constraints. Therefore,
the payloadNumber leaf node can be used to determine middlebox the payloadNumber leaf node can be used to determine middlebox
configuration before-hand. configuration before-hand.
RFC 4733 [23] iterates over RFC 2833 [24] by introducing certain RFC 4733 (https://tools.ietf.org/html/rfc4733) iterates over RFC 2833
changes in the way NTE events are transmitted. SIP service providers (https://tools.ietf.org/html/rfc2833) by introducing certain changes
can indicate support for RFC 4733 [25] by setting the iteration flag in the way NTE events are transmitted. SIP service providers can
to 1 or indicating support for RFC 2833 [26] by setting the iteration indicate support for RFC 4733 (https://tools.ietf.org/html/rfc4733)
flag to 0. by setting the iteration flag to 1 or indicating support for RFC 2833
(https://tools.ietf.org/html/rfc2833) by setting the iteration flag
to 0.
*security*: A container that encapsulates characteristics about *security*: A container that encapsulates characteristics about
encrypting signalling streams between the enterprise and SIP service encrypting signalling streams between the enterprise and SIP service
provider networks. provider networks.
*signaling*: A container that encapsulates the type of security *signaling*: A container that encapsulates the type of security
protocol for the SIP communication between the enterprise SBC and the protocol for the SIP communication between the enterprise SBC and the
service provider. service provider.
*type*: A leaf node that specifies the protocol used for protecting *type*: A leaf node that specifies the protocol used for protecting
SIP signalling messages between the enterprise and service provider SIP signalling messages between the enterprise and service provider
network. The value of the type leaf node is only defined for network. The value of the type leaf node is only defined for
Transport Layer Security (TLS). Accordingly, if TLS is allowed for Transport Layer Security (TLS). Accordingly, if TLS is allowed for
SIP sessions between the enterprise and service provider network, the SIP sessions between the enterprise and service provider network, the
type leaf node is set to the string "tls". type leaf node is set to the string "tls".
*version*: A leaf node that specifies the version(s) of TLS supported *version*: A leaf node that specifies the version(s) of TLS supported
in decimal format. If multiple versions of TLS are supported, they in decimal format. If multiple versions of TLS are supported, they
should be separated by semi-colons. If the service provide does not should be separated by semi-colons. If the service provider does not
support TLS for protecting SIP sessions, the signalling element is support TLS for protecting SIP sessions, the signalling element is
set to the string "NULL". set to the string "NULL".
*mediaSecurity*: A container that describes the various *mediaSecurity*: A container that describes the various
characteristics of securing media streams between enterprise and characteristics of securing media streams between enterprise and
service provider networks. service provider networks.
*keyManagement*: A leaf node that specifies the key management method *keyManagement*: A leaf node that specifies the key management method
used by the service provider. Possible values of this node include: used by the service provider. Possible values of this node include:
"SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP "SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP
service provider uses the methods defined in RFC 4568 [27] for the service provider uses the methods defined in RFC 4568
purpose of key management. A value of "DTLS-SRTP" signifies that the (https://tools.ietf.org/html/rfc4568) for the purpose of key
SIP service provider uses the methods defined in RFC 5764 [28] for management. A value of "DTLS-SRTP" signifies that the SIP service
the purpose of key management. If the value of this leaf node is set provider uses the methods defined in RFC 5764
to "DTLS-SRTP", the various versions of DTLS supported by the SIP (https://tools.ietf.org/html/rfc5764) for the purpose of key
service provider MUST be encoded as per the formatting rules of management. If the value of this leaf node is set to "DTLS-SRTP",
Section 9.2. If the service provider does not support media the various versions of DTLS supported by the SIP service provider
security, the keyManagement node MUST be set to "NULL". 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 *certLocation:*: If the enterprise network is required to exchange
SIP traffic over TLS with the SIP service provider, and if the SIP SIP traffic over TLS with the SIP service provider, and if the SIP
service provider is capable of accepting TLS connections from the service provider is capable of accepting TLS connections from the
enterprise network, it may be required for the SIP service provider enterprise network, it may be required for the SIP service provider
certificates to be pre-installed on the enterprise edge element. In certificates to be pre-installed on the enterprise edge element. In
such situations, the certLocation leaf node is populated with a URL, such situations, the certLocation leaf node is populated with a URL,
which when dereferenced, provides a single PEM encoded file that which when dereferenced, provides a single PEM encoded file that
contains all certificates in the chain of trust. This is an optional contains all certificates in the chain of trust. This is an optional
leaf node. leaf node.
*secureTelephonyIdentity*: A container that is used to collectively
encapsulate Secure Telephony Identity Revisited (STIR)
characteristics.
*STIRCompliance*: A leaf node that indicates whether the SIP service
provider is STIR compliant. This node is a Boolean type, a value 1/
true indicates that the SIP service provider is STIR compliant. A
value of 0/false indicates that the SIP service provider is not STIR
compliant. A SIP service provider being STIR compliant has
implications for inbound and outbound calls, from the perspective of
the enterprise network.
For inbound calls received from a STIR compliant SIP service
provider, the enterprise edge element can be configured to
appropriately handle calls based on their "attestation value". For
example, calls with an attestation value of "A" (Full Attestation)
are allowed to go through, while calls with an attestation value of
"C" (Gateway Attestation) may be flagged for administrative analysis.
For outgoing calls placed to a STIR compliant SIP service provider,
the enterprise edge element must ensure that the calling number
populated in SIP From header field (or in trusted environments, the
P-Asserted-Identity header field), is as per what the service
provider expects. This is so that the Authentication Service running
in the SIP service provider network can determine if it is
authoritative for the calling number presented by the enterprise
network.
*certDelegation*: A leaf node value that indicates whether a SIP
service provider that allocates one or more number ranges to an
enterprise network, is willing to delegate authority to the
enterprise network over that number range(s). This node is a Boolean
type, a value of 1/true indicates that the SIP service provider is
willing to delegate authority to the enterprise network over one or
more number ranges. A value of 0/false indicates that the SIP
service provider is not willing to delegate authority to the
enterprise network over one or more number ranges. This leaf node
MUST only be included in the capability set if the value of the
STIRCompliance leaf node is set to 1/true. In order to obtain
delegate certificates, the enterprise network must be made aware of
the scope of delegation - the number or number range(s) over which
the SIP service provider is willing to delegate authority. This
information is included in the numRange container.
*ACMEDirectory*: For delegate certificates that are obtained by the
enterprise network using Automatic Certificate Management Environment
(ACME), this leaf node value provides the URL of the directory object
(https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-
18#section-7.1.1). The directory object URL, when de-referenced,
provides a collection of field name-value pairs. Certain field name-
value pairs provided in the response are used to bootstrap the
process the obtaining delegate certificates. This leaf node MUST
only be included in the capability set if the value of the
certDelegation leaf node is set to 1/true.
*extensions*: A leaf node that is a semicolon separated list of all *extensions*: A leaf node that is a semicolon separated list of all
possible SIP option tags supported by the service provider network. possible SIP option tags supported by the service provider network.
These extensions must be referenced using name registered under IANA. These extensions must be referenced using name registered under IANA.
If the service provider network does not support any extensions to If the service provider network does not support any extensions to
baseline SIP, the extensions node must be set to "NULL". baseline SIP, the extensions node must be set to "NULL".
9.4. Extending the Capability Set 7.4. Extending the Capability Set
There are situations in which equipment manufactures or service There are situations in which equipment manufactures or service
providers would benefit from extending the YANG module defined in providers would benefit from extending the YANG module defined in
this draft. For example, service providers could extend the YANG this draft. For example, service providers could extend the YANG
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
skipping to change at page 25, line 39 skipping to change at page 30, line 37
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 [29]] to "augment" statement as defined in Section 4.2.8 of [RFC 7950
extend the module defined in this draft. (https://tools.ietf.org/html/rfc7950)] to extend the module defined
in this draft.
10. Example Capability Set Document Encoding 8. Processing the Capability Set Response
This section provides a non-normative description of the procedures
that could be carried out by the enterprise network after obtaining
the SIP service provider capability set. On obtaining the capability
set, the enterprise edge element can parse the various fields within
the capability set and generate configuration blocks. For example,
the configuration required to successfully register a SIP trunk with
the SIP registrar hosted in the service provider network, the
configuration required to ensure that fax calls are handled
appropriately, the configuration required to advertise only audio
codecs supported by the SIP service provider, among many other
configuration blocks. A configuration block generated for an almost
identical SIP service provider capability set document is likely
going to differ drastically from one vendor to the next.
Enterprise edge elements are usually capable of normalising
mismatches in the signalling and media planes between the enterprise
and service provider SIP networks. As a result, most, if not all of
the configuration blocks required to enable successful SIP service
provider peering might need to be added on the edge element. In
situations wherein configuration blocks need to be distributed across
multiple devices, some mechanism, that is out of scope of this
document might be used to communicate the specific fields of capacity
set and their corresponding value. Alternatively, a human
administrator could go through the capability set document and
configure the edge element (and if required, other devices in the
enterprise network appropriately.
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. JSON or XML as well as the exchange of messages between the
enterprise edge element and the service provider to acquire the
capability set document.
10.1. XML Capability Set Document 9.1. XML Capability Set Document
<peering-info xmlns="urn:ietf:params:xml:ns:yang:ietf-peering" <peering-info xmlns="urn:ietf:params:xml:ns:yang:ietf-peering"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:yang:ietf-peering ietf-peering.xsd"> xsi:schemaLocation="urn:ietf:params:xml:ns:yang:ietf-peering ietf-peering.xsd">
<variant>1.0</variant> <variant>1.0</variant>
<transport-info> <transport-info>
<transport>TCP;TLS;UDP</transport> <transport>TCP;TLS;UDP</transport>
<registrar>registrar1.voip.example.com:5060</registrar> <registrar>registrar1.voip.example.com:5060</registrar>
<registrar>registrar2.voip.example.com:5060</registrar> <registrar>registrar2.voip.example.com:5060</registrar>
<registrarRealm>voip.example.com</registrarRealm> <registrarRealm>voip.example.com</registrarRealm>
skipping to change at page 27, line 19 skipping to change at page 32, line 44
<payloadNumber>101</payloadNumber> <payloadNumber>101</payloadNumber>
<iteration>0</iteration> <iteration>0</iteration>
</dtmf> </dtmf>
<security> <security>
<signaling> <signaling>
<type>TLS</type> <type>TLS</type>
<version>1.0;1.2</version> <version>1.0;1.2</version>
</signaling> </signaling>
<mediaSecurity> <mediaSecurity>
<keyManagement>SDES;DTLS-SRTP,version=1.2</keyManagement> <keyManagement>SDES;DTLS-SRTP,version=1.2</keyManagement>
</mediaSecurity> </mediaSecurity>
<certLocation>https://sipserviceprovider.com/certificateList.pem</certLocation> <certLocation>https://sipserviceprovider.com/certificateList.pem</certLocation>
</security> <secureTelephonyIdentity>
<STIRCompliance>true</STIRCompliance>
<certDelegation>true</certDelegation>
<ACMEDirectory>https://sipserviceprovider.com/acme.html</ACMEDirectory>
</secureTelephonyIdentity>
</security>
<extensions>timer;rel100;gin;path</extensions> <extensions>timer;rel100;gin;path</extensions>
</peering-response> </peering-response>
11. Example Exchange 9.2. Example Exchange
This section depicts an example of the configuration flow that This section depicts an example of the configuration flow that
ultimately results in the enterprise edge element obtaining the ultimately results in the enterprise edge element obtaining the
capability set document from the SIP service provider. Assuming the capability set document from the SIP service provider. Assuming the
enterprise edge element has been pre-configured with the request 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+xml
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 XML.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/peering-info+xml Content-Type: application/peering-info+xml
Content-Length: nnn Content-Length: nnn
<peering-info> <peering-info>
... …
</peering-info> </peering-info>
12. Security Considerations 10. Security Considerations
[TBD] [TBD]
13. Acknowledgments 11. Acknowledgments
[TBD] [TBD]
14. References 12. Normative References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833, Digits, Telephony Tones and Telephony Signals", RFC 2833,
DOI 10.17487/RFC2833, May 2000, DOI 10.17487/RFC2833, May 2000,
<https://www.rfc-editor.org/info/rfc2833>. <https://www.rfc-editor.org/info/rfc2833>.
skipping to change at page 29, line 20 skipping to change at page 34, line 45
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
DOI 10.17487/RFC6665, July 2012, DOI 10.17487/RFC6665, July 2012,
<https://www.rfc-editor.org/info/rfc6665>. <https://www.rfc-editor.org/info/rfc6665>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<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>.
skipping to change at page 30, line 8 skipping to change at page 35, line 34
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>.
Authors' Addresses Authors' Addresses
Kaustubh Inamdar Kaustubh Inamdar
Cisco Systems Unaffiliated
Email: kinamdar@cisco.com Email: kaustubh.ietf@gmail.com
Sreekanth Narayanan Sreekanth Narayanan
Cisco Systems Cisco Systems
Email: sreenara@cisco.com Email: sreenara@cisco.com
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Email: fluffy@iii.ca Email: fluffy@iii.ca
 End of changes. 95 change blocks. 
299 lines changed or deleted 482 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/