Internet Engineering Task Force (IETF) K. Inamdar
Request for Comments: 10006 S. Narayanan
Category: Standards Track Unaffiliated
ISSN: 2070-1721 C. Jennings
Cisco Systems
August 2026
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks.
この文書は、企業テレフォニー セッション開始プロトコル (SIP) ネットワークが SIP サービス プロバイダーから機能セット文書を要求し、取得できるようにするフレームワークを指定します。機能セット ドキュメントは、企業とサービス プロバイダーの SIP ネットワーク間の簡単なピアリングを可能にする一連の特性をエンコードします。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10006.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10006 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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' Addresses
The deployment of an infrastructure based on SIP [RFC3261] 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 (note that "peering" and "trunking" can be used interchangeably). 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.
企業およびサービスプロバイダーの通信ネットワークにおける SIP [RFC3261] に基づくインフラストラクチャの導入は急速に増加しています。その結果、企業ネットワークとサービス プロバイダー ネットワーク間の直接 IP ピアリングが、企業ネットワークとサービス プロバイダー ネットワーク間の従来の相互接続方法に急速に取って代わりつつあります。現在公開されている標準は、直接 IP ピアリングを実現できる強力な基盤を提供します (「ピアリング」と「トランキング」は同じ意味で使用できることに注意してください)。ただし、これらの標準の数が膨大であるため、ピアリングを確実に成功させるためにサービス プロバイダーや企業ネットワークがどの動作サブセット、ベースライン プロトコルの拡張機能、および動作原理を実装する必要があるかが明確でないことがよくあります。
The SIPconnect technical recommendations [SIPconnect-TR] aim to solve this problem by providing a central reference that promotes seamless peering between enterprise and service provider SIP networks. However, despite the extensive set of implementation rules and operating guidelines, interoperability issues between service provider and enterprise networks persist. This is in large part because the guidelines of the technical specifications are not hard requirements that can be enforced by the peer. 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 SIPconnect technical recommendations, in that both endeavors aim to promote and achieve interoperability between the enterprise and service provider.
SIPconnect 技術推奨事項 [SIPconnect-TR] は、企業とサービス プロバイダーの SIP ネットワーク間のシームレスなピアリングを促進する一元的なリファレンスを提供することで、この問題を解決することを目的としています。しかし、広範な実装ルールと運用ガイドラインにもかかわらず、サービス プロバイダーと企業ネットワーク間の相互運用性の問題は依然として残ります。これは主に、技術仕様のガイドラインがピアによって強制できる厳しい要件ではないためです。したがって、企業管理者は通常、シームレスなサービス プロバイダーのピアリングを保証する構成ブロックに到達するために、テスト、分析、およびトラブルシューティングのかなり厳密な計画を実行します。ただし、このワークフローは SIPconnect の技術的推奨事項を補完するものであり、どちらの取り組みも企業とサービス プロバイダーの間の相互運用性を促進および実現することを目的としています。
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.
企業管理者がサービス プロバイダーからの一連の技術推奨事項を企業ネットワーク内の 1 つ以上のデバイスにわたる構成ブロックに変換する必要がある場合、別の相互運用性の問題が発生します。これは通常、エラーが発生しやすい作業です。さらに、そのような技術的な推奨事項は、特定の構成ブロックを直感的に生成できるほど微妙ではない可能性があります。
This document introduces the framework for Automatic Peering and Trunking over SIP by 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.
このドキュメントでは、企業ネットワークが SIP サービス プロバイダーから詳細な機能セットを要求できる、SIP 経由の自動ピアリングとトランキングのフレームワークを紹介します。その後、自動化または管理者が詳細な機能セットを使用して、企業ネットワーク内の 1 つ以上のデバイスにわたって構成ブロックを生成し、サービス プロバイダーのピアリングを確実に成功させることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section provides a reference architecture against which the SIP Automatic Peering framework may be implemented. Additionally, terms that are commonly used in the context of the document are defined. Last, considerations for the configuration workflow and the choice of network transport between enterprise and service provider telephony networks are discussed.
このセクションでは、SIP 自動ピアリング フレームワークを実装するためのリファレンス アーキテクチャを提供します。さらに、文書の文脈で一般的に使用される用語が定義されています。最後に、構成ワークフローに関する考慮事項と、企業とサービス プロバイダーのテレフォニー ネットワーク間のネットワーク トランスポートの選択について説明します。
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 Private Branch Exchange (SIP-PBX), media endpoints (ME), and a Session Border Controller (SBC) [RFC7092]. It may also include additional components such as application servers for voicemail, recording, fax, etc. At a high level, the service provider consists of a SIP signaling entity (SP-SSE), a media entity for handling media streams of calls set up by the SP-SSE, and an HTTP [RFC9110] server that stores the capability set document (indicated as Cap Server in Figure 1).
図 1 は、この文書で説明されているメカニズムをサポートするために導入できる参照アーキテクチャを示しています。企業ネットワークは、SIP 構内交換機 (SIP-PBX)、メディア エンドポイント (ME)、およびセッション ボーダー コントローラー (SBC) [RFC7092] で構成されます。また、ボイスメール、録音、FAX などのアプリケーション サーバーなどの追加コンポーネントが含まれる場合もあります。高レベルでは、サービス プロバイダーは、SIP シグナリング エンティティ (SP-SSE)、SP-SSE によって設定された通話のメディア ストリームを処理するメディア エンティティ、および機能セット文書を保存する HTTP [RFC9110] サーバー (図 1 では Cap サーバーとして示されています) で構成されます。
+-----------------------------------------------------+
| +---------------+ +-----------------------+ |
| | | | | |
| | +----------+ | | +-------+ | |
| | | Cap | | HTTPS | | | | |
| | | Server |--|---------|-->| | | |
| | | |<-|---------|---| | +-----+ | |
| | +----------+ | | | |-->|SIP- | | |
| | | | | |<--|PBX | | |
| | | | | | +-----+ | |
| | +----------+ | | | SBC | | |
| | | | | SIP | | | | |
| | | SP-SSE |--|---------|-->| | +-----+ | |
| | | |<-|---------|---| |-->| ME | | |
| | +----------+ | | | |<--| | | |
| | | | | | +-----+ | |
| | +----------+ | (S)RTP | | | | |
| | | Media |--|---------|-->| | | |
| | | |<-|---------|---| | | |
| | +----------+ | | +-------+ | |
| +---------------+ +-----------------------+ |
| |
+-----------------------------------------------------+
Figure 1: Reference Architecture
図 1: リファレンス アーキテクチャ
This document makes use of the following terminology:
このドキュメントでは次の用語が使用されています。
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 such as application servers, endpoints, call agents, and edge devices, among others.
SIP を介してサービス プロバイダー ネットワークと相互接続する、企業によって展開される通信ネットワーク インフラストラクチャ。企業ネットワークには、アプリケーション サーバー、エンドポイント、コール エージェント、エッジ デバイスなどのデバイスが含まれる場合があります。
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) [RFC7092] such as a Session Border Controller (SBC).
企業ネットワークの最後のホップであり、企業に出入りするトラフィックの中継点となるデバイス。エッジ デバイスは通常、セッション ボーダー コントローラー (SBC) などのバックツーバック ユーザー エージェント (B2BUA) [RFC7092] です。
Service Provider Network:
サービスプロバイダーネットワーク:
A communications network infrastructure deployed by service providers. In the context of this document, the service provider network is accessible over SIP for the establishment, modification, and termination of calls and is accessible over HTTP 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.
サービス プロバイダーによって展開される通信ネットワーク インフラストラクチャ。この文書の文脈では、サービス プロバイダー ネットワークは、通話の確立、変更、終了のために SIP 経由でアクセスでき、機能セット文書の転送のために HTTP 経由でアクセスできます。サービス プロバイダー ネットワークは、SIP サービス プロバイダー (SSP) またはインターネット テレフォニー サービス プロバイダー (ITSP) ネットワークとも呼ばれます。
Call Control:
通話制御:
Call control within telephony networks refers to software that is responsible for delivering core telephony functions. Call control not only provides the basic functionality of setting up, sustaining, and terminating calls, but it 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 (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 signaling, 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.
サービス プロバイダー ネットワーク内の一連の特性を総称して指します。これらの特性は、企業ネットワークに通信されると、サービス プロバイダー ネットワークとの相互接続に必要な情報を企業ネットワークに提供します。機能セットを構成するさまざまなパラメータは、シグナリング、メディア、トランスポート、およびセキュリティに固有の特性に関連しています。サービス プロバイダーとの相互接続の特定の側面 (サービス プロバイダー ネットワークとの相互接続に使用されるアクセス テクノロジなど) は、機能セットの範囲外です。
A workflow that enables an enterprise network to solicit the capability set of a SIP service provider ought to take into account the following considerations:
企業ネットワークが SIP サービス プロバイダーの機能セットを要求できるようにするワークフローでは、次の考慮事項を考慮する必要があります。
* 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.
* 構成ワークフローは、サービス プロバイダー ネットワークが企業ネットワークの ID に基づいて、さまざまな機能セットをさまざまな企業ネットワークに動的にオフロードできるように、十分な柔軟性を備えている必要があります。
* 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.
* 構成ワークフローの結果として取得される機能セットのドキュメントは、自動化による簡単な解析に役立つものでなければなりません。その後、自動化を使用して、エッジ要素上または企業ネットワーク内の 1 つ以上の要素にわたって適切な構成ブロックを生成することができます。
Taking the above considerations 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 solicit the service provider capability set. Subsequently, the HTTP 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.
上記の考慮事項を考慮して、この文書では、企業ネットワークがサービス プロバイダーの機能セットを要求し、最終的に取得するために使用できる HTTP ベースのワークフローを提案します。企業ネットワークは、サービス プロバイダーの機能セットを要求するために、整形式の HTTP GET リクエストを作成します。その後、SIP サービス プロバイダーからの HTTP 応答には機能セットが含まれます。機能セットは JSON でエンコードされるため、応答は自動化によって簡単に解析できます。
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 HTTP request:
SIP サービス プロバイダーの機能セットを要求するために、企業ネットワーク内のエッジ要素は、整形式の HTTP GET リクエストを生成します。エンタープライズ エッジ要素が HTTP リクエストを生成することが合理的である理由は 2 つあります。
1. Edge elements are devices that normalize 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.
1. エッジ要素は、メディア プレーンおよびシグナリング プレーンにおける企業ネットワークとサービス プロバイダー ネットワーク間の不一致を正規化するデバイスです。その結果、機能セットが SIP サービス プロバイダー ネットワークから受信されると、エッジ要素は相互接続を可能にする適切な構成ブロックを (場合によっては複数のデバイスにわたって) 生成できます。
2. 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.
2. エッジ要素が企業外部のネットワークと「通信」するように構成されているとすると、NAT トラバーサルとファイアウォール構成の複雑さは最小限になります。
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 to the guidelines of the YANG data model described in this document. 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.
HTTP GET 要求は、SIP サービス プロバイダーによって管理される機能サーバーを対象としており、このサーバーが処理し、要求が正常に処理されると、応答に機能セット ドキュメントが含まれます。機能セットのドキュメントは、このドキュメントで説明されている YANG データ モデルのガイドラインに従って構築されています。成功した応答に含まれる機能セットのドキュメントは JSON 形式です。HTTP リクエストとレスポンスのフォーマットの詳細については、セクション 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 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 the characteristics of the intermediary SIP service provider by leveraging the YANG data model introduced in this document.
企業テレフォニー ネットワークが SIP サービス プロバイダーと相互接続し、2 つのネットワーク間のトラフィックが中間の SIP サービス プロバイダー ネットワークを通過する状況が考えられます。これは、終端 SIP サービス プロバイダー ネットワークと中継 SIP サービス プロバイダー ネットワーク間の相互接続協定の結果である可能性があります。このような状況では、SIP サービス プロバイダーによって企業ネットワークに提供される機能セットは、シグナリングとメディアの観点からトランジット SIP サービス プロバイダー ネットワークの特性を考慮する必要があります。たとえば、終端 SIP サービス プロバイダー ネットワークが G.729 コーデックをサポートし、中継 SIP サービス プロバイダー ネットワークがサポートしていない場合、G.729 を機能セットでアドバタイズしてはなりません。別の例として、トランジット SIP サービス プロバイダー ネットワークが SIP 拡張機能、たとえば [RFC3262] で定義されている信頼性の高い暫定応答用の SIP 拡張機能をサポートしていない場合、終端 SIP サービス プロバイダー ネットワークは、企業ネットワークに提供される機能セットでこの拡張機能のサポートをアドバタイズしてはなりません。終端 SIP サービス プロバイダーが中間 SIP サービス プロバイダー ネットワークの特性をどのように取得するかについては、この文書の範囲外です。ただし、1 つの方法として、終端 SIP サービス プロバイダーが、このドキュメントで紹介されている YANG データ モデルを利用して、中間 SIP サービス プロバイダーの特性を取得することができます。
This section describes the use of HTTP [RFC9110] as a transport protocol for the peering workflow.
このセクションでは、ピアリング ワークフローのトランスポート プロトコルとして HTTP [RFC9110] を使用する方法について説明します。
The workflow defined in this document leverages the HTTP GET method and its corresponding response(s) to request and subsequently obtain the service provider capability set document.
この文書で定義されているワークフローは、HTTP GET メソッドとそれに対応する応答を利用して、サービス プロバイダーの機能セット文書を要求し、その後取得します。
Peering requests and responses are defined over HTTP [RFC9110]. However, due to the sensitive nature of information transmitted between client and server, it is required to secure HTTP communications using Transport Layer Security (TLS) [RFC8446]; therefore, the enterprise edge element and the capability server MUST support TLS 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].
ピアリングのリクエストとレスポンスは HTTP [RFC9110] 上で定義されています。ただし、クライアントとサーバー間で送信される情報は機密性が高いため、Transport Layer Security (TLS) [RFC8446] を使用して HTTP 通信を保護する必要があります。したがって、エンタープライズエッジ要素と機能サーバーは、TLS バージョン 1.2 [RFC5246] 以降 [RFC8446] をサポートしなければなりません (MUST)。HTTP/3 [RFC9114] が使用される場合、TLS は機能セット文書の転送のために QUIC 内に組み込まれます。SIP または RTP-over-QUIC の使用法については、このドキュメントの範囲外です。さらに、エンタープライズエッジ要素と機能サーバーは、[RFC9110] で定義されている https URI スキームの使用をサポートしなければなりません (MUST)。
HTTP usually adopts asymmetric methods of authentication. For example, clients typically use certificate-based authentication to verify the server they are talking to, whereas servers typically use methods such as HTTP digest authentication or OAuth 2.0 [RFC6749] to authenticate clients. Though OAuth 2.0 is not an authentication protocol, it nonetheless allows for client authentication to be carried out with the use of OAuth tokens.
HTTP は通常、非対称の認証方法を採用します。たとえば、クライアントは通常、通信しているサーバーを検証するために証明書ベースの認証を使用しますが、サーバーは通常、クライアントを認証するために HTTP ダイジェスト認証や OAuth 2.0 [RFC6749] などの方法を使用します。OAuth 2.0 は認証プロトコルではありませんが、OAuth トークンを使用してクライアント認証を実行できます。
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.
SIP 自動ピアリング フレームワークのコンテキストでは、クライアント認証を実行するために OAuth 2.0 を使用しなければなりません。エンタープライズ エッジ要素は、機能セット ドキュメントを取得するために、OAuth 2.0 仕様で概要が説明され、サービス プロバイダーによってサポートされているさまざまな許可タイプを使用できます。この文書は、特定の助成金の種類を義務付けるものではありません。機能セットを取得するための OAuth 2.0 の実装については、このドキュメントの範囲を超えています。ただし、図 2 では、エンタープライズ SBC が認可コード付与フロー ([RFC6749] のセクション 4.1) を利用してサービス プロバイダーから機能セット文書を取得する方法の例を示しています。
Using the resource owner password credentials grant type (Section 1.3.3 of [RFC6749]) requires the existence of a trust relationship between the resource owner (in this context, the administrator/enterprise network) and the client (in this context, an edge element such as an SBC). In SIP trunking deployments between enterprise and service provider networks, such a trust relationship between the client (edge element) and the administrator, resource owner, and enterprise network 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.
リソース所有者のパスワード認証情報付与タイプ ([RFC6749] のセクション 1.3.3) を使用するには、リソース所有者 (この文脈では、管理者/エンタープライズ ネットワーク) とクライアント (この文脈では、SBC などのエッジ要素) の間に信頼関係が存在する必要があります。エンタープライズ ネットワークとサービス プロバイダー ネットワーク間の SIP トランキング展開では、SIP トランクの登録 (および登録の更新) には、管理者によってエッジ要素で構成された資格情報 (通常はユーザー名とパスワード) が必要であるため、クライアント (エッジ要素) と管理者、リソース所有者、およびエンタープライズ ネットワークとの間にそのような信頼関係がすでに存在します。ただし、企業ネットワーク管理者とサービス プロバイダーは、この許可タイプに関連するセキュリティ問題を考慮することが重要です。
+---------------+
| Resource |
| Owner |
| (Enterprise) |
+---------------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| Service |
| User | | Provider |
| Agent -+----(B)-- User Authenticates --->| Authorization |
| | | Server |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| (SBC) | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
^ v
| |
| | +--------------+
| -------(F)---- Access Token --------->| Capability |
-----------(G)---- Capability Set -------<| Server |
+--------------+
Figure 2: Client Authentication Mechanism
図 2: クライアント認証メカニズム
The flow illustrated in Figure 2 includes the following steps:
図 2 に示すフローには次のステップが含まれます。
A. 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.
A. エンタープライズ SBC (クライアント) は、リソース所有者 (エンタープライズ ネットワーク管理者) のユーザー エージェントを承認エンドポイントに誘導することによってフローを開始します。SBC には、クライアント識別子、要求されたスコープ、ローカル状態、およびアクセスが許可 (または拒否) された後に認可サーバーがユーザー エージェントを送り返すリダイレクト URI が含まれます。フローの前段階として、エンタープライズ ネットワーク管理者はネットワークの一意のクライアント ID をすでに取得しており、承認コードを取得するためにネットワーク内のターゲットが設定されたリダイレクト URI を提供しています。
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.
B. サービス プロバイダー ネットワーク内の認可サーバーは、(ユーザー エージェントを介して) ネットワーク管理者を認証し、ネットワーク管理者がクライアントのアクセス要求を許可するか拒否するかを確立します。
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 provided by the client earlier.
C. ネットワーク管理者がアクセスを許可すると、認可サーバーは、前に (要求またはクライアント登録中に) 提供されたリダイレクト URI を使用して、ユーザー エージェントをエンタープライズ SBC にリダイレクトします。リダイレクト URI には、認証コードと、クライアントによって以前に提供されたローカル状態が含まれます。
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.
D. エンタープライズ SBC は、前の手順で受信した認可コードを含めて、認可サーバーのトークン エンドポイントからアクセス トークンを要求します。要求を行うとき、エンタープライズ SBC は認可サーバーで認証し、検証用の認可コードを取得するために使用されるリダイレクト URI を含めます。
E. 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.
E. 認可サーバーはエンタープライズ SBC を認証し、認可コードを検証し、受信したリダイレクト URI が手順 (C) で SBC をリダイレクトするために使用された URI と一致することを確認します。有効な場合、認可サーバーはアクセス トークンと、必要に応じてリフレッシュ トークンを返します。
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.
F. 次に、エンタープライズ SBC は、アクセス トークンとともに HTTP GET 要求を使用してサービス プロバイダー ネットワークにある機能サーバーに接続し、機能セット ドキュメントを取得します。
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.
G. 機能サーバーは有効なアクセス トークンをチェックし、機能セット ドキュメントをエンタープライズ SBC に返します。サービス プロバイダーは、ピアリングする企業ネットワークごとに固有のドキュメントをホストします。
The edge element in the enterprise network generates an 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.
企業ネットワーク内のエッジ要素は、セクション 4.5 で概要を説明した手順を使用して要求ターゲットが取得されるように、HTTP GET 要求を生成します。この文書では、コンテンツのネゴシエーションについては規定していません。サーバーは、応答コンテンツ タイプ ヘッダーを application/json メディア タイプに設定しなければなりません。
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:
エンタープライズ エッジ要素からの HTTP GET リクエストは、有効なリクエスト ターゲットを運ばなければなりません。エンタープライズ エッジ要素は、次の 2 つの方法のいずれかで、機能サーバーでホストされているリソースの URL を取得できます。
1. Manual configuration
1. 手動構成
2. Discovery using the WebFinger protocol
2. WebFinger プロトコルを使用した検出
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.
エンタープライズ エッジ要素 (オプション) を認証し、SIP サービス プロバイダーの機能セットを取得するときに使用される完全な https URL は、事前に SIP サービス プロバイダーから取得し、CLI や GUI などのインターフェイスを介してエッジ要素に手動で入力できます。
However, if the resource URL is unknown to the administrator (and by extension, to the edge element), the WebFinger protocol [RFC7033] and the sip-trunking-capability [RFC9409] link relation type may be leveraged assuming that the SIP service provider has implemented WebFinger within their network and hosts the capability set at the respective location.
ただし、リソース URL が管理者 (ひいてはエッジ要素) に不明な場合は、SIP サービス プロバイダーがネットワーク内に WebFinger を実装し、それぞれの場所で機能セットをホストしていると仮定して、WebFinger プロトコル [RFC7033] と sip-trunking-capability [RFC9409] リンク関係タイプを利用できます。
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.
エンタープライズ エッジ要素が ssp1.example.com ドメインでホストされているエンドポイントの URL を検出しようとすると、次のリクエストを発行します。
GET /.well-known/webfinger?
resource=https%3A%2F%2Fssp1.example.com
rel=sipTrunkingCapability
HTTP/1.1
Host: ssp1.example.com
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
"subject" : "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 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.
企業テレフォニー ネットワークによってターゲット URI が取得されると、その URI を逆参照して、その特定の企業テレフォニー ネットワークに固有の固有の機能セット ドキュメントを取得できます。ITSP は、資格情報を使用して企業テレフォニー ネットワークの ID を判断し、適切な機能セットのドキュメントを提供できます。
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 (e.g., an incorrect query parameter in the URI), the capability server MUST generate a "400 Bad Request" status code for the incorrect request. 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.
機能サーバーは、成功した応答の本文に機能セットのドキュメントを含めます。機能セットのドキュメントは JSON でフォーマットする必要があります。不正な形式のリクエスト(例、URI内の不正なクエリパラメータ)の場合、機能サーバーは不正なリクエストに対して「400 Bad Request」ステータスコードを生成しなければなりません(MUST)。リクエストに無効なトークンが含まれている場合、機能サーバーは、このトークンに機能セット文書を表示する権限がないことを明確に示す「403 Forbidden」ステータス コードを生成しなければなりません (MUST)。
The capability server can respond to client requests with redirect status codes (3xx).
機能サーバーは、リダイレクト ステータス コード (3xx) を使用してクライアント要求に応答できます。
The server SHOULD include the Location header field in such responses. If the Location header is not included with the status code, 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.
サーバーは、そのような応答に Location ヘッダーフィールドを含めるべきです (SHOULD)。Location ヘッダーがステータス コードに含まれていない場合、クライアントが機能セット ドキュメントを見つけることができず、ピアリング プロセスで障害が発生したり、管理者による手動介入が必要になったりする可能性があります。
The enterprise edge element SHOULD handle the 3xx status codes from the capability server in accordance with [RFC9110].
エンタープライズエッジ要素は、[RFC9110] に従って、機能サーバーからの 3xx ステータスコードを処理する必要があります (SHOULD)。
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 predefined intervals to obtain 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 if any changes have occurred.
サービス プロバイダーの機能セットが静的なままであることが主に予想されることを考えると、機能セット ドキュメントの小さな変更 (状態デルタ) をエンコードするために非同期プッシュ メカニズムを実装するために必要な作業は、その利点に見合っていません。むしろ、エンタープライズ エッジ要素は、事前定義された間隔で機能サーバーをポーリングして、完全な機能セットのドキュメントを取得できます。機能サーバーは 24 時間ごとにポーリングすることをお勧めします。あるいは、エンタープライズエッジ要素は、[RFC9110] で指定されている前提条件を利用して、変更が発生した場合に条件付きで機能セット文書を取得することもできます。
In the context of this document, 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.
このドキュメントの文脈では、サービス プロバイダーの機能セットとは、企業ネットワークに通信されると、サービス プロバイダー ネットワークと直接ピアリングするのに十分な情報を提供する一連の特性を総称して指します。機能セットのドキュメントは、サービス プロバイダー ネットワークによってサポートされるすべての機能、サービス、およびプロトコル拡張の非常に詳細な詳細をエンコードするように設計されていません。たとえば、サービス プロバイダーが FAX 送信に T.38 リレーを使用することをエンコードするだけで十分です。「T38FaxFillBitRemoval」パラメータの値を知る必要はありません。
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 practices and common problem sets typically seen between enterprise and service provider SIP networks.
機能セット文書内のパラメータは幅広い特性を表しており、これらの特性が集合して、企業ネットワークとサービス プロバイダー ネットワーク間の直接 IP ピアリングを可能にするのに十分な情報を伝達します。機能セットで表されるさまざまなパラメーターは、既存の慣行と、企業とサービス プロバイダーの SIP ネットワーク間で通常見られる共通の問題セットに基づいて選択されます。
This section contains 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)、サービスプロバイダーの機能セットをエンコードするための YANG モジュール [RFC7950] (セクション 7.2)、および機能セットの拡張に関する説明 (セクション 7.3) が含まれています。
The meanings of the symbols in YANG tree diagrams are defined in "YANG Tree Diagrams" [RFC8340].
YANG ツリー図のシンボルの意味は、「YANG Tree Diagrams」[RFC8340] で定義されています。
The data model for the peering capability document has the following 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-tag
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]. In addition, this YANG module references [RFC2833], [RFC4585], [RFC4568], [RFC4733], [RFC4855], [RFC4961], [RFC5764], [RFC6716], [RFC7362], [RFC8555], [RFC9645], [iana-crypt-hash], and [iana-sip-option-tags].
このセクションでは、ピアリング機能セット文書の YANG モジュールを定義します。このモジュールは、共通の YANG データ型 [RFC9911] とシステム管理 [RFC7317] を提供する既存の YANG モジュールに依存しています。さらに、この YANG モジュールは [RFC2833]、[RFC4585]、[RFC4568]、[RFC4733]、[RFC4855]、[RFC4961]、[RFC5764]、[RFC6716]、[RFC7362]、[RFC8555]、[RFC9645]、[iana-crypt-hash]、および [iana-sip-option-tags]。
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.";
}
}
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 {
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.";
}
}
}
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 conversation
between the offnet parties.";
}
leaf symmetric-rtp {
type boolean;
description
"A node indicating whether the SIP service provider
expects the enterprise network to use symmetric RTP.
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/";
}
}
}
There are situations in which equipment manufacturers or service providers would benefit from extending the YANG module defined in this document. 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, and service provider support numbers, among others. Extensions of the module can be achieved by importing the module defined in this document. An example is provided below.
機器メーカーまたはサービスプロバイダーが、この文書で定義されている YANG モジュールを拡張することで恩恵を受ける状況があります。たとえば、サービス プロバイダーは、YANG モジュールを拡張して、ダイレクト IP ピアリングをさらに簡素化する情報を含めることができます。このような情報には、トランク グループ識別子、顧客/企業のアカウント番号、サービス プロバイダーのサポート番号などが含まれる場合があります。モジュールの拡張は、このドキュメントで定義されているモジュールをインポートすることで実現できます。以下に例を示します。
Consider a new YANG module "example-vendor-config" specified for Vendor's enterprise SBC. The "example-vendor-config" YANG module is configured as follows:
ベンダーのエンタープライズ SBC 用に指定された新しい YANG モジュール「example-vendor-config」について考えてみましょう。「example-vendor-config」YANG モジュールは次のように構成されます。
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.";
}
}
}
In the example above, a 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.
上の例では、「example-vendor-config」という名前のカスタム モジュールが、[RFC7950] のセクション 4.2.8 で定義されている「augment」ステートメントを使用して、この文書で定義されているモジュールを拡張しています。
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. Examples of this include 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, and 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.
このセクションでは、SIP サービス プロバイダーの機能セットを取得した後に企業ネットワークによって実行できる手順の非標準的な説明を提供します。エンタープライズ エッジ要素は、機能セットを取得すると、機能セット内のさまざまなフィールドを解析し、構成ブロックを生成できます。この例としては、サービス プロバイダー ネットワークでホストされている SIP レジストラに SIP トランクを正常に登録するために必要な設定、FAX 通話が適切に処理されることを保証するために必要な設定、およびその他多くの設定ブロックの中でも特に、SIP サービス プロバイダーがサポートするオーディオ コーデックのみをアドバタイズするために必要な設定が含まれます。ほぼ同一の SIP サービス プロバイダー機能セット ドキュメントに対して生成される構成ブロックは、ベンダーごとに大幅に異なる可能性があります。
Enterprise edge elements are usually capable of normalizing mismatches in the signaling 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.
エンタープライズ エッジ要素は通常、エンタープライズとサービス プロバイダーの SIP ネットワーク間のシグナリング プレーンとメディア プレーンの不一致を正規化できます。その結果、SIP サービス プロバイダーのピアリングを成功させるために必要な構成ブロックのすべてではないにしても、ほとんどをエッジ要素に追加する必要がある場合があります。構成ブロックを複数のデバイスに分散する必要がある状況では、容量セットの特定のフィールドとそれに対応する値を通信するために、このドキュメントの範囲外である何らかのメカニズムが使用される可能性があります。あるいは、人間の管理者が機能セット文書を調べて、エッジ要素 (および必要に応じて企業ネットワーク内の他のデバイス) を適切に構成することもできます。
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.
このセクションでは、このドキュメントで定義されている YANG モジュールを利用する機能セット ドキュメントを JSON 経由でエンコードする方法と、機能セット ドキュメントを取得するためのエンタープライズ エッジ要素とサービス プロバイダー間のメッセージ交換の例を示します。サービス プロバイダーは、ピアリングする企業ネットワークごとに固有のドキュメントを作成します。
NOTE: '\' line wrapping per [RFC8792].
注: [RFC8792] による「\」行の折り返し。
{
"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"
]
}
}
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 preconfigured with the request target for the capability set document or has dynamically found the request target, the edge element generates an HTTP GET request. This request can be challenged by the service provider to authenticate the enterprise.
このセクションは、最終的にエンタープライズ エッジ要素が SIP サービス プロバイダーから機能セット ドキュメントを取得する構成フローを示す情報例です。エンタープライズ エッジ要素が機能セット ドキュメントのリクエスト ターゲットで事前設定されているか、リクエスト ターゲットを動的に見つけていると仮定すると、エッジ要素は HTTP GET リクエストを生成します。この要求は、企業を認証するためにサービス プロバイダーによって要求されることがあります。
GET /capdoc?trunkid=trunkent1456 HTTP/1.1
Host: capserver.ssp1.com
Authorization: Bearer <clientToken>
The capability set document is obtained in the body of the response and is encoded in JSON.
機能セットのドキュメントは応答の本文で取得され、JSON でエンコードされます。
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: nnn
{
"ietf-sip-auto-peering:sip-auto-peering": ...
}
This document registers two new URIs in the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registrations have been made.
この文書は、「IETF XML Registry」[RFC3688] に 2 つの新しい URI を登録します。[RFC3688]のフォーマットに従い、以下の登録が行われています。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering
urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering
Registrant Contact:
登録者の連絡先:
The IESG.
IESG。
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
URI:
URI:
urn:ietf:params:xml:ns:yang:iana-sip-option-tags
urn:ietf:params:xml:ns:yang:iana-sip-option-tags
Registrant Contact:
登録者の連絡先:
The IESG.
IESG。
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
This document registers two new YANG modules in the "YANG Module Names" registry [RFC6020].
この文書は、2 つの新しい YANG モジュールを「YANG Module Names」レジストリ [RFC6020] に登録します。
Name:
名前：
ietf-sip-auto-peering
ietf-sip-自動ピアリング
Maintained by IANA?
IANAによって保守されていますか？
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering
urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering
Prefix:
プレフィックス:
sipap
シパプ
Reference:
参照：
RFC 10006
RFC 10006
Name:
名前：
iana-sip-option-tags
iana-sip-オプション-タグ
Maintained by IANA?
IANAによって保守されていますか？
Y
Y
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:iana-sip-option-tags
urn:ietf:params:xml:ns:yang:iana-sip-option-tags
Prefix:
プレフィックス:
sip-option-tags
sip-オプション-タグ
Reference:
参照：
RFC 10006
RFC 10006
This document defines the initial version of the IANA-maintained "iana-sip-option-tags" YANG module. The most recent version of the YANG module is available in the "YANG Parameters" registry group [YANG-PARAMS].
この文書は、IANA が管理する「iana-sip-option-tags」YANG モジュールの初期バージョンを定義します。YANG モジュールの最新バージョンは、「YANG パラメータ」レジストリ グループ [YANG-PARAMS] で入手できます。
IANA has added the following to the "Notes" field of the "iana-sip-option-tags" entry in the "YANG Module Names" registry within the "YANG Parameters" registry group:
IANA は、「YANG Parameters」レジストリ グループ内の「YANG Module Names」レジストリの「iana-sip-option-tags」エントリの「Notes」フィールドに次の内容を追加しました。
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].
新しい値を「iana-sip-option-tags」YANG モジュールに直接追加しないでください。代わりに、それらを「オプション タグ」レジストリ [SIP-PARAMS] に追加する必要があります。
When a value is added to the "Option Tags" registry, a new "enum" statement must be added to the "iana-sip-option-tags" YANG module. The "enum" statement, and substatements thereof, should be defined:
「オプション タグ」レジストリに値を追加するときは、新しい「enum」ステートメントを「iana-sip-option-tags」YANG モジュールに追加する必要があります。「enum」ステートメントとそのサブステートメントは次のように定義する必要があります。
"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 present in the module.
未割り当てまたは予約された値はモジュール内に存在しません。
When the "iana-sip-option-tags" YANG module is updated, a new "revision" statement with a unique revision date needs to be added in front of the existing "revision" statements. The "revision" statement MUST contain both "description" and "reference" substatements as follows.
「iana-sip-option-tags」YANG モジュールが更新されると、固有の改訂日を持つ新しい「revision」ステートメントを既存の「revision」ステートメントの前に追加する必要があります。「revision」ステートメントには、次のように「description」サブステートメントと「reference」サブステートメントの両方を含める必要があります。
The "description" substatement captures what changed in the revised version. Typically, the description enumerates the changes such as updates to existing entries (e.g., update a description or a reference) or notes about which "enums" were added or had their status changed (e.g., deprecated, discouraged, or obsoleted).
「説明」サブステートメントには、改訂版での変更点が記載されています。通常、説明には、既存のエントリの更新 (例: 説明やリファレンスの更新)、またはどの「列挙型」が追加されたか、ステータスが変更された (例: 非推奨、非推奨、廃止) などの変更が列挙されます。
When such a description is not feasible, the description varies on how the update is triggered.
このような説明が実現できない場合、更新がどのようにトリガーされるかによって説明が異なります。
* If the update is triggered by an RFC, the "description" substatement should include or consist of this text:
* 更新が RFC によってトリガーされる場合、「説明」サブステートメントには次のテキストが含まれるか、次のテキストで構成される必要があります。
Applied updates as specified by RFC 10006.
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]):
* 別の IANA 登録ポリシーに従って更新がトリガーされたが、レジストリ内のすべての値が同じポリシーでカバーされているわけではない場合は、次のテキストを挿入します (「Some_IANA_policy」は [RFC8126] のセクション 4 で定義されている登録ポリシーの 1 つを指します)。
Applied updates as specified by the registration policy Some_IANA_policy.
登録ポリシー Some_IANA_policy の指定に従って更新を適用しました。
The "reference" substatement points specifically to the published module at [YANG-PARAMS]. It may also point to an authoritative event triggering the update to the YANG module. In all cases, this event is cited from the underlying IANA registry. If the update is triggered by an RFC, that RFC must also be included in the "reference" substatement.
「reference」サブステートメントは、[YANG-PARAMS] で公開されているモジュールを具体的に指します。また、YANG モジュールの更新をトリガーする権限のあるイベントを指す場合もあります。いずれの場合も、このイベントは基礎となる IANA レジストリから引用されています。更新が RFC によってトリガーされる場合、その RFC も「reference」サブステートメントに含める必要があります。
IANA has added this note to the "Option Tags" registry within the "Session Initiation Protocol (SIP) Parameters" registry group [SIP-PARAMS]:
IANA は、次のメモを「セッション開始プロトコル (SIP) パラメーター」レジストリ グループ [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.
このレジストリを変更する場合は、YANG モジュール「iana-sip-option-tags」<https://www.iana.org/assignments/iana-sip-option-tags> を RFC 10006 の定義に従って更新する必要があります。
The service provider will filter out the advertised extensions using local policy.
サービス プロバイダーは、ローカル ポリシーを使用して、アドバタイズされた拡張機能をフィルターで除外します。
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.
ASAP ワークフローには複数の攻撃ポイントがあります。以下のセクションでは、ワークフローが攻撃者に対して脆弱になるさまざまな点について説明します。
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.
OAuth リソース所有者の資格情報を使用してクライアント認証が実行されるシナリオでは、これらの資格情報が無許可の第三者によって取得されないようにする必要があります。許可されていない第三者によって取得された場合、これらの資格情報は、SIP サービス プロバイダーから機能セット文書を取得するために使用され、その後、そのような文書内の情報を使用して、SIP サービス プロバイダーから通話サービスに対して正当に料金を支払った企業テレフォニー ネットワークを装いながら、不正な通話を行う可能性があります。
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 Authorization header field provided in response to authentication challenges.
機能サーバーから機能セット文書を取得するためにエッジ要素によって使用されるすべての通信は、HTTPS を使用して保護されなければなりません (MUST)。これを行わないと、機能セット文書がクリア テキストで送信されることになり、トランク登録のターゲット、アウトバウンド通話要求のターゲット、認証チャレンジに応じて提供される Authorization ヘッダー フィールドの構築に使用される資格情報などの機密情報が公開されます。
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 exhibited in Section 9. The service provider communicates the URL of this JSON file in an out-of-band manner to the enterprise. Alternatively, the enterprise uses WebFinger to discover the URL of the JSON file. The enterprise SBC downloads the JSON file and parses it. Once it has validated that the JSON file is correctly formatted, it applies the configuration and peers with the service provider's network for SIP calls to occur.
「ietf-sip-auto-peering」YANG モジュールは、サービス プロバイダーが機能セット ドキュメントを作成する際に、できれば自動化された方法で従わなければならないデータ モデルを定義します。機能セット文書は、セクション 9 で示されているように、JSON ファイルとしてフォーマットされる必要があります (SHOULD)。サービスプロバイダーは、この JSON ファイルの URL を帯域外方式で企業に通信します。あるいは、企業は WebFinger を使用して JSON ファイルの URL を検出します。エンタープライズ SBC は JSON ファイルをダウンロードして解析します。JSON ファイルが正しくフォーマットされていることが検証されると、設定が適用され、SIP コールが発生するようにサービス プロバイダーのネットワークとピアリングされます。
It is possible that enterprises may purchase numbers in different countries or regions. In this scenario, 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 capability set document cannot be modified by the enterprise. It can only be created one time by the service provider for each enterprise entering into an agreement with the service provider. Therefore, there are no particularly sensitive writable data nodes.
企業が異なる国または地域で番号を購入する可能性があります。このシナリオでは、企業とサービス プロバイダーの間に複数の SIP トランクが存在します。サービス プロバイダーは、各 SIP トランクの機能セット文書を作成する責任があります。企業は機能セット文書を変更できません。サービス プロバイダーは、サービス プロバイダーと契約を結ぶ企業ごとに 1 回だけ作成できます。したがって、特に機密性の高い書き込み可能なデータ ノードはありません。
There are no particularly sensitive writable data nodes.
特に機密性の高い書き込み可能なデータ ノードはありません。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:
この YANG モジュールの読み取り可能なデータ ノードの一部は、一部のネットワーク環境では機密であるか脆弱であると見なされる場合があります。したがって、これらのデータ ノードへの読み取りアクセス (get、get-config、通知など) を制御することが重要です。具体的には、次のサブツリーとデータ ノードには特定の感度/脆弱性があります。
* registrar: This list contains IP addresses or hostnames belonging to registration servers in the service provider network, which may be targeted by malicious actors.
* レジストラ: このリストには、サービス プロバイダー ネットワーク内の登録サーバーに属する IP アドレスまたはホスト名が含まれており、悪意のある攻撃者の標的となる可能性があります。
* 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.
* call-control: このリストには、サービス プロバイダー ネットワーク内の通話処理サーバーに属する IP アドレスまたはホスト名が含まれており、悪意のある攻撃者の標的となる可能性があります。
* 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.
* outbound-proxy: このリストには、サービス プロバイダー ネットワーク内の SIP プロキシに属する IP アドレスまたはホスト名が含まれており、悪意のある攻撃者の標的となる可能性があります。
* 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.
特に機密性の高い RPC 操作やアクション操作はありません。
This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to the Security Considerations of [RFC9911] and [RFC7317] for information as to which nodes may be considered sensitive or vulnerable in network environments.
この YANG モジュールは、ネットワーク環境で機密または脆弱であると考えられるノードを定義する他の YANG モジュールのグループを使用します。ネットワーク環境においてどのノードが機密であるか脆弱であるとみなされるかについては、[RFC9911] および [RFC7317] のセキュリティに関する考慮事項を参照してください。
The YANG module "iana-sip-option-tags" defines a set of types. These nodes are intended to be reused by other YANG modules. This module by itself does not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to this YANG module that need to be considered.
YANG モジュール「iana-sip-option-tags」は、タイプのセットを定義します。これらのノードは、他の YANG モジュールによって再利用されることを目的としています。このモジュール自体は、書き込み可能なデータ ノード、読み取り専用状態を含むデータ ノード、または RPC を公開しません。そのため、この YANG モジュールに関連して考慮する必要のある追加のセキュリティ問題はありません。
[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>.
[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>.
There are alternative mechanisms that the SIP service provider can use to offload its capability set. For example, the Session Initiation Protocol (SIP) can be extended to define a new event package [RFC6665], such that the enterprise network can establish a SIP subscription with the service provider for its capability set; the SIP service provider can subsequently use the SIP NOTIFY request to communicate its capability set or any state deltas to its baseline capability set.
SIP サービス プロバイダーがその機能セットをオフロードするために使用できる代替メカニズムがあります。たとえば、Session Initiation Protocol (SIP) を拡張して新しいイベント パッケージ [RFC6665] を定義し、企業ネットワークがその機能セットに対してサービス プロバイダーとの SIP サブスクリプションを確立できるようにすることができます。その後、SIP サービス プロバイダーは、SIP NOTIFY リクエストを使用して、その機能セットまたは任意の状態デルタをそのベースライン機能セットに伝達できます。
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. An HTTP-based approach would be relatively easier to adopt, as most edge devices deployed in enterprise networks today already support HTTP; from the perspective of service provider networks, all that is required is for them to deploy HTTP 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.
機器メーカーは最初にそのような SIP 拡張機能のサポートを追加する必要があるため、このメカニズムは SIP サービス プロバイダーや企業ネットワークの導入に障壁となる可能性があります。現在、企業ネットワークに導入されているほとんどのエッジ デバイスはすでに HTTP をサポートしているため、HTTP ベースのアプローチは比較的採用が容易です。サービス プロバイダー ネットワークの観点から見ると、必要なのは、機能サーバーとして機能する HTTP サーバーを展開することだけです。さらに、ほとんどの SIP サービス プロバイダーでは、サブスクリプション (SIP SUBSCRIBE) または通話 (SIP INVITE) を開始する他の SIP メソッドが処理される前に、エンタープライズ ネットワークが (SIP REGISTER メッセージを使用して) 登録する必要があります。その結果、機能セットを取得するための SIP ベースのフレームワークでは、サービス プロバイダー ネットワークの側で運用上の変更が必要になります。
Yet another example of an alternative mechanism would be for service providers and enterprise equipment manufacturers to agree on YANG data models [RFC6020] [RFC7950] that enable configuration to be pushed over NETCONF [RFC6241] to enterprise networks from a centralized 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 data 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.
代替メカニズムのさらに別の例は、サービス プロバイダーと企業機器メーカーが、サービス プロバイダー ネットワークでホストされている集中ソースから NETCONF [RFC6241] を介して企業ネットワークに設定をプッシュできるようにする YANG データ モデル [RFC6020] [RFC7950] に合意することです。エンタープライズ デバイスに通話とメディア処理のための独自のソフトウェア ロジックが存在すると、「万能の」YANG データ モデルを生成できなくなります。さらに、サービス プロバイダー ネットワークが企業デバイスに設定をプッシュすると、企業ネットワーク側の実装の自主性が失われる可能性があります。
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.
この文書に関して詳細かつ思慮深いコメントを提供してくださった方々、特に Marc Petit-Huguenin、Paul Jones、Ram Mohan R、Nicola Serafini、Jonathan Rosenberg、Jon Peterson、Chris Wendt、Henning Schulzrinne に感謝いたします。さらに、レビューとフィードバックを提供してくれた Murray Kucherawy、Joel Halpern、Dan Harkins、Éric Vyncke、Joerg Ott、Mahesh Jethanandani、Orie Steele、Harald Alvestro、Ebben Aries、Jen Linkova、David Dong、Gorry Fairhurst、Mohamed Boucadair、Paul Wouters、Mike Bishop、Andy Newton、Amanda Baber に感謝します。
Kaustubh Inamdar
Unaffiliated
Email: kaustubh.ietf@gmail.com
Sreekanth Narayanan
Unaffiliated
Email: sknth.n@protonmail.com
Cullen Jennings
Cisco Systems
Email: fluffy@iii.ca