Automatic Peering for SIP Trunks

Introduction The deployment of a Session Initiation Protocol (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 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.

Overview of Operations 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.

Reference Architecture Figure 1 illustrates a reference architecture that may be deployed to support the mechanism described in this document. The enterprise network consists of a SIP-PBX, media endpoints (M.E.) and a Session Border Controller . 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 server. | | | | | | | |<-|---------|---| | +-----+ | | | | +----------+ | | | |-->| SIP | | | | | | | | |<--| PBX | | | | | | | | | +-----+ | | | | +----------+ | | | SBC | | | | | | | | SIP | | | | | | | | SP - SSE |--|---------|-->| | +-----+ | | | | | |<-|---------|---| |-->| M.E.| | | | | +----------+ | | | |<--| | | | | | | | | | +-----+ | | | | +----------+ | (S)RTP | | | | | | | | Media |--|---------|-->| | | | | | | |<-|---------|---| | | | | | +----------+ | | +-------+ | | | +---------------+ +-----------------------+ | | | +-----------------------------------------------------+ Figure 1: Reference Architecture ]]> This draft makes use of the following terminology:

Enterprise Network: A communications network infrastructure deployed by an enterprise which interconnects with the service provider network over SIP. The enterprise network could include devices such as application servers, endpoints, call agents and edge devices, among others.
Edge Device: A device that is the last hop in the enterprise network and that is the transit point for traffic entering and leaving the enterprise. An edge device is typically a back-to-back user agent (B2BUA) such as a Session Border Controller (SBC).
Service Provider Network: A communications network infrastructure deployed by service providers. In the context of this draft, the service provider network is accessible over SIP for the establishment, modification and termination of calls and accessible over HTTPS for the transfer of the capability set document. The service provider network is also referred to as a SIP Service Provider (SSP) or Internet Telephony Service Provider (ITSP) network.
Call Control: Call Control within a telephony networks refers to software that is responsible for delivering its core functionality. Call control not only provides the basic functionality of setting up, sustaining and terminating calls, but also provides the necessary control and logic required for additional services within the telephony network, such as, registration of endpoints, integration with application servers (voicemail, instant messaging, presence), among others.
Capability Server: A server hosted in the service provider network, such that this server is the target for capability set document requests from the enterprise network.
Capability Set: The term capability set (or capability set document) refers collectively to a set of characteristics within the service provider network, which when communicated to the enterprise network, provides the enterprise network the information required to interconnect with the service provider network. The various parameters that constitute the capability set relate to characteristics that are specific to signalling, media, transport and security. Certain aspects of interconnecting with service providers are out of scope of the capability set; for example, the access technology used to interconnect with service provider networks.

Configuration Workflow A workflow that facilitates an enterprise network to solicit the capability set of a SIP service provider ought to take into account the following considerations:

The configuration workflow must be based on a protocol or a set of protocols commonly used between enterprise and service provider telephony networks.
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.
Capability set documents obtained as a result of the configuration workflow must be conducive to easy parsing by automation. Subsequently, automation may be used for the generation of appropriate configuration blocks on the edge element or across one or more elements in 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 , 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 that enable configuration to be pushed over NETCONF 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.

Transport 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:

Edge elements are devices that normalise any mismatches between the enterprise and service provider networks in the media and signaling planes. As a result, when the capability set is received from the SIP service provider network, the edge element can generate appropriate configuration blocks (possibly across multiple devices) to enable interconnection.
Given that edge elements are configured to "talk" to networks external to the enterprise, the complexity in terms of NAT traversal and firewall configuration would be minimal.

The 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.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here.

HTTP Transport 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 .

HTTP Methods 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.

Integrity and Confidentiality Peering requests and responses are defined over HTTP . 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) ; 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 .

Authenticated Client Identity 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 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" () flow to acquire the capability set document from the service provider in Figure 2. Using the "Resource Owner Password Credentials" grant type () requires the existence of a trust relationship between the resource owner (in this context, the administrator/enterprise network) and the client (in this context, an edge element such as an SBC). In SIP trunking deployments between enterprise and service provider networks, such a trust relationship between the administrator/resource owner/enterprise network and the client (edge element) already exists, as SIP trunk registration (and refreshing registrations) require credentials - typically a username and password, that are configured on the edge element by the administrator. However, it is important for the enterprise network administrator and service provider to factor in security issues associated with this grant type. | 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 enterprise SBC (client) initiates the flow by directing the resource owner's (enterprise network administrator) user-agent to the authorization endpoint. The SBC includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). As a precursor to the flow, the enterprise network administrator has already obtained a unique client identifier for their network and provided a redirection URI populated with a target within their network to obtain the authorization code.
The authorization server within the service provider network authenticates the network administrator (via the user-agent) and establishes whether the network administrator grants or denies the client's access request.
Assuming the network administrator grants access, the authorization server redirects the user-agent back to the enterprise SBC using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.
The enterprise SBC requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the enterprise SBC authenticates with the authorization server and includes the redirection URI used to obtain the authorization code for verification.
The authorization server authenticates the enterprise SBC, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the SBC in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.
The enterprise SBC then contacts the capability server located in the service provider network with an HTTP GET request along with the access token to retrieve the capability set document.
The capability server checks for a valid access token and returns the capability set document to the enterprise SBC. The service provider will host a unique document for each enterprise network that will peer with it.

Encoding the Request 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.

Identifying the Request Target 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:

Manual Configuration
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, to the edge element), the WebFinger protocol and the 'sipTrunkingCapability' 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). 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.

Generating the response 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:

301 Moved Temporarily
302 Found
307 Temporary Redirect

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.

State Deltas Given that the service provider capability set is largely expected to remain static, the work needed to implement an asynchronous push mechanism to encode minor changes in the capability set document (state deltas) is not commensurate with the benefits. Rather, enterprise edge elements can poll capability servers at pre-defined intervals to obtain the full capability set document. It is recommended that capability servers are polled every 24 hours.

Encoding the Service Provider Capability Set In the context of this draft, the capability set of a service provider refers collectively to a set of characteristics which when communicated to an enterprise network, provides it with sufficient information to directly peer with the service provider network. The capability set document is not designed to encode extremely granular details of all features, services, and protocol extensions that are supported by the service provider network. For example, it is sufficient to encode that the service provider uses T.38 relay for faxing, it is not required to know the value of the "T38FaxFillBitRemoval" parameter. The parameters within the capability set document represent a wide array of characteristics, such that these characteristics collectively disseminate sufficient information to enable direct IP peering between enterprise and service provider networks. The various parameters represented in the capability set are chosen based on existing practises and common problem sets typically seen between enterprise and service provider SIP networks.

Data Model for Capability Set This section defines a YANG module 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.

Tree Diagram This section provides a tree diagram for the "ietf-sip-auto-peering" module. The interpretation of the symbols appearing in the tree diagram is as follows:

Brackets "[" and "]" enclose list keys.
Abbreviations before data node names: "rw" means configuration (read-write), and "ro" means state data (read-only).
Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list.
Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
Ellipsis ("...") stands for contents of subtrees that are not shown.

The data model for the peering capability document has the following structure:

YANG Model 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 and system management . WG List: Editor: Kaustubh Inamdar Editor: Sreekanth Narayanan Editor: Cullen Jennings "; 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"; } typedef uri { type string; description "Type for a Uniform Resource Identifier"; reference "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"; } 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 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 specified in this list 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. A value of true signifies that the service provider is capable of early media, whereas false signifies otherwise."; } 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. A value of true indicates the service provider network can potentially fork outbound call requests, whereas false indicates it will not."; } 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."; } container caller-id { description "A container that encodes the preferences of SIP Service Providers in terms of calling number presentation by the enterprise network."; leaf e164-format { type boolean; description "A value of true indicates that the enterprise should format the calling number in E.164 format, while false indicates that there are no restrictions on formatting of the calling number."; } 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."; } } 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."; 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 "Indicates whether the DID range is communicated by value or by 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."; } } } container media { description "A container used to encapsulate the characteristics of UDP-based audio streams and basic RTP/RTCP information."; list media-type-audio { key "media-format"; description "A list of media types and parameters necessary to set up media between the enterprise and service provider."; 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."; } } container fax { description "Encapsulates the fax protocol(s) supported by the SIP service provider."; 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 "Encapsulates generic characteristics of RTP sessions."; leaf rtp-trigger { type boolean; description "A value of true indicates that the service provider expects the enterprise network to send the first RTP packet after media establishment. A value of false indicates no such requirement from the service provider."; } leaf symmetric-rtp { type boolean; description "A value of true indicates that the service provider expects the enterprise network to use the same port for sending and receiving RTP. A value of false indicates no such requirement from the service provider (RFC 4961)."; } } container rtcp { description "Encapsulates generic characteristics of RTCP sessions."; leaf symmetric-rtcp { type boolean; description "A value of true indicates that the service provider expects the enterprise network to use the same port for sending and receiving RTCP. A value of false indicates no such requirement from the service provider (RFC 4961)."; } leaf rtcp-feedback { type boolean; description "A value of true indicates that the service provider supports the transmission of RTCP feedback packets that aid in congestion control and other features. A value of false indicates that the service provider does not support RTCP feedback (RFC 8888)."; } } } container dtmf { description "Describes various aspects of DTMF relay via RTP 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 "Encapsulates characteristics about encrypting signalling streams."; container signaling { description "Encapsulates the security protocol for SIP signalling."; leaf secure { type boolean; description "A value of true indicates that the service provider supports the use of TLS for SIP signalling while a vlue of false indicates no support."; } leaf-list version { type enumeration { enum 1.2 { description "TLS version 1.2."; } enum 1.3 { description "TLS version 1.3."; } } description "Specifies the TLS version(s) supported. If TLS is not supported, this list should be set to 'NULL'."; } } container media-security { description "Describes characteristics of securing media streams."; leaf dtls-key-management { type boolean; description "Specifies whether DTLS is supported for SRTP key management (RFC 5764). A value of true indicates that the service provider supports key management over DTLS and a value of false indicates that key management for SRTP must be done externally."; } } leaf cert-location { type string; description "If required, contains the URL from which the service provider's certificate(s) can be retrieved."; } container secure-telephony-identity { description "Encapsulates Secure Telephony Identity (STIR) characteristics."; leaf stir-compliance { type boolean; description "A value of true indicates that the service provider is STIR compliant while a value of false indicates no support for STIR."; } leaf cert-delegation { type boolean; description "A value of true indicates that the service provider is willing to delegate authority over allocated number ranges while a value of false indicates no such support."; } leaf acme-directory { when "../cert-delegation = 'true'"; type uri; description "Provides the URL of the ACME directory for delegate certificates."; } } } leaf-list extensions { type string; description "A list of all possible SIP option tags supported by the service provider network."; } } } ]]>

Extending the Capability Set There are situations in which equipment manufactures or service providers would benefit from extending the YANG module defined in this draft. For example, service providers could extend the YANG module to include information that further simplifies direct IP peering. Such information could include: trunk group identifiers, 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: In the example above, a custom module named "vendorA-config" uses the "augment" statement as defined in Section 4.2.8 of to extend the module defined in this draft.

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.

Examples 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.

JSON Capability Set Document

Example Exchange 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. ]]> The capability set document is obtained in the body of the response and is encoded in JSON.

IANA Considerations This document has no IANA actions.

Security Considerations 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.

OAuth Credentials 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.

Client-Server Communication 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.

Acknowledgments 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 and Harald Alvestrand for their reviews and feedback.