| Internet-Draft | SIP Auto Peer | March 2025 |
| Inamdar, et al. | Expires 20 September 2025 | [Page] |
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The deployment of a Session Initiation Protocol [RFC3261] (SIP)-based infrastructure in enterprise and service provider communication networks is increasing at a rapid pace. Consequently, direct IP peering between enterprise and service provider networks is quickly replacing conventional methods of interconnection between enterprise and service provider networks. Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioral subsets, extensions to baseline protocols and operating principles ought to be implemented by service provider and enterprise networks to ensure successful peering.¶
The SIP Connect technical recommendations [SIP-Connect-TR] aim to solve this problem by providing a central reference that promotes seamless peering between enterprise and service provider SIP networks. However, despite the extensive set of implementation rules and operating guidelines, interoperability issues between service provider and enterprise networks persist. This is in large part because service providers and equipment manufacturers aren't required to enforce the guidelines of the technical specifications and have a fair degree of freedom to deviate from them. Consequently, enterprise administrators usually undertake a fairly rigorous regimen of testing, analysis and troubleshooting to arrive at a configuration block that ensures seamless service provider peering. However, this workflow complements the SIP Connect technical recommendations, in that both endeavours aim to promote/achieve interoperability between the enterprise and service provider.¶
Another set of interoperability problems arise when enterprise administrators are required to translate a set of technical recommendations from service providers to configuration blocks across one or more devices in the enterprise network, which is usually an error prone exercise. Additionally, such technical recommendations might not be nuanced enough to intuitively allow the generation of specific configuration blocks.¶
This draft introduces a mechanism using which an enterprise network can solicit a detailed capability set from a SIP service provider; the detailed capability set can subsequently be used by automation or an administrator to generate configuration blocks across one or more devices within the enterprise network to ensure successful service provider peering.¶
This section provides a reference architecture against which the SIP Auto Peer framework may be implemented. Additionally, terms that are commonly used in the context of the document are defined. Lastly, considerations for the choice of network transport between enterprise and service provider telephony networks are discussed.¶
Figure 1 illustrates a reference architecture that may be deployed to support the mechanism described in this document. The enterprise network consists of a SIP-PBX, media endpoints (M.E.) and a Session Border Controller [RFC7092]. It may also include additional components such as application servers for voicemail, recording, fax etc. At a high level, the service provider consists of a SIP signaling entity (SP-SSE), a media entity for handling media streams of calls setup by the SP-SSE and a HTTPS [RFC9110] server.¶
+-----------------------------------------------------+
| +---------------+ +-----------------------+ |
| | | | | |
| | +----------+ | | +-------+ | |
| | | Cap | | HTTPS | | | | |
| | | Server |--|---------|-->| | | |
| | | |<-|---------|---| | +-----+ | |
| | +----------+ | | | |-->| SIP | | |
| | | | | |<--| PBX | | |
| | | | | | +-----+ | |
| | +----------+ | | | SBC | | |
| | | | | SIP | | | | |
| | | SP - SSE |--|---------|-->| | +-----+ | |
| | | |<-|---------|---| |-->| M.E.| | |
| | +----------+ | | | |<--| | | |
| | | | | | +-----+ | |
| | +----------+ | (S)RTP | | | | |
| | | Media |--|---------|-->| | | |
| | | |<-|---------|---| | | |
| | +----------+ | | +-------+ | |
| +---------------+ +-----------------------+ |
| |
+-----------------------------------------------------+
Figure 1: Reference Architecture
¶
This draft makes use of the following terminology:¶
A workflow that facilitates an enterprise network to solicit the capability set of a SIP service provider ought to take into account the following considerations:¶
The configuration workflow must be flexible enough to allow the service provider network to dynamically offload different capability sets to different enterprise networks based on the identity of the enterprise network.¶
Taking the above considerations into account, this document proposes a Hypertext Transfer Protocol (HTTP)-based workflow using which the enterprise network can solicit and ultimately obtain the service provider capability set. The enterprise network creates a well formed HTTP GET request to solicit the service provider capability set. Subsequently, the HTTPS response from the SIP service provider includes the capability set. The capability set is encoded in JSON, thus ensuring that the response can be easily parsed by automation.¶
There are alternative mechanisms using which the SIP service provider can offload its capability set. For example, the Session Initiation Protocol (SIP) can be extended to define a new event package [RFC6665], such that the enterprise network can establish a SIP subscription with the service provider for its capability set; the SIP service provider can subsequently use the SIP NOTIFY request to communicate its capability set or any state deltas to its baseline capability set.¶
This mechanism is likely to result in a barrier to adoption for SIP service providers and enterprise networks as equipment manufacturers would have to first add support for such a SIP extension. A HTTPS-based approach would be relatively easier to adopt as most edge devices deployed in enterprise networks today already support HTTPS; from the perspective of service provider networks, all that is required is for them to deploy HTTPS servers that function as capability servers. Additionally, most SIP service providers require enterprise networks to register with them (using a SIP REGISTER message) before any other SIP methods that initiate subscriptions (SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a SIP-based framework to obtain a capability set would require operational changes on the part of service provider networks.¶
Yet another example of an alternative mechanism would be for service providers and enterprise equipment manufacturers to agree on YANG models [RFC6020] that enable configuration to be pushed over NETCONF [RFC6241] to enterprise networks from a centralised source hosted in service provider networks. The presence of proprietary software logic for call and media handling in enterprise devices would preclude the generation of a "one-size-fits-all" YANG model. Additionally, service provider networks pushing configuration to enterprises devices might lead to the loss of implementation autonomy on the part of the enterprise network.¶
To solicit the capability set of a SIP service provider, the edge element in an enterprise network generates a well-formed HTTP GET request. There are two reasons why it makes sense for the enterprise edge element to generate the HTTPS request:¶
The HTTP GET request is targeted at a capability server that is managed by the SIP service provider such that this server processes, and on successfully processing the request, includes the capability set document in the response. The capability set document is constructed according the guidelines of the YANG model described in this draft. The capability set document included in a successful response is formatted in JSON. More details about the formatting of the HTTP request and response are provided in Section 4.¶
There could be situations wherein an enterprise telephony network interconnects with its SIP service provider such that traffic between the two networks traverses an intermediary SIP service provider network. This could be a result of interconnect agreements between the terminating and transit SIP service provider networks. In such situations, the capability set provided to the enterprise network by its SIP service provider must account for the characteristics of the transit SIP service provider network from a signalling and media perspective. For example, if the terminating SIP service provider network supports the G.729 codec and the transit SIP service provider network does not, G.729 must not be advertised in the capability set. As another example, if the transit SIP service provider network doesn't support a SIP extension, for instance, the SIP extension for Reliable Provisional Responses as defined in RFC 3262, the terminating SIP service provider network must not advertise support for this extension in the capability set provided to the enterprise network. How a terminating SIP service provider obtains the characteristics of the intermediary SIP service provider network is out of the scope of this document; however, one method could be for the terminating SIP service provider to obtain the characteristics of the intermediary SIP service provider by leveraging the YANG model introduced in this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section describes the use of HTTPS as a transport protocol for the peering workflow. This workflow is based on HTTP/1.1, and as such is compatible with any future version of HTTP that is backward compatible with HTTP/1.1 including HTTP/3 [RFC9114].¶
The workflow defined in this document leverages the HTTP GET method and its corresponding response(s) to request for and subsequently obtain the service provider capability set document.¶
Peering requests and responses are defined over HTTP [RFC9110]. However, due to the sensitive nature of information transmitted between client and server, it is required to secure HTTP communications using Transport Layer Security (TLS) [RFC8446]; therefore the enterprise edge element and the capability server MUST support TLS. When HTTP/3 is used, TLS is incorporated within QUIC. Additionally, the enterprise edge element and capability server MUST support the use of the HTTPS URI scheme as defined in [RFC9110].¶
HTTP usually adopts asymmetric methods of authentication. For example, clients typically use certificate based authentication to verify the server they are talking to, whereas, servers typically use methods such as HTTP digest authentication or OAuth 2.0 [RFC6749] to authenticate clients. Though OAuth 2.0 is not an authentication protocol, it nonetheless allows for client authentication to be carried out with the use of OAuth tokens.¶
In the context of the SIP Auto Peer framework, OAuth 2.0 MUST be used to carry out client authentication. Enterprise edge elements could use the various grant types outlined in the OAuth 2.0 specification and supported by the service provider in order to obtain the capability set document. This draft does not mandate a specific grant type. The implementation of OAuth 2.0 to obtain the capability set are beyond the scope of this document. However, it provides an example of how an enterprise SBC could leverage the "Authorization Code Grant" (Section 4.1 of [RFC6749]) flow to acquire the capability set document from the service provider in Figure 2.¶
Using the "Resource Owner Password Credentials" grant type (Section 1.3.3 of [RFC6749]) requires the existence of a trust relationship between the resource owner (in this context, the administrator/enterprise network) and the client (in this context, an edge element such as an SBC). In SIP trunking deployments between enterprise and service provider networks, such a trust relationship between the administrator/resource owner/enterprise network and the client (edge element) already exists, as SIP trunk registration (and refreshing registrations) require credentials - typically a username and password, that are configured on the edge element by the administrator. However, it is important for the enterprise network administrator and service provider to factor in security issues associated with this grant type.¶
+---------------+
| Resource |
| Owner |
| (Enterprise) |
+---------------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| Service |
| User- | | Provider |
| Agent -+----(B)-- User authenticates --->| Authorization |
| | | Server |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| (SBC) | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
^ v
| |
| | +--------------+
| -------(F)---- Access Token --------->| Capability |
-----------(G)---- Capability set -------<| Server |
+--------------+
Figure 2: Client Authentication Mechanism
¶
The flow illustrated in Figure 2 includes the following steps:¶
The edge element in the enterprise network generates a HTTP GET request such that the request-target is obtained using the procedure outlined in section 4.5. This document does not specify any content negotiation. The server MUST set the response content type header to the application/json media type.¶
HTTP 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:¶
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, to the edge element), the WebFinger protocol [RFC7033] and the 'sipTrunkingCapability' [RFC9409] link relation type may be leveraged assuming that the service SIP service provider has implemented WebFinger within their network and hosts the capability set at the respective location.¶
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=sipTrunkingCapability
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" : "sipTrunkingCapability",
"href" :
"https://capserver.ssp1.com/capserver/capdoc.json"
}
]
}
¶
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.¶
Capability servers include the capability set documents in the body of a successful response. Capability set documents MUST be formatted in JSON. For requests that are incorrectly formatted, an example being an incorrect query parameter in the URI, the capability server must generate a "400 Bad Request" response for the incorrect request. If requests contain an invalid token, the capability server must generate a "403 Forbidden" response clearly indicating that this token does not have the permission to view the capability set document.¶
The capability server can respond to client requests with redirect responses, specifically, the server can respond with the following redirect responses:¶
The server SHOULD include the Location header field in such responses. If the Location header isn't included in the response, this can lead to the client being unable to find the capability set document, leading to a failure in the peering process or requiring manual intervention by an administrator.¶
Given that the service provider capability set is largely expected to remain static, the work needed to implement an asynchronous push mechanism to encode minor changes in the capability set document (state deltas) is not commensurate with the benefits. Rather, enterprise edge elements can poll capability servers at pre-defined intervals to obtain the full capability set document. It is recommended that capability servers are polled every 24 hours.¶
In the context of this draft, the capability set of a service provider refers collectively to a set of characteristics which when communicated to an enterprise network, provides it with sufficient information to directly peer with the service provider network. The capability set document is not designed to encode extremely granular details of all features, services, and protocol extensions that are supported by the service provider network. For example, it is sufficient to encode that the service provider uses T.38 relay for faxing, it is not required to know the value of the "T38FaxFillBitRemoval" parameter.¶
The parameters within the capability set document represent a wide array of characteristics, such that these characteristics collectively disseminate sufficient information to enable direct IP peering between enterprise and service provider networks. The various parameters represented in the capability set are chosen based on existing practises and common problem sets typically seen between enterprise and service provider SIP networks.¶
This section defines a YANG module [RFC7950] for encoding the service provider capability set. Section 7.1 provides the tree diagram, which is followed by a description of the various nodes within the module defined in this draft.¶
This section provides a tree diagram [RFC8340] for the "ietf-sip-auto-peering" module. The interpretation of the symbols appearing in the tree diagram is as follows:¶
The data model for the peering capability document has the following structure:¶
module: ietf-sip-auto-peering
+--rw peering-info* [index]
+--rw index uint16
+--rw variant enumeration
+--rw revision
| +--rw not-before uint32
| +--rw location inet:uri
+--rw transport-info
| +--rw transport* enumeration
| +--rw registrar* [host port]
| | +--rw host union
| | +--rw port inet:port-number
| +--rw realms* [name]
| | +--rw name string
| | +--rw username? string
| | +--rw password? ianach:crypt-hash
| +--rw call-control* [host port]
| | +--rw host union
| | +--rw port inet:port-number
| +--rw dns* inet:ip-address
| +--rw outbound-proxy* [host port]
| +--rw host union
| +--rw port inet:port-number
+--rw call-specs
| +--rw early-media? boolean
| +--rw signaling-forking? boolean
| +--rw supported-methods* enumeration
| +--rw caller-id
| | +--rw e164-format? boolean
| | +--rw preferred-method? enumeration
| +--rw num-ranges* [index]
| +--rw index uint16
| +--rw type? enumeration
| +--rw count? uint16
| +--rw value* string
+--rw media
| +--rw media-type-audio* [media-format]
| | +--rw media-format enumeration
| | +--rw rate? uint8
| | +--rw ptime? uint8
| | +--rw param? string
| +--rw fax
| | +--rw protocol* enumeration
| +--rw rtp
| | +--rw rtp-trigger? boolean
| | +--rw symmetric-rtp? boolean
| +--rw rtcp
| +--rw symmetric-rtcp? boolean
| +--rw rtcp-feedback? boolean
+--rw dtmf
| +--rw payload-number? uint8
| +--rw iteration? boolean
+--rw security
| +--rw signaling
| | +--rw secure? boolean
| | +--rw version* enumeration
| +--rw media-security
| | +--rw key-management* enumeration
| +--rw cert-location? inet:uri
| +--rw secure-telephony-identity
| +--rw stir-compliance? boolean
| +--rw cert-delegation? boolean
| +--rw acme-directory? inet:uri
+--rw extensions* string
¶
This section defines the YANG module for the peering capability set document. This module depends on existing YANG modules that provide common YANG data types [RFC6991] and system management [RFC7317].¶
<CODE BEGINS> file "ietf-sip-auto-peering@2025-03-19.yang"
module ietf-sip-auto-peering {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering";
prefix "peering";
import ietf-inet-types {
prefix "inet";
reference
"RFC 6991: Common YANG Data Types";
}
import iana-crypt-hash {
prefix "ianach";
reference
"RFC 7317: A YANG Data Model for System Management";
}
organization
"IETF ASAP (Automatic SIP trunking And Peering) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/asap/>
WG List: <mailto:asap@ietf.org>
Editor: Kaustubh Inamdar
<mailto:kaustubh.ietf@gmail.com>
Editor: Sreekanth Narayanan
<mailto:sreenara@cisco.com>
Editor: Cullen Jennings
<mailto:fluffy@iii.ca>";
description
"Data model for encoding SIP Service Provider Capability Set
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2025-03-19 {
description "Initial version";
reference
"NOTE TO RFC EDITOR: Please replace 'RFC XXXX' with the actual
RFC number of this document when published, and delete this
sentence. Also replace the revision with the date of publication
of this document.
RFC XXXX: Automatic Peering for SIP Trunks";
}
grouping entity {
description "Grouping that provides a reusable list named
'entity', with each entry containing a host and a port.";
leaf host {
type union {
type inet:ip-address;
type inet:domain-name;
}
description "IP Address or host name of the entity";
}
leaf port {
type inet:port-number;
description "Entity's port number (e.g. 5060).";
}
}
list peering-info {
key index;
max-elements 1;
description "A list containing a single container; the
peering-info node is akin to the root element of a JSON
document.";
leaf index {
type uint16;
description "Index for the peering-info document.";
}
leaf variant {
type enumeration {
enum v1_0 {
description "Variant 1.0 of the capability set document is
defined in this draft";
}
}
mandatory true;
description "A node that identifies the version number of the
capability set document. This draft defines the parameters
for variant 1.0; future specifications might define a richer
parameter set, in which case the variant must be changed to
2.0, 3.0 and so on. Future extensions to the capability set
document MUST also ensure that the corresponding YANG module
is defined.";
}
container revision {
description "A container that encapsulates information
regarding the availability of a new version of the
capability set document for the enterprise.";
leaf not-before {
type uint32;
mandatory true;
description "A node that identifies the epoch time at
which the parameters in this capability set document are
activated or considered valid. This node has been set to
mandatory as it is the service provider's
responsibility to inform when new peering settings take
effect. Without being aware of a start time, the
enterprise network will experience failures.";
}
leaf location {
type inet:uri;
mandatory true;
description "A node that identifies the URL of a new
revision of the service provider capability set document.
Without this URL, an enterprise network wouldn't be aware
of changes that have occurred in the service provider
network.";
}
}
container transport-info {
description "A container that encapsulates transport
characteristics of SIP sessions between enterprise and
service provider networks.";
leaf-list transport {
type enumeration {
enum tcp {
description "Transmission Control Protocol";
}
enum tls {
description "Transport Layer Security (over TCP)";
}
enum udp {
description "User Datagram Protocol";
}
}
min-elements 1;
description "A list that enumerates the different Transport
Layer protocols supported by the SIP service provider.
Valid transport layer protocols include: UDP, TCP and TLS";
}
list registrar {
key "host port";
uses entity;
max-elements 3;
description "A list that specifies the transport address of
one or more registrar servers in the service provider
network. The transport address of the registrar can be
provided using a combination of a valid IP address and
port number, or a subdomain of the SIP service provider
network, or the fully qualified domain name (FQDN) of the
SIP service provider network. If the transport address of
a registrar is specified using either a subdomain or a
fully qualified domain name, the DNS element must be
populated with one or more valid DNS server IP
addresses.";
}
list realms {
key "name";
description "A container that encapsulates the set of realms
or protection domains the SIP service provider is
responsible for.";
leaf name {
type string;
mandatory true;
description "A node specifying the SIP service provider
realm or protection domain. This node is encoded as a
string; the value of this node must be identical to the
value of the 'realm' parameter in a WWW-Authenticate
header field that the SIP service provider might send in
response to requests that do not contain a valid
Authorisation header field.";
}
leaf username {
type string;
description "A node that encodes the username for the
given realm. The username is one of many inputs used by
the enterprise network in generating the response
parameter of the Authorization header field.";
}
leaf password {
type ianach:crypt-hash;
description "A node that encodes the password for the
given realm. The password is one of many inputs used by
the enterprise network in generating the response
parameter of the Authorization header field. The
password is stored as a cryptographic hash.";
}
}
list call-control {
key "host port";
uses entity;
max-elements 3;
description "A list that specifies the transport address of
the call server(s) in the service provider network. The
enterprise network must use an applicable transport
protocol in conjunction with the call control server(s)
transport address when transmitting call setup requests.
The transport address of a call server(s) within the
service provider network can be specified using a
combination of a valid IP address and port number, or a
subdomain of the SIP service provider network, or a fully
qualified domain name of the SIP service provider network.
If the transport address of a call control server(s) is
specified using either a subdomain or a fully qualified
domain name, the DNS element must be populated with one
or more valid DNS server IP addresses. The transport
address specified in this element can also serve as the
target for non-call requests such as SIP OPTIONS.";
}
leaf-list dns {
type inet:ip-address;
max-elements 2;
description "A list that encodes the IP address of one or
more DNS servers hosted by the SIP service provider. If
the enterprise network is unaware of the IP address, port
number, and transport protocol of servers within the
service provider network (for example, the registrar and
call control server), it must use DNS NAPTR and SRV.
Alternatively, if the enterprise network has the fully
qualified domain name of the SIP service provider network,
it must use DNS to resolve the said FQDN to an IP address.
The dns element encodes the IP address of one or more DNS
servers hosted in the service provider network. If however,
either the registrar or call-control lists or both are
populated with a valid IP address and port pair, the dns
element must be set to ::/0.";
}
list outbound-proxy {
key "host port";
uses entity;
description "A list that specifies the transport address of
one or more outbound proxies. The transport address can be
specified by using a combination of an IP address and a
port number, a subdomain of the SIP service provider
network, or a fully qualified domain name and port number
of the SIP service provider network. If the outbound-proxy
list is populated with a valid transport address, it
represents the default destination for all outbound SIP
requests and therefore, the registrar and call-control
lists must be populated with the quadruple octet of
0.0.0.0";
}
}
container call-specs {
description "A container that encapsulates information about
call specifications, restrictions and additional handling
criteria for SIP calls between the enterprise and service
provider network.";
leaf early-media {
type boolean;
description "A node that specifies whether the service
provider network is expected to deliver in-band
announcements/tones before call connect. The
'P-Early-Media' header field can be used to indicate
pre-connect delivery of tones and announcements on a
per-call basis. However, given that signalling and media
could traverse a large number of intermediaries with
varying capabilities (in terms of handling of the
'P-Early-Media' header field) within the enterprise, such
devices can be appropriately configured for media cut
through if it is known before-hand that early media is
expected for some or all of the outbound calls. This
element is a boolean type, where a value of true signifies
that the service provider is capable of early media. A
value of false signifies that the service provider is not
expected to generate early media.";
}
leaf signaling-forking {
type boolean;
description "A node that specifies whether outbound call
requests from the enterprise might be forked on the
service provider network that MAY lead to multiple early
dialogs. This information would be useful to the
enterprise network in appropriately handling multiple early
dialogs reliably and in enforcing local policy. This
element is a boolean type, where a value of true signifies
that the service provider network can potentially fork
outbound call requests from the enterprise. A value of
false indicates that the service provider will not fork
outbound call requests.";
}
leaf-list supported-methods {
type enumeration {
enum INVITE {
description "Initiate a dialog or session.";
}
enum ACK {
description "Acknowledge final response to INVITE.";
}
enum BYE {
description "Terminate a dialog or session.";
}
enum CANCEL {
description "Cancel a pending request.";
}
enum REGISTER {
description "Register contact information.";
}
enum OPTIONS {
description "Query capabilities of a server.";
}
enum PRACK {
description "Provisional acknowledgement.";
}
enum SUBSCRIBE {
description "Subscribe to an event.";
}
enum NOTIFY {
description "Notify subscriber of an event.";
}
enum PUBLISH {
description "Publish an event state.";
}
enum INFO {
description "Send mid-session information.";
}
enum REFER {
description "Refer recipient to a third party.";
}
enum MESSAGE {
description "Instant message transport.";
}
enum UPDATE {
description "Update session parameters within a dialog.";
}
}
description "A list that specifies the various SIP methods
supported by the SIP service provider. The list of
supported methods help to appropriately configure
various devices within the enterprise network. For
example, if the service provider enumerates support for
the OPTIONS method, the enterprise network could
periodically send OPTIONS requests as a keep-alive
mechanism.";
}
container caller-id {
description "A container that encodes the preferences of SIP
service providers in terms of calling number presentation
by the enterprise network. Certain ITSPs require that the
calling number be formatted in E.164, whereas others place
no such restrictions. Additionally, some ITSPs require
that the calling number be included in a specific SIP
header field, for example, the P-Asserted-ID header field
or the From header field, whereas others place no
restrictions on the specific SIP header field used to
convey the calling number.";
leaf e164-format {
type boolean;
description "A node that indicates whether the service
provider requires the enterprise network to normalize
the calling number into E.164 format. A value of true
mandates the enterprise network to format calling
numbers to E.164 format, while a false leaves the
formatting of the calling number up to the enterprise
network.";
}
leaf preferred-method {
type enumeration {
enum P_ASSERTED_IDENTITY {
description "Use the 'P-Asserted-Identity' header to
determine remote party identity.";
}
enum FROM {
description "Use the 'From' header to determine remote
party identity.";
}
}
description "A node that specifies which SIP header MUST
be used by the enterprise network to communicate caller
information. The value of this node is a string that
contains the name of the SIP header required to carry
caller information.";
}
}
list num-ranges {
key index;
description "A list that specifies the Direct Inward Dial
(DID) number range allocated to the enterprise network by
the SIP service provider. The DID number ranges allocated
by the service provider to the enterprise network might be
a contiguous or a non-contiguous block. The number ranges
allocated to an enterprise can be communicated as a value
or as a reference. For large enterprise networks, the size
of the DID range might run into several hundred numbers.
For situations in which the enterprise is allocated a large
DID number range or a non-contiguous number range it is
RECOMMENDED that the SIP service provider communicate this
information by reference, that is, through a URL. The
enterprise network is required to de-reference this URL in
order to obtain the DID number ranges allocated by the SIP
service provider. Refer to the example provided in
Section 9.1.";
leaf index {
type uint16;
description "Index for the number ranges.";
}
leaf type {
type enumeration {
enum range {
description "Numbers specified as a range.";
}
enum collection {
description "Numbers specified in the form of a
collection.";
}
enum reference {
description "Number range available at a URL.";
}
}
description "A node that indicates whether the DID range
is communicated by value or by reference. It can have a
value of 'range', 'collection' or 'reference'.";
}
leaf count {
when "../type = 'range' or ../type = 'collection'";
type uint16;
description "Indicates the size of the DID number range.
This leaf MUST NOT be included when using the
'reference' type.";
}
leaf-list value {
type string;
description "A list that encapsulates the DID number range
allocated to the enterprise. If the num-ranges 'type' is
set to 'range' or 'collection', the 'count' node MUST
have a valid, non-zero, positive integer. If the
num-ranges 'type' value is set to 'range', then, the
number in this field represents the first phone number
of a DID range allocated to the enterprise. The value
of subsequent numbers of the given DID range are
obtained by adding one to the value of this field. The
number of times we need to add one is indicated by the
'count' field.";
}
}
}
container media {
description "A container that is used to collectively
encapsulate the characteristics of UDP-based audio streams.
A future extension to this draft may extend the media
container to describe other media types. The media container
is also used to encapsulate basic information about
Real-Time Transport Protocol (RTP) and Real-Time Transport
Control Protocol (RTCP) from the perspective of the service
provider network. At the time of writing this specification,
video media streams aren't exchanged between enterprise and
service provider SIP networks.";
list media-type-audio {
key "media-format";
description "A list encoding the various audio media formats
supported by the SIP service provider. The relative
ordering of different media formats in the list indicates
preference from the perspective of the service provider.
Each element in the list begins with the encoding name
of the media format, which is the same encoding name as
used in the 'RTP/AVP' and 'RTP/SAVP' profiles. The
encoding name is followed by the sampling rate for the
encoding and the packetization time. Additionally, any
other required and optional parameters for the given media
format as specified when the media format is registered
[@RFC4855] are described the 'param' field.
Given that the parameters of media formats can vary from
one communication session to another, for example, across
two separate communication sessions, the packetization
time (ptime) used for the PCMU media format might vary
from 10 to 30 ms, the parameters included in the format
element must be the ones that are expected to be invariant
from the perspective of the service provider. Providing
information about supported media formats and their
respective parameters, allows enterprise networks to
configure the media plane characteristics of various
devices such as endpoints and middleboxes.";
leaf media-format {
type enumeration {
enum PCMU {
description "PCMU format.";
}
enum G722 {
description "G722 format.";
}
}
description "The audio media format.";
}
leaf rate {
type uint8;
description "Sampling rate in Hz.";
}
leaf ptime {
type uint8;
description "Packetization time in milliseconds.";
}
leaf param {
type string;
description "Optional parameter for additional media
details regarding the encoding.";
}
}
container fax {
description "A container that encapsulates the fax
protocol(s) supported by the SIP service provider. The fax
container encloses a list (protocol) that enumerates
whether the service provider supports t38 relay,
protocol-based fax passthrough or both. The relative
ordering of nodes within the lists indicates preference.";
leaf-list protocol {
type enumeration {
enum pass_through {
description "Protocol-based fax passthrough.";
}
enum t38 {
description "T38 relay.";
}
}
max-elements 2;
description "List indicating the different fax protocols
supported by the service provider.";
}
}
container rtp {
description "A container that encapsulates generic
characteristics of RTP sessions between the enterprise
and service provider network.";
leaf rtp-trigger {
type boolean;
description "A node indicating whether the SIP service
provider network always expects the enterprise network
to send the first RTP packet for an established
communication session. This information is useful in
scenarios such as 'hairpinned' calls, in which the caller
and callee are on the service provider network and
because of sub-optimal media routing, an enterprise
device such as an SBC is retained in the media path.
Based on the encoding of this node, it is possible to
configure enterprise devices such as SBCs to start
streaming media (possibly filled with silence payloads)
toward the address:port tuples provided by caller and
callee. This node is a boolean type. A value of true
indicates that the service provider expects the
enterprise network to send the first RTP packet, whereas
a value of false indicates that the service provider
network does not require the enterprise network to send
the first media packet. While the practise of preserving
the enterprise network in a hairpinned call flow is
fairly common, it is recommended that SIP service
providers avoid this practise. In the context of a
hairpinned call, the enterprise device retained in the
call flow can easily eavesdrop on the conversation
between the offnet parties.";
}
leaf symmetric-rtp {
type boolean;
description "A node indicating whether the SIP service
provider expects the enterprise network to use symmetric
RTP as defined in [@RFC4961]. Enforcement of this
requirement by service providers on enterprise networks
is typically useful in scenarios such as media latching
[@RFC7362]. This node is a boolean type, a value of true
indicates that the service provider expects the
enterprise network to use symmetric RTP, whereas a value
of false indicates that the enterprise network can use
asymmetric RTP.";
}
}
container rtcp {
description "A container that encapsulates generic
characteristics of RTCP sessions between the enterprise
and service provider network.";
leaf symmetric-rtcp {
type boolean;
description "A node indicating whether the SIP service
provider expects the enterprise network to use symmetric
RTCP as defined in [@RFC4961]. This node is a boolean
type, a value of true indicates that the service
provider expects symmetric RTCP reports, whereas a
value of false indicates that the enterprise can use
asymmetric RTCP.";
}
leaf rtcp-feedback {
type boolean;
description "A node that indicates whether the SIP service
provider supports the RTP profile extension for
RTCP-based feedback [@RFC4585]. Media sessions spanning
enterprise and service provider networks, are rarely
made to flow directly between the caller and callee,
rather, it is often the case that media traffic flows
through network intermediaries such as SBCs. As a result,
RTCP traffic from the service provider network is
intercepted by these intermediaries, which in turn can
either pass across RTCP traffic unmodified or modify
RTCP traffic before it is forwarded to the endpoint in
the enterprise network. Modification of RTCP traffic
would be required, for example, if the intermediary has
performed media payload transformation operations such
as transcoding or transrating. In a similar vein, for
the RTCP-based feedback mechanism as defined in
[@RFC4585] to be truly effective, intermediaries must
ensure that feedback messages are passed reliably and
with the correct formatting to enterprise endpoints.
This might require additional configuration and
considerations that need to be dealt with at the time of
provisioning the intermediary device. This node is of
boolean type, a value of true indicates that the service
provider supports the RTP profile extension for
RTP-based feedback and a value of false indicates that
the service provider does not support the RTP profile
extension for RTP-based feedback.";
}
}
}
container dtmf {
description "A container that describes the various aspects of
DTMF relay via RTP Named Telephony Events. The dtmf
container allows SIP service providers to specify two facets
of DTMF relay via Named Telephony Events.";
leaf payload-number {
type uint8 {
range "96..127";
}
description "Indicates the payload type number.";
}
leaf iteration {
type boolean;
description "A value of true indicates that the service
provider supports RFC4733 while a value of false indicates
that the service provider prefers RFC2833";
}
}
container security {
description "A container that encapsulates characteristics
about encrypting signalling streams between the enterprise
and SIP service provider networks.";
container signaling {
description "A container that encapsulates the type of
security protocol for the SIP communication between the
enterprise SBC and the service provider.";
leaf secure {
type boolean;
description "A node that specifies whether the service
provider allows the use of TLS to secure SIP signalling
messages between the enterprise and service provider
network. This node is of boolean type, a value of true
indicates that the service provider supports SIP
sessions over TLS, wheras a value of false indicates
that the service provider does not support SIP over
TLS.";
}
leaf-list version {
type enumeration {
enum 1.2 {
description "TLS version 1.2.";
}
enum 1.3 {
description "TLS version 1.3.";
}
}
description "A list that specifies the version(s) of TLS
supported.";
}
}
container media-security {
description "A container that describes the various
characteristics of securing media streams between
enterprise and service provider networks.";
leaf-list key-management {
type enumeration {
enum SDES {
description "Simplified Data Encryption Standard
key management.";
}
enum DTLS-SRTP {
description "SRTP keys managed using DTLS.";
}
}
description "A list that specifies the key management
method(s) used by the service provider. Possible values
in this list include 'SDES' and 'DTLS-SRTP'. A value of
'SDES' signifies that the SIP service provider uses the
methods defined in [@RFC4568] for the purpose of key
management. A value of 'DTLS-SRTP' signifies that the
SIP service provider uses the methods defined in
[@RFC5764] for the purpose of key management.";
}
}
leaf cert-location {
type inet:uri;
description "If the enterprise network is required to
exchange SIP traffic over TLS with the SIP service
provider, and if the SIP service provider is capable of
accepting TLS connections from the enterprise network, it
may be required for the SIP service provider certificates
to be pre-installed on the enterprise edge element. In
such situations, the cert-location node is populated with
a URL, which when dereferenced, provides a single PEM
encoded file that contains all certificates in the chain
of trust.";
}
container secure-telephony-identity {
description "Encapsulates Secure Telephony Identity (STIR)
characteristics.";
leaf stir-compliance {
type boolean;
description "A node that indicates whether the SIP service
provider is STIR compliant. This node is of boolean
type, a value of true indicates that the SIP service
provider is STIR compliant. A value of 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.";
}
leaf cert-delegation {
type boolean;
description "A node 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 of boolean type, a value of 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 false indicates that the SIP service
provider is not willing to delegate authority to the
enterprise network over one or more number ranges. This
node MUST only be included in the capability set if the
value of the stir-compliance leaf node is set to 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 num-ranges container.";
}
leaf acme-directory {
when "../cert-delegation = 'true'";
type inet:uri;
description "A node that provides the URL of the directory
object for delegate certificates using Automatic
Certificate Management Environment (ACME) [@RFC8555].
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 node MUST only be included in the
capability set if the value of the cert-delegation
leaf node is set to true.";
}
}
}
leaf-list extensions {
type string;
description "A list of all possible SIP option tags supported
by the service provider network. These extensions must be
referenced using name registered under IANA.";
}
}
}
<CODE ENDS>¶
There are situations in which equipment manufactures or service providers would benefit from extending the YANG module defined in this draft. For example, service providers could extend the YANG module to include information that further simplifies direct IP peering. Such information could include: trunk group identifiers, customer/enterprise account numbers, service provider support numbers, among others. Extension of the module can be achieved by importing the module defined in this draft. An example is provided below: Consider a new YANG module "vendorA" specified for VendorA's enterprise SBC. The "vendorA-config" YANG module is configured as follows:¶
module vendorA-config {
namespace "urn:ietf:params:xml:ns:yang:vendorA-config";
prefix "vendorA";
description
"Data model for configuring VendorA Enterprise SBC";
revision 2020-05-06 {
description "Initial revision of VendorA Enterprise SBC
configuration data model";
}
import ietf-peering {
prefix "peering";
}
augment "/peering:peering-info" {
container vendorAConfig {
leaf vendorAConfigParam1 {
type int32;
description "vendorA configuration parameter 1
(SBC Device ID)";
}
leaf vendorAConfigParam2 {
type string;
description "vendorA configuration parameter 2
(SBC Device name)";
}
description "Container for vendorA SBC configuration";
}
}
}
¶
In the example above, a custom module named "vendorA-config" uses the "augment" statement as defined in Section 4.2.8 of [RFC7950] to extend the module defined in this draft.¶
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.¶
This section provides examples of how capability set documents that leverage the YANG module defined in this document can be encoded over JSON as well as the exchange of messages between the enterprise edge element and the service provider to acquire the capability set document. The service provider will create a unique document for each enterprise network that will peer with it.¶
<CODE BEGINS> file "asap-example.json"
{
{
"ietf-sip-auto-peering:peering-info": [
{
"variant": "v1_0",
"revision": {
"notBefore": 1742330340,
"location":
"https://capserver.example.org/capserver/capdoc.json"
},
"transport-info": {
"transport": [
"tcp",
"tls",
"udp"
],
"registrar": [
{
"host": "registrar1.voip.example.com",
"port": 5060
},
{
"host": "registrar2.voip.example.com",
"port": 5060
}
],
"realms": [
{
"name": "voip.example.com",
"username": "voip",
"password": "$6$salt$hash"
}
],
"call-control": [
{
"host": "callServer1.voip.example.com",
"port": 5060
},
{
"host": "192.0.2.40",
"port": 5065
}
],
"dns": [
"192.0.2.50",
"192.0.2.51"
],
"outbound-proxy": {
"host": "192.0.2.35",
"port": 5060
}
},
"call-specs": {
"early-media": true,
"signaling-forking": false,
"supported-methods": [
"INVITE",
"OPTIONS",
"BYE",
"CANCEL",
"ACK",
"PRACK",
"SUBSCRIBE",
"NOTIFY",
"REGISTER"
],
"caller-id": {
"e164-format": true,
"preferred-method": "FROM"
},
"num-ranges": [
{
"index": 0,
"type": "range",
"count": 20,
"value": [
"19725455000"
]
},
{
"index": 1,
"type": "collection",
"count": 2,
"value": [
"19725455000",
"19725455001"
]
}
]
},
"media": {
"media-type-audio": [
{
"media-format": "PCMU",
"rate": 8000,
"ptime": 20
},
{
"media-format": "G729",
"rate": 8000,
"ptime": 20,
"param": "annexb"
}
],
"fax": {
"protocol": [
"t38",
"pass-through"
]
},
"rtp": {
"rtp-trigger": true,
"symmetric-rtp": true
},
"rtcp": {
"symmetric-rtcp": true,
"rtcp-feedback": true
}
},
"dtmf": {
"payload-number": 101,
"iteration": false
},
"security": {
"signaling": {
"secure": true,
"version": ["1.0", "1.2", "1.3"]
},
"media-security": {
"key-management": ["SDES", "DTLS-SRTP"]
},
"cert-location":
"https://sipserviceprovider.com/certificateList.pem",
"secure-telephony-identity": {
"stir-compliance": true,
"cert-delegation": true,
"acme-directory": "https://sipserviceprovider.com/acme.html"
}
},
"extensions": [
"timer",
"rel100",
"gin",
"path"
]
}
]
}
<CODE ENDS>¶
This section is an informational example depicting the configuration flow that ultimately results in the enterprise edge element obtaining the capability set document from the SIP service provider. Assuming the enterprise edge element has been pre-configured with the request target for the capability set document or has dynamically found the request target, the edge element generates a HTTP GET request. This request can be challenged by the service provider to authenticate the enterprise.¶
GET /capdoc?trunkid=trunkent1456 HTTP/1.1
Host: capserver.ssp1.com
Authorization: Bearer <clientToken>
¶
The capability set document is obtained in the body of the response and is encoded in JSON.¶
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: nnn
{
"peering-info": ...
}
¶
This document has no IANA actions.¶
The capability set document contains sensitive information that must be protected from attackers. A capability set document leak can inflict considerable damage to both the enterprise as well as the service provider. An attacker that gains access to the capability set document can cause problems in multiple ways.¶
There are multiple attack points in the ASAP workflow. The sections below deal with the different points at which the workflow is vulnerable to attackers.¶
In scenarios wherein client authentication is carried out using OAuth resource owner credentials, it is required to ensure that these credentials cannot be acquired by any unauthorized third-party. If acquired by an unauthorized third-party, these credentials may be used to obtain the capability set document from the SIP service provider and subsequently use the information in such a document to make unauthorized calls while posing as an enterprise telephony network that has legitimately paid for calling services from a SIP service provider.¶
All communication used by the edge element to obtain the capability set document from the capability server MUST be secured using HTTPS. Failure to do so, results in the capability set document being transmitted over clear text, thus exposing sensitive information such as targets for trunks registration, targets for outbound calling requests and credentials used in building the Authorisation header field provided in response to authentication challenges.¶
We would like to thank those who provided detailed and thoughtful comments on this draft, especially Marc Petit-Huguenin, Paul Jones, Ram Mohan R, Nicola Serafini, Jonathan Rosenberg, Jon Peterson, Chris Wendt and Henning Schulzrinne. Additional thanks to Murray Kucherawy, Joel Halpern, Dan Harkins, Éric Vyncke, Joerg Ott, Mahesh Jethanandani, Orie Steele, Harald Alvestrand and Ebben Aries for their reviews and feedback.¶