RFC 10006
Automatic SIP Trunking and Peering
RFC 10006: Automatic SIP Trunking and Peering π
Part 1 of 10 π
Okay bestie, this is RFC 10006, the standards-track doc called Automatic SIP Trunking and Peering. It's an ISSN 2070-1721 document dated August 2026. The authors are K. Inamdar (no affiliation listed), S. Narayanan (listed as Unaffiliated), and C. Jennings from Cisco Systems π¦. The title block doesn't list anything it obsoletes or updates, so this one is standing on its own β¨.
Abstract π¦
So this doc is a framework that lets an enterprise phone network running SIP (Session Initiation Protocol) go and ask a SIP service provider for a capability set document π. That capability set doc packs in a bunch of characteristics that make peering between enterprise and service provider SIP networks super easy π .
Status of This Memo π
This is an Internet Standards Track document π₯. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication π«Ά. If you want more on Internet Standards, check Section 2 of RFC 7841 πΈ. Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc10006 π.
Copyright Notice Β©οΈ
Copyright (c) 2026 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) as they're in effect on the date this document is published. Please read these carefully, because they spell out your rights and restrictions for this document π. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License βοΈ.
Table of Contents π
1. Introduction
2. Requirements Language
3. Overview of Operations
3.1. Reference Architecture
3.2. Terminology
3.3. Configuration Workflow
3.4. Transport
4. HTTP Transport
4.1. HTTP Methods
4.2. Integrity and Confidentiality
4.3. Authenticated Client Identity
4.4. Encoding the Request
4.5. Identifying the Request Target
4.6. Generating Status Codes
5. Monitoring for Updates
6. Encoding the Service Provider Capability Set
7. Data Model for Capability Set
7.1. Tree Diagram
7.2. YANG Data Model
7.3. Extending the Capability Set
8. Processing the Capability Set Response
9. Examples
9.1. JSON Capability Set Document
9.2. Example Exchange
10. IANA Considerations
10.1. IANA-Maintained Module for SIP Option Tags
11. Security Considerations
11.1. OAuth Credentials
11.2. Client-Server Communication
11.3. YANG Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Alternative Mechanisms to Transmit the Capability Set
Acknowledgments
Authors' Addresses1. Introduction πΈ
Okay so SIP [RFC3261] deployments are growing at a rapid pace in enterprise and service provider communication networks, like, fast π. Because of that, direct IP peering between enterprise and service provider networks is quickly replacing the conventional ways of interconnecting them π₯. There's already a strong foundation of published standards you can build direct IP peering on top of (and yep, "peering" and "trunking" can be used interchangeably π€). BUT there are SO many standards that it's often not clear which behavioral subsets, extensions to baseline protocols, and operating principles the service provider and enterprise networks ought to implement to make peering work π.
The SIPconnect technical recommendations [SIPconnect-TR] are trying to fix this by acting as a central reference that promotes seamless peering between enterprise and service provider SIP networks π. Even with that extensive set of implementation rules and operating guidelines, interoperability issues between service provider and enterprise networks still pop up π. A big reason is that the guidelines in the technical specifications aren't hard requirements that the peer can enforce π. So enterprise administrators usually go through a pretty rigorous routine of testing, analysis, and troubleshooting to land on a configuration block that gives seamless service provider peering β¨. This workflow actually complements the SIPconnect technical recommendations, since both efforts are aiming for the same thing: interoperability between the enterprise and the service provider π«Ά.
Another interop headache: enterprise administrators often have to translate a set of technical recommendations from service providers into configuration blocks across one or more devices in the enterprise network, and that's usually a super error-prone job π©. On top of that, those recommendations might not be nuanced enough to let anyone intuitively generate the specific configuration blocks they need π.
So this document introduces the framework for Automatic Peering and Trunking over SIP π§. An enterprise network can solicit a detailed capability set from a SIP service provider. Then automation or an administrator can use that detailed capability set to generate configuration blocks across one or more devices within the enterprise network, so peering with the service provider works π.
2. Requirements Language π
Rules-lawyer alert π¨ Here's how the key words work in this doc. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here π§.
3. Overview of Operations β¨
This section gives you a reference architecture that the SIP Automatic Peering framework may be implemented against ποΈ. It also defines terms that show up a lot in the doc π. Last but not least, it talks about considerations for the configuration workflow and the choice of network transport between enterprise and service provider telephony networks π¦.
3.1. Reference Architecture ποΈ
Figure 1 shows a reference architecture that may be deployed to support the mechanism described in this document π . The enterprise network has a SIP Private Branch Exchange (SIP-PBX), media endpoints (ME), and a Session Border Controller (SBC) [RFC7092] π. It may also include extra stuff like application servers for voicemail, recording, fax, and so on π§. At a high level, the service provider has a SIP signaling entity (SP-SSE), a media entity that handles the media streams for calls the SP-SSE sets up, and an HTTP [RFC9110] server that stores the capability set document (that's the Cap Server in Figure 1) π.
+-----------------------------------------------------+
| +---------------+ +-----------------------+ |
| | | | | |
| | +----------+ | | +-------+ | |
| | | Cap | | HTTPS | | | | |
| | | Server |--|---------|-->| | | |
| | | |<-|---------|---| | +-----+ | |
| | +----------+ | | | |-->|SIP- | | |
| | | | | |<--|PBX | | |
| | | | | | +-----+ | |
| | +----------+ | | | SBC | | |
| | | | | SIP | | | | |
| | | SP-SSE |--|---------|-->| | +-----+ | |
| | | |<-|---------|---| |-->| ME | | |
| | +----------+ | | | |<--| | | |
| | | | | | +-----+ | |
| | +----------+ | (S)RTP | | | | |
| | | Media |--|---------|-->| | | |
| | | |<-|---------|---| | | |
| | +----------+ | | +-------+ | |
| +---------------+ +-----------------------+ |
| |
+-----------------------------------------------------+
Figure 1: Reference Architecture3.2. Terminology π
This doc uses the following terminology, so let's get you fluent π«Ά.
Enterprise Network: A communications network infrastructure deployed by an enterprise that interconnects with the service provider network over SIP. The enterprise network could include devices like application servers, endpoints, call agents, and edge devices, among others π’.
Edge Device: A device that's the last hop in the enterprise network and the transit point for traffic entering and leaving the enterprise πͺ. An edge device is typically a back-to-back user agent (B2BUA) [RFC7092], such as a Session Border Controller (SBC) π‘οΈ.
Service Provider Network: A communications network infrastructure deployed by service providers π. In the context of this document, the service provider network is reachable over SIP for setting up, modifying, and ending calls, and it's reachable over HTTP for transferring the capability set document π². It's also called a SIP Service Provider (SSP) or an Internet Telephony Service Provider (ITSP) network π.
Call Control: Call control within telephony networks refers to the software responsible for delivering core telephony functions ποΈ. It doesn't just do the basics of setting up, sustaining, and terminating calls. It also provides the control and logic needed for extra services in the telephony network, like registering endpoints and integrating with application servers (voicemail, instant messaging, presence), among others π§ .
Capability Server: A server hosted in the service provider network, and it's the target for capability set document requests coming from the enterprise network π―.
Capability Set (or Capability Set Document): This refers collectively to a set of characteristics within the service provider network. When they're communicated to the enterprise network, the enterprise network gets the information it needs to interconnect with the service provider network π. The parameters that make up the capability set relate to characteristics specific to signaling, media, transport, and security π. Some aspects of interconnecting with service providers are out of scope for the capability set, like the access technology used to interconnect with service provider networks π ββοΈ.
Part 1 of 10 ends here, continued in Part 2 π¦
3.3. Configuration Workflow π
okay so the enterprise network wants to ask its SIP service provider "what can you do??" πβ¨ and there are a few things it ought to keep in mind:
- 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 all of that into account, this document proposes an HTTP-based workflow that the enterprise network can use to solicit and ultimately obtain the service provider capability set. πΈ The enterprise network creates a well-formed HTTP GET request to ask for the SP capability set. Then the HTTP response from the SIP service provider includes the capability set. The capability set is encoded in JSON, so the response can be easily parsed by automation. it's giving clean and organized π«Ά
3.4. 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 be the one generating the HTTP request:
- Edge elements are the devices that smooth out any mismatches between the enterprise and service provider networks in the media and signaling planes. So once the capability set comes back 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 outside 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 managed by the SIP service provider. This server processes the request and, on successfully processing it, includes the capability set document in the response. The capability set document is constructed according to the guidelines of the YANG data model described in this document. A capability set document included in a successful response is formatted in JSON. More details about the formatting of the HTTP request and response are in Section 4. π
There could be situations wherein an enterprise telephony network interconnects with its SIP service provider, so 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 situations like this, 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 signaling 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 does not support a SIP extension, for instance the SIP extension for reliable provisional responses as defined in [RFC3262], 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 those characteristics by leveraging the YANG data model introduced in this document. π§ π
4. HTTP Transport β¨
This section describes the use of HTTP [RFC9110] as a transport protocol for the peering workflow. π¦
4.1. HTTP Methods
The workflow defined in this document leverages the HTTP GET method and its corresponding response(s) to request and then obtain the service provider capability set document. π
4.2. Integrity and Confidentiality π
Peering requests and responses are defined over HTTP [RFC9110]. However, because the information sent between client and server is sensitive, it is required to secure HTTP communications using Transport Layer Security (TLS) [RFC8446]. So the enterprise edge element and the capability server MUST support TLS version 1.2 [RFC5246] or later [RFC8446]. π‘οΈ When HTTP/3 [RFC9114] is used, TLS is incorporated within QUIC for the transport of the capability set document. The usage of SIP or RTP-over-QUIC is beyond the scope of this document. Additionally, the enterprise edge element and capability server MUST support the use of the https URI scheme as defined in [RFC9110]. π«Ά
4.3. 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 [RFC6749] to authenticate clients. Though OAuth 2.0 is not an authentication protocol, it still allows client authentication to be carried out with the use of OAuth tokens. π€
In the context of the SIP Automatic Peering 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 document does not mandate a specific grant type. The implementation of OAuth 2.0 to obtain the capability set is beyond the scope of this document. π However, it provides an example of how an enterprise SBC could leverage the authorization code grant flow (Section 4.1 of [RFC6749]) 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, that trust relationship between the client (edge element) and the administrator, resource owner, and enterprise network already exists. This is because SIP trunk registration (and refreshing registrations) requires credentials, typically a username and password, that the administrator configures on the edge element. Still, 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 MechanismThe flow illustrated in Figure 2 includes the following steps: π
A. The enterprise SBC (client) starts 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. The authorization server will send the user agent back to that redirection URI 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. π
B. 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. π
C. 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 the client provided earlier. ποΈ
D. 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. ποΈ
E. The authorization server authenticates the enterprise SBC, validates the authorization code, and makes sure the redirection URI received matches the URI used to redirect the SBC in step (C). If everything checks out, the authorization server responds with an access token and, optionally, a refresh token. β
F. 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. π¨
G. 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. ππ
4.4. Encoding the Request π
Okay so the edge element in the enterprise network sends out an HTTP GET request π, and the request target gets figured out using the procedure in Section 4.5. This document doesn't specify any content negotiation, so there's no drama there π
ββοΈ. The server MUST set the response content type header to the application/json media type π
. Literally a must, no cap.
4.5. Identifying the Request Target π―
HTTP GET requests from enterprise edge elements MUST carry a valid request target π«Ά. The edge element can get the URL of the resource hosted on the capability server in one of two ways:
- Manual configuration
- Discovery using the WebFinger protocol
So for manual config, the complete https URLs (the one for authenticating the enterprise edge element, which is optional, and the one for grabbing the SIP service provider capability set) can be gotten from the SIP service provider ahead of time. Then you just type them into the edge element through some interface, like a CLI or GUI π₯οΈ.
But if the resource URL is a mystery to the admin (and therefore to the edge element too π΅οΈββοΈ), the WebFinger protocol [RFC7033] and the sip-trunking-capability [RFC9409] link relation type may be leveraged. That only works if the SIP service provider has implemented WebFinger in their network and hosts the capability set at the matching location π.
Let's say an enterprise edge element wants to discover the URL of the endpoints hosted in the ssp1.example.com domain. It sends this:
GET /.well-known/webfinger?
resource=https%3A%2F%2Fssp1.example.com
rel=sipTrunkingCapability
HTTP/1.1
Host: ssp1.example.comAnd the response comes back looking like this β¨:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
"subject" : "https://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 get a unique capability set document that's specific to that enterprise telephony network π§©. The ITSP may use credentials to figure out who the enterprise telephony network is, and then hand over the appropriate capability set document π.
4.6. Generating Status Codes π¦
Capability servers pop the capability set documents into the body of a successful response π¦. Capability set documents MUST be formatted in JSON π§Ύ. For requests that are incorrectly formatted (like an incorrect query parameter in the URI), the capability server MUST generate a "400 Bad Request" status code for the incorrect request π
. And if requests contain an invalid token, the capability server MUST generate a "403 Forbidden" status code clearly indicating that this token does not have the permission to view the capability set document π.
The capability server can also respond to client requests with redirect status codes (3xx) π.
The server SHOULD include the Location header field in such responses π. Here's the tea β: if the Location header isn't included with the status code, the client might be unable to find the capability set document. That can lead to a failure in the peering process or mean an administrator has to step in manually π©.
The enterprise edge element SHOULD handle the 3xx status codes from the capability server in accordance with [RFC9110] π«Ά.
5. Monitoring for Updates π
Since the service provider capability set is largely expected to stay static π§, building an asynchronous push mechanism just to send minor changes (state deltas) isn't commensurate with the benefits. It's not worth the effort, bestie π ββοΈ. Instead, enterprise edge elements can poll capability servers at predefined intervals to grab the full capability set document π. It is recommended that capability servers are polled every 24 hours β°.
Alternatively, the enterprise edge elements can leverage preconditions specified in [RFC9110] to conditionally retrieve the capability set document only if any changes have occurred β .
6. Encoding the Service Provider Capability Set π§
In this document, the capability set of a service provider refers collectively to a set of characteristics. When they're communicated to an enterprise network, they give it enough info 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 the service provider network supports π. For example, it's enough to encode that the service provider uses T.38 relay for faxing π . You don't need to know the value of the T38FaxFillBitRemoval parameter. Not required, not needed, iconic π
.
The parameters in the capability set document represent a wide array of characteristics. Together, they disseminate enough information to enable direct IP peering between enterprise and service provider networks π. The parameters are chosen based on existing practices and common problem sets that typically show up between enterprise and service provider SIP networks π‘.
7. Data Model for Capability Set π§¬
This section has a tree diagram (Section 7.1), the YANG module [RFC7950] for encoding the service provider capability set (Section 7.2), and a discussion about extending the capability set (Section 7.3) π.
7.1. Tree Diagram π³
The meanings of the symbols in YANG tree diagrams are defined in "YANG Tree Diagrams" [RFC8340] π£.
The data model for the peering capability document has this structure:
module: ietf-sip-auto-peering
+--ro sip-auto-peering
+--ro variant identityref
+--ro revision
| +--ro not-before yang:date-and-time
| +--ro location inet:uri
+--ro transport-info
| +--ro transport* identityref
| +--ro registrar* [host port]
| | +--ro host union
| | +--ro port inet:port-number
| +--ro realm* [name]
| | +--ro name string
| | +--ro username? string
| | +--ro password? ianach:crypt-hash
| +--ro call-control* [host port]
| | +--ro host union
| | +--ro port inet:port-number
| +--ro dns-server* inet:ip-address
| +--ro outbound-proxy* [host port]
| +--ro host union
| +--ro port inet:port-number
+--ro call-spec
| +--ro early-media? boolean
| +--ro signaling-forking? boolean
| +--ro supported-method* enumeration
| +--ro caller-id
| | +--ro e164-format? boolean
| | +--ro preferred-method? enumeration
| +--ro number-range* [index]
| +--ro index uint16
| +--ro type? enumeration
| +--ro count? uint16
| +--ro value* string
+--ro media
| +--ro media-type-audio* [media-format]
| | +--ro media-format identityref
| | +--ro rate? uint16
| | +--ro ptime? uint8
| | +--ro parameter? string
| +--ro fax
| | +--ro protocol* enumeration
| +--ro rtp
| | +--ro rtp-trigger? boolean
| | +--ro symmetric-rtp? boolean
| +--ro rtcp
| +--ro symmetric-rtcp? boolean
| +--ro rtcp-feedback? boolean
+--ro dtmf
| +--ro payload-number? uint8
| +--ro iteration? boolean
+--ro security
| +--ro signaling
| | +--ro secure? boolean
| | +--ro version* identityref
| +--ro media-security
| | +--ro key-management* enumeration
| +--ro certificate-location? inet:uri
| +--ro secure-telephony-identity
| +--ro stir-compliance? boolean
| +--ro certificate-delegation? boolean
| +--ro acme-directory? inet:uri
+--ro extension* iana-sip-option-tags:sip-option-tag7.2. YANG Data 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 [RFC9911] and system management [RFC7317]. On top of that, this YANG module references [RFC2833], [RFC4585], [RFC4568], [RFC4733], [RFC4855], [RFC4961], [RFC5764], [RFC6716], [RFC7362], [RFC8555], [RFC9645], [iana-crypt-hash], and [iana-sip-option-tags] π.
<CODE BEGINS> file "ietf-sip-auto-peering@2026-06-15.yang"
module ietf-sip-auto-peering {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering";
prefix sipap;
import ietf-inet-types {
prefix inet;
reference
"RFC 9911: Common YANG Data Types.";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types.";
}
import iana-crypt-hash {
prefix ianach;
reference
"https://www.iana.org/assignments/iana-crypt-hash/";
}
import ietf-tls-common {
prefix tlscmn;
reference
"RFC 9645: YANG Groupings for TLS Clients and TLS Servers.";
}
import iana-sip-option-tags {
prefix iana-sip-option-tags;
reference
"https://www.iana.org/assignments/iana-sip-option-tags/";
}
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:sknth.n@protonmail.com>
Editor: Cullen Jennings
<mailto:fluffy@iii.ca>";
description
"Data model for encoding SIP service provider capability set.
This YANG module defines a read-only data model intended for
exchanging SIP service provider capabilities with enterprise
networks. The data is published by service providers and
consumed by enterprises via an out-of-band interface.
This module does NOT provide configuration capabilities; it
serves purely as a standardized format for capability exchange.
Service providers generate and host capability documents based
on this schema, which enterprises retrieve and use to configure
their SIP equipment.
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.
Copyright (c) 2026 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).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC 10006; see the
RFC itself for full legal notices."; revision 2026-06-15 {
description
"Initial version";
reference
"RFC 10006: Automatic SIP Trunking and Peering";
}
identity capability-doc-variant {
description
"Base for capability document variants.";
}
identity v1-0 {
base capability-doc-variant;
description
"Variant 1.0 of the capability set document.";
}
identity sip-transport-protocol {
description
"Base for transport protocols used to send SIP requests
across.";
}
identity udp {
base sip-transport-protocol;
description
"UDP used for SIP requests and responses.";
}
identity tcp {
base sip-transport-protocol;
description
"TCP used for SIP requests and responses.";
}
identity codec-variant {
description
"Base for variants of codec supported by the service
provider.";
}
identity pcmu {
base codec-variant;
description
"PCMU (G.711 ΞΌ-law) audio codec.";
}
identity pcma {
base codec-variant;
description
"PCMA (G.711 A-law) audio codec.";
}
identity opus {
base codec-variant;
description
"Opus audio codec.";
reference
"RFC 6716: Definition of the Opus Audio Codec.";
}
identity g722 {
base codec-variant;
description
"G.722 audio codec.";
}
identity g729 {
base codec-variant;
description
"G.729 codec.";
}
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.";
}
}okay the module keeps going and it's giving identities galore π¦ first up we've got the capability-doc-variant base with v1-0 hanging off it πβ¨ then the sip-transport-protocol base with udp and tcp as its besties π the codec-variant base is next, with pcmu, pcma, opus, g722 and g729 all sitting under it πΆ and finally the entity grouping, which is that reusable host-and-port list π
okay bestie, the YANG model is still going and it is giving structure π here's the next chunk π
container sip-auto-peering {
config false;
description
"Root container for SIP service provider capability data. This
container holds read-only operational data that represents the
capabilities and requirements of a SIP service provider.
Enterprise networks retrieve this data to automatically
configure their SIP trunking parameters.";
leaf variant {
type identityref {
base capability-doc-variant;
}
mandatory true;
description
"A node that identifies the version number of the capability
set document. RFC 10006 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.";
reference
"RFC 10006: Automatic SIP Trunking and Peering";
}
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 yang:date-and-time;
mandatory true;
description
"A node that identifies the absolute UTC 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 would not 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 identityref {
base sip-transport-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, 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 FQDN, the DNS
element must be populated with one or more valid DNS
server IP addresses.";
}
list realm {
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;
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 Authorization
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, a subdomain of the
SIP service provider network, or a FQDN of the SIP service
provider network. If the transport address of a call
control server(s) is specified using either a subdomain or
a FQDN, 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-server {
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
FQDN 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 can be omitted.";
}
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 FQDN
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; therefore, the registrar
and call-control lists can be omitted.";
}
}
container call-spec {
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
signaling 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 beforehand 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-method {
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 {okay bestie, we're still deep in the YANG module and it is GIVING detail π β¨ the SIP method list, caller-id prefs, and DID number ranges are all right here π
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 value of 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 number-range {
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
dereference this URL in order to obtain the DID number
ranges allocated 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
"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 number-range
'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.";
}
}
}next up is the media container π¦ it's where all the audio, fax, and RTP stuff lives, and ngl the RTP trigger bit is so specific π
container media {
description
"A container that is used to collectively encapsulate the
characteristics of UDP-based audio streams. A future
extension to RFC 10006 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
RFC 10006, video media streams are not exchanged
between enterprise and service provider SIP networks.";
reference
"RFC 10006: Automatic SIP Trunking and Peering";
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
are described the 'param' field.
Given that the parameters of media formats can vary from
one communication session to another (e.g., across two
separate communication sessions), the packetization
time (ptime) used for the PCMU media format might vary
from 10 to 30 ms, and 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.";
reference
"RFC 4855: Media Type Registration of RTP Payload Formats";
leaf media-format {
type identityref {
base codec-variant;
}
description
"The audio media format.";
}
leaf rate {
type uint16;
units "Hz";
description
"Sampling rate in Hz.";
}
leaf ptime {
type uint8;
units "milliseconds";
description
"Packetization time in milliseconds.";
}
leaf parameter {
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 T.38 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
"T.38 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 practice of
preserving the enterprise network in a hairpinned call
flow is fairly common, it is recommended that SIP
service providers avoid this practice. In the context
of a hairpinned call, the enterprise device retained in
the call flow can easily eavesdrop on the conversationbetween 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. Enforcement of this requirement by service providers on enterprise networks is typically useful in scenarios such as media latching. 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."; reference "RFC 4961: Symmetric RTP / RTP Control Protocol (RTCP), RFC 7362: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication"; } } 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. 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."; reference "RFC 4961: Symmetric RTP / RTP Control Protocol (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. Media sessions spanning enterprise and service provider networks are rarely made to flow directly between the caller and callee; rather, it is often the case that media traffic flows through network intermediaries such as SBCs. As a result, RTCP traffic from the service provider network is intercepted by these intermediaries, which in turn can either pass across RTCP traffic unmodified or modify RTCP traffic before it is forwarded to the endpoint in the enterprise network. Modification of RTCP traffic would be required, for example, if the intermediary has performed media payload transformation operations such as transcoding or transrating. In a similar vein, for the RTCP-based feedback mechanism as defined in RFC 4585 to be truly effective, intermediaries must ensure that feedback messages are passed reliably and with the correct formatting to enterprise endpoints. This might require additional configuration and considerations that need to be dealt with at the time of provisioning the intermediary device. This node is a boolean type. A value of 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."; reference "RFC 4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"; } } } 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 the newer standard while a value of false indicates that the service provider prefers the older standard"; reference "RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals, RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals"; } } container security { description "A container that encapsulates characteristics about encrypting signaling 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 signaling messages between the enterprise and service provider network. This node is a boolean type. A value of true indicates that the service provider supports SIP sessions over TLS, whereas a value of false indicates that the service provider does not support SIP over TLS."; } leaf-list version { when "../secure = 'true'"; type identityref { base tlscmn:tls-version-base; } 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 (SDES) key management."; } enum dtls-srtp { description "Secure Real-time Transport Protocol (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'."; reference "RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams, RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)"; } } leaf certificate-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 certificate-location node is populated with a URL, which when dereferenced, provides a single Privacy-Enhanced Mail (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 a 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 certificate-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 a 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, i.e., 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 "../certificate-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). The directory object URL, when dereferenced, provides a collection of field name-value pairs. Certain field name-value pairs provided in the response are used to bootstrap the process of obtaining delegate certificates. This node MUST only be included in the capability set if the value of the certificate-delegation leaf node is set to true."; reference "RFC 8555: Automatic Certificate Management Environment (ACME)"; } } } leaf-list extension { type iana-sip-option-tags:sip-option-tag; description "A list of SIP option tags (extensions) supported by the service provider network."; reference "https://www.iana.org/assignments/iana-sip-option-tags/"; } } } <CODE ENDS>
7.3. Extending the Capability Set β¨
okay so equipment manufacturers and service providers would totally benefit from extending the YANG module in this document π For example, service providers could add info that makes direct IP peering even simpler, like trunk group identifiers, customer/enterprise account numbers, and service provider support numbers (among others) π Extending the module is done by importing the module defined in this document. Here's an example!
Consider a new YANG module "example-vendor-config" specified for Vendor's enterprise SBC. The "example-vendor-config" YANG module is configured as follows:
module example-vendor-config {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-vendor-config";
prefix vendor;
import ietf-sip-auto-peering {
prefix sipap;
reference
"RFC 10006: Automatic SIP Trunking and Peering";
}
organization
"Vendor Enterprise.";
contact
"Vendor Enterprise
1234 Vendor Street
Anytown, State 12345
Tel: +1 424 254 5300
<mailto:vendor@vendor.com>";
description
"Example of a vendor configuration data model that augments the
IETF SIP auto-peering model to include vendor-specific SBC
configuration parameters.";
revision 2026-12-06 {
description
"Initial revision of Vendor Enterprise SBC
configuration data model.";
reference
"RFC 10006: Automatic SIP Trunking and Peering";
}
augment "/sipap:sip-auto-peering" {
description
"Augmentation of the SIP auto-peering model to include vendor-
specific SBC configuration parameters.";
container vendorConfig {
leaf vendorConfigParam1 {
type int32;
description
"Vendor configuration parameter 1
(SBC Device ID).";
}
leaf vendorConfigParam2 {
type string;
description
"Vendor configuration parameter 2
(SBC Device name).";
}
description
"Container for vendor SBC configuration.";
}
}
}So in this example, the custom module named "example-vendor-config" uses the "augment" statement as defined in Section 4.2.8 of [RFC7950] to extend the module defined in this document. Clean, right? π¦
8. Processing the Capability Set Response π₯
This section is non-normative π It describes what the enterprise network could do once it has the SIP service provider capability set. Once the enterprise edge element has the capability set, it can parse the different fields and generate configuration blocks. Some examples: the config needed to register a SIP trunk with the SIP registrar hosted in the service provider network, the config needed so fax calls get handled properly, and the config needed to advertise only the audio codecs the SIP service provider supports, plus many other 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 able to normalize mismatches in the signaling and media planes between the enterprise and service provider SIP networks β¨ So most, if not all, of the configuration blocks needed for successful SIP service provider peering might need to be added on the edge element. If configuration blocks need to be spread 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 values. Or, a human admin could go through the capability set document and configure the edge element (and, if required, other devices in the enterprise network) by hand π§
9. Examples π
This section gives examples of how capability set documents that use the YANG module defined in this document can be encoded in JSON, plus the message exchange between the enterprise edge element and the service provider to get the capability set document. The service provider will create a unique document for each enterprise network that will peer with it π
9.1. JSON Capability Set Document
Heads up, bestie: the '' line wrapping in this example follows [RFC8792] π
<CODE BEGINS> file "asap-example.json"
{
"ietf-sip-auto-peering:sip-auto-peering":
{
"variant": "ietf-sip-auto-peering:v1-0",
"revision": {
"not-before": "2026-06-15T10:30:00Z",
"location":
"https://capserver.example.org/capserver/capdoc.json"
},
"transport-info": {
"transport": [
"ietf-sip-auto-peering:tcp",
"ietf-sip-auto-peering:udp"
],
"registrar": [
{
"host": "registrar1.voip.example.com",
"port": 5060
},
{
"host": "registrar2.voip.example.com",
"port": 5060
}
],
"realm": [
{
"name": "voip.example.com",
"username": "voip",
"password":
"$6$OoEJwExxp6U/FRFq$4RkL2lSSGLoKdfGjX4lQLF\
Xo89gc0wtJsKiBxg/BBz6aNwu7C.D3kRUwD7lvJm6rhaCdhSzVh/XfkkAUY2dTu0"
}
],
"call-control": [
{
"host": "callServer1.voip.example.com",
"port": 5060
},
{
"host": "192.0.2.40",
"port": 5065
}
],
"dns-server": [
"192.0.2.50",
"192.0.2.51"
],
"outbound-proxy": [{
"host": "192.0.2.35",
"port": 5060
}]
},
"call-spec": {
"early-media": true,
"signaling-forking": false,
"supported-method": [
"invite",
"options",
"bye",
"cancel",
"ack",
"prack",
"subscribe",
"notify",
"register"
],
"caller-id": {
"e164-format": true,
"preferred-method": "from"
},
"number-range": [
{
"index": 0,
"type": "range",
"count": 20,
"value": [
"19725455000"
]
},
{
"index": 1,
"type": "collection",
"count": 2,
"value": [
"19725455000",
"19725455001"
]
}
]
},
"media": {
"media-type-audio": [
{
"media-format": "ietf-sip-auto-peering:pcmu",
"rate": 8000,
"ptime": 20
},
{
"media-format": "ietf-sip-auto-peering:g729",
"rate": 8000,
"ptime": 20,
"parameter": "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": ["ietf-tls-common:tls12", "ietf-tls-comm\
on:tls13"]
},
"media-security": {
"key-management": ["sdes", "dtls-srtp"]
},
"certificate-location":
"https://sipserviceprovider.com/certificateList.pem",
"secure-telephony-identity": {
"stir-compliance": true,
"certificate-delegation": true,
"acme-directory":
"https://sipserviceprovider.com/acme.html"
}
},
"extension": [
"one-hundred-rel",
"timer",
"replaces",
"path"
]
}
}
<CODE ENDS>9.2. Example Exchange
This section is an informational example showing the config flow that ends with the enterprise edge element grabbing the capability set document from the SIP service provider π¦ Assuming the edge element has been preconfigured with the request target for the capability set document, or has dynamically found it, the edge element sends an HTTP GET request. The service provider can challenge this request to authenticate the enterprise π
GET /capdoc?trunkid=trunkent1456 HTTP/1.1
Host: capserver.ssp1.com
Authorization: Bearer <clientToken>The capability set document comes back in the body of the response, encoded in JSON π
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: nnn
{
"ietf-sip-auto-peering:sip-auto-peering": ...
}10. IANA Considerations π
This document registers two new URIs in the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registrations have been made β¨
URI: urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:iana-sip-option-tags
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.This document registers two new YANG modules in the "YANG Module Names" registry [RFC6020]. Here they are, slay π
Name: ietf-sip-auto-peering
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering
Prefix: sipap
Reference: RFC 10006
Name: iana-sip-option-tags
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-sip-option-tags
Prefix: sip-option-tags
Reference: RFC 1000610.1. IANA-Maintained Module for SIP Option Tags π
okay so this doc is where the very first version of the IANA-maintained "iana-sip-option-tags" YANG module gets defined π the newest version always lives in the "YANG Parameters" registry group [YANG-PARAMS] β¨
IANA added this bit to the "Notes" field of the "iana-sip-option-tags" entry in the "YANG Module Names" registry, which sits in the "YANG Parameters" registry group. bestie, read this one carefully π
| New values must not be directly added to the "iana-sip-option-
| tags" YANG module. They must instead be added to the "Option
| Tags" registry [SIP-PARAMS].so whenever a value gets added to the "Option Tags" registry, a new enum statement has to be added to the "iana-sip-option-tags" YANG module too π§ the enum statement, and everything nested inside it, should be defined like this:
enum: Replicates a name from the registry.description: Replicates the description from the registry.reference: Replicates the reference(s) from the registry with the title of the document(s) added.
unassigned or reserved values are not in the module at all, so no ghosts allowed π»
when the "iana-sip-option-tags" YANG module gets updated, a new revision statement with a unique revision date needs to go in front of the existing revision statements π
the revision statement MUST contain both description and reference substatements, and it looks like this.
the description substatement is where you spill what changed in the new version βοΈ usually it lists the changes, like updates to existing entries (for example, a description or a reference getting changed) or notes about which enums got added or had their status changed (for example, deprecated, discouraged, or obsoleted).
if writing that description isn't doable, the wording depends on what triggered the update π«Ά
- If the update is triggered by an RFC, the
descriptionsubstatement should include or consist of this text:
Applied updates as specified by RFC 10006.- If the update is triggered following another IANA registration policy but not all the values in the registry are covered by the same policy, insert this text (where "Some_IANA_policy" refers to one of the defined registration policies in Section 4 of [RFC8126]):
Applied updates as specified by the registration policy
Some_IANA_policy.the reference substatement points specifically to the published module at [YANG-PARAMS] π it can also point to an authoritative event that set off the update. either way, that event gets cited from the underlying IANA registry. and if an RFC triggered the update, that RFC must also be included in the reference substatement.
IANA also added this note to the "Option Tags" registry, which lives in the "Session Initiation Protocol (SIP) Parameters" registry group [SIP-PARAMS] π
| When this registry is modified, the YANG module "iana-sip-option-
| tags" <https://www.iana.org/assignments/iana-sip-option-tags> must
| be updated as defined in RFC 10006.and last but not least, the service provider filters out the advertised extensions using local policy πΈ
11. Security Considerations π¨
okay this section is SERIOUS, bestie π the capability set document has sensitive info that absolutely has to be protected from attackers π if it leaks, it can seriously damage both the enterprise AND the service provider. an attacker who gets their hands on the capability set document can cause trouble in lots of ways π
there are multiple attack points in the ASAP workflow, so the sections below walk through each spot where the workflow is vulnerable to attackers π΅οΈββοΈ
11.1. OAuth Credentials π
if client authentication happens with OAuth resource owner credentials, it is required to make sure those credentials can't be grabbed by any unauthorized third party π ββοΈ if an unauthorized third party does get them, they can use them to pull the capability set document from the SIP service provider. then they can use the info in that document to make unauthorized calls while pretending to be an enterprise telephony network that legitimately paid for calling services from a SIP service provider. not it. π€
11.2. Client-Server Communication π
all communication the edge element uses to get the capability set document from the capability server MUST be secured using HTTPS π if that doesn't happen, the capability set document gets sent in clear text, which exposes sensitive stuff like targets for trunks registration, targets for outbound calling requests, and the credentials used to build the Authorization header field in responses to authentication challenges. so yeah, don't skip HTTPS π
11.3. YANG Security Considerations π‘οΈ
the "ietf-sip-auto-peering" YANG module defines a data model that a service provider MUST adhere to while creating the capability set document, preferably in an automated fashion π€ the capability set document SHOULD be formatted as a JSON file, as shown in Section 9. the service provider shares the URL of this JSON file with the enterprise out-of-band π¬ alternatively, the enterprise can use WebFinger to discover the URL of the JSON file. then the enterprise SBC downloads the JSON file and parses it. once it's validated that the JSON file is correctly formatted, it applies the configuration and peers with the service provider's network so SIP calls can happen π
it's possible that enterprises buy numbers in different countries or regions π in that case there would be multiple SIP trunks between the enterprise and the service provider. the service provider is responsible for creating the capability set documents for each SIP trunk. the enterprise can't modify the capability set document. it can only be created one time by the service provider for each enterprise that signs an agreement with the service provider. so, no particularly sensitive writable data nodes π
there are no particularly sensitive writable data nodes. (yes, we're saying it twice because it's that important π )
some of the readable data nodes in this YANG module may be sensitive or vulnerable in some network environments π so controlling read access is really important (for example, via get, get-config, or notification) to these data nodes. the following subtrees and data nodes have particular sensitivities/vulnerabilities:
registrar: This list contains IP addresses or hostnames belonging to registration servers in the service provider network, which may be targeted by malicious actors.realms: This list contains sensitive credentials that are utilized by the enterprise to create a registration with the service provider's network. The registration is a prerequisite to making and receiving calls to and from the service provider, respectively.call-control: This list contains IP addresses or hostnames belonging to call processing servers in the service provider network, which may be targeted by malicious actors.outbound-proxy: This list contains IP addresses or hostnames belonging to SIP proxies in the service provider network, which may be targeted by malicious actors.number-range: This list contains a range of phone numbers allocated by the service provider to an enterprise that the service provider may want to conceal from other enterprises or customers.
there are no particularly sensitive RPC or action operations π«§
this YANG module uses groupings from other YANG modules that define nodes that may be sensitive or vulnerable in network environments π§ check the Security Considerations of [RFC9911] and [RFC7317] to see which nodes might be sensitive or vulnerable in network environments.
the "iana-sip-option-tags" YANG module defines a set of types π those nodes are meant to be reused by other YANG modules. by itself, this module doesn't expose any writable data nodes, data nodes that contain read-only state, or RPCs. so as a result, there are no additional security issues related to this YANG module that need to be considered π
12. References π
12.1. Normative References π§Ύβ¨
bestie, here are the receipts π these are the normative ones, the stuff the spec needs you to have read π«Ά
- [iana-crypt-hash] IANA, "iana-crypt-hash YANG Module",
https://www.iana.org/assignments/iana-crypt-hash. - [iana-sip-option-tags] IANA, "iana-sip-option-tags YANG Module",
https://www.iana.org/assignments/iana-sip-option-tags. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, July 2002,
https://www.rfc-editor.org/info/rfc3261. - [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
https://www.rfc-editor.org/info/rfc4855. - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,
https://www.rfc-editor.org/info/rfc5246. - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010,
https://www.rfc-editor.org/info/rfc6020. - [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012,
https://www.rfc-editor.org/info/rfc6665. - [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012,
https://www.rfc-editor.org/info/rfc6749. - [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014,
https://www.rfc-editor.org/info/rfc7317. - [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016,
https://www.rfc-editor.org/info/rfc7950. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
https://www.rfc-editor.org/info/rfc8446. - [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
https://www.rfc-editor.org/info/rfc8792. - [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022,
https://www.rfc-editor.org/info/rfc9110. - [RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024,
https://www.rfc-editor.org/info/rfc9645. - [RFC9911] SchΓΆnwΓ€lder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025,
https://www.rfc-editor.org/info/rfc9911.
12.2. Informative References π
these are the extra reads, the "ooh, go deeper" section π
- [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, DOI 10.17487/RFC2833, May 2000,
https://www.rfc-editor.org/info/rfc2833. - [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, July 2002,
https://www.rfc-editor.org/info/rfc3262. - [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004,
https://www.rfc-editor.org/info/rfc3688. - [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
https://www.rfc-editor.org/info/rfc4568. - [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006,
https://www.rfc-editor.org/info/rfc4585. - [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006,
https://www.rfc-editor.org/info/rfc4733. - [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
https://www.rfc-editor.org/info/rfc4961. - [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010,
https://www.rfc-editor.org/info/rfc5764. - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
https://www.rfc-editor.org/info/rfc6241. - [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012,
https://www.rfc-editor.org/info/rfc6716. - [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013,
https://www.rfc-editor.org/info/rfc7033. - [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013,
https://www.rfc-editor.org/info/rfc7092. - [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, DOI 10.17487/RFC7362, September 2014,
https://www.rfc-editor.org/info/rfc7362. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
https://www.rfc-editor.org/info/rfc8126. - [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
https://www.rfc-editor.org/info/rfc8340. - [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
https://www.rfc-editor.org/info/rfc8555. - [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022,
https://www.rfc-editor.org/info/rfc9114. - [RFC9409] Inamdar, K., Narayanan, S., Engi, D., and G. Salgueiro, "The 'sip-trunking-capability' Link Relation Type", RFC 9409, DOI 10.17487/RFC9409, July 2023,
https://www.rfc-editor.org/info/rfc9409. - [SIP-PARAMS] IANA, "Session Initiation Protocol (SIP) Parameters",
https://www.iana.org/assignments/sip-parameters. - [SIPconnect-TR] SIP Forum, "SIPconnect 2.0 Technical Recommendation",
https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818. - [YANG-PARAMS] IANA, "YANG Parameters",
https://www.iana.org/assignments/yang-parameters.
Appendix A. Alternative Mechanisms to Transmit the Capability Set π¦
okay so the capability set doesn't have to come through HTTP only π§ the SIP service provider has other ways to offload it, and a few are pretty fun.
One option is to extend SIP itself with a new event package [RFC6665]. The enterprise network sets up a SIP subscription with the service provider for its capability set, and then the service provider can use the SIP NOTIFY request to send over the capability set or any state deltas against its baseline capability set π¬
ngl this one has a barrier to adoption energy π equipment manufacturers would have to add support for that SIP extension first, before anything could work. An HTTP-based approach is way easier to adopt, because most edge devices in enterprise networks already support HTTP πΈ From the service provider side, all that's needed is to deploy HTTP servers that work as capability servers.
Also, most SIP service providers require enterprise networks to register first (using a SIP REGISTER message) before any other SIP methods that start subscriptions (SIP SUBSCRIBE) or calls (SIP INVITE) get processed. So a SIP-based framework to get a capability set would mean operational changes on the service provider's side. Not the vibe π
Yet another option is for service providers and enterprise equipment manufacturers to agree on YANG data models [RFC6020] [RFC7950], so configuration can be pushed over NETCONF [RFC6241] to enterprise networks from a centralized source hosted in the service provider network. The catch? Proprietary software logic for call and media handling in enterprise devices would rule out a "one-size-fits-all" YANG data model π And service provider networks pushing configuration to enterprise devices might lead to the loss of implementation autonomy on the part of the enterprise network π¬
Acknowledgments π«Ά
We would like to thank those who provided detailed and thoughtful comments on this document, 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, Ebben Aries, Jen Linkova, David Dong, Gorry Fairhurst, Mohamed Boucadair, Paul Wouters, Mike Bishop, Andy Newton, and Amanda Baber for their reviews and feedback π
Authors' Addresses π¦
- Kaustubh Inamdar
- Unaffiliated
- Email:
kaustubh.ietf@gmail.com
- Sreekanth Narayanan
- Unaffiliated
- Email:
sknth.n@protonmail.com
- Cullen Jennings
- Cisco Systems
- Email:
fluffy@iii.ca
and that's the whole spec, bestie πβ¨π
π¦ where this page comes from
- ietf: rfc10006 2026-08
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms