idnits 2.17.1 draft-ietf-asap-sip-auto-peer-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 9 instances of too long lines in the document, the longest one being 34 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 June 2021) is 1053 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 849, but not defined == Missing Reference: '1-9' is mentioned on line 848, but not defined == Missing Reference: '0-4' is mentioned on line 615, but not defined == Missing Reference: '0-5' is mentioned on line 615, but not defined == Missing Reference: '1-5' is mentioned on line 647, but not defined == Missing Reference: '1-4' is mentioned on line 646, but not defined == Missing Reference: '1-2' is mentioned on line 647, but not defined -- Looks like a reference, but probably isn't: '01' on line 615 == Missing Reference: 'TBD' is mentioned on line 1484, but not defined == Unused Reference: 'RFC2119' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: 'RFC2833' is defined on line 1493, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 1498, but no explicit reference was found in the text == Unused Reference: 'RFC4585' is defined on line 1504, but no explicit reference was found in the text == Unused Reference: 'RFC4733' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'RFC4855' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'RFC4961' is defined on line 1519, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1523, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 1528, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1533, but no explicit reference was found in the text == Unused Reference: 'RFC6665' is defined on line 1538, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 1542, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1546, but no explicit reference was found in the text == Unused Reference: 'RFC7033' is defined on line 1550, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 1554, but no explicit reference was found in the text == Unused Reference: 'RFC7362' is defined on line 1559, but no explicit reference was found in the text == Unused Reference: 'RFC8340' is defined on line 1564, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 1568, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2833 (Obsoleted by RFC 4733, RFC 4734) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 7362 Summary: 6 errors (**), 0 flaws (~~), 30 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ASAP K. Inamdar 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track S. Narayanan 5 Expires: 9 December 2021 C. Jennings 6 Cisco Systems 7 7 June 2021 9 Automatic Peering for SIP Trunks 10 draft-ietf-asap-sip-auto-peer-02 12 Abstract 14 This draft specifies a configuration workflow to enable enterprise 15 Session Initiation Protocol (SIP) networks to solicit the capability 16 set of a SIP service provider network. The capability set can 17 subsequently be used to configure features and services on the 18 enterprise edge element, such as a Session Border Controller (SBC), 19 to ensure smooth peering between enterprise and service provider 20 networks. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 9 December 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 4 57 2.1. Reference Architecture . . . . . . . . . . . . . . . . . 4 58 2.2. Configuration Workflow . . . . . . . . . . . . . . . . . 5 59 2.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 8 61 4. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8 64 4.3. Authenticated Client Identity . . . . . . . . . . . . . . 9 65 4.4. Encoding the Request . . . . . . . . . . . . . . . . . . 9 66 4.5. Identifying the Request Target . . . . . . . . . . . . . 9 67 4.6. Generating the response . . . . . . . . . . . . . . . . . 10 68 5. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Encoding the Service Provider Capability Set . . . . . . . . 11 70 7. Data Model for Capability Set . . . . . . . . . . . . . . . . 12 71 7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 72 7.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 20 74 7.4. Extending the Capability Set . . . . . . . . . . . . . . 29 75 8. Processing the Capability Set Response . . . . . . . . . . . 30 76 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 77 9.1. XML Capability Set Document . . . . . . . . . . . . . . . 31 78 9.2. Example Exchange . . . . . . . . . . . . . . . . . . . . 33 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 81 12. Normative References . . . . . . . . . . . . . . . . . . . . 33 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 84 1. Introduction 86 The deployment of a Session Initiation Protocol [RFC 3261 87 (https://tools.ietf.org/html/rfc3261)] (SIP)-based infrastructure in 88 enterprise and service provider communication networks is increasing 89 at a rapid pace. Consequently, direct IP peering between enterprise 90 and service provider networks is quickly replacing traditional 91 methods of interconnection between enterprise and service provider 92 networks. Currently published standards provide a strong foundation 93 over which direct IP peering can be realized. However, given the 94 sheer number of these standards, it is often not clear which 95 behavioral subsets, extensions to baseline protocols and operating 96 principles ought to be implemented by service provider and enterprise 97 networks to ensure successful peering. 99 The SIP Connect technical recommendations 100 (https://www.sipforum.org/download/sipconnect-technical- 101 recommendation-version-2-0/?wpdmdl=2818) aim to solve this problem by 102 providing a master reference that promotes seamless peering between 103 enterprise and service provider SIP networks. However, despite the 104 extensive set of implementation rules and operating guidelines, 105 interoperability issues between service provider and enterprise 106 networks persist. This is in large part because service providers 107 and equipment manufacturers aren't required to enforce the guidelines 108 of the technical specifications and have a fair degree of freedom to 109 deviate from them. Consequently, enterprise administrators usually 110 undertake a fairly rigorous regimen of testing, analysis and 111 troubleshooting to arrive at a configuration block that ensures 112 seamless service provider peering. However, this workflow 113 complements the SIP Connect technical recommendations, in that both 114 endeavours aim to promote/achieve interop between the enterprise and 115 service provider. 117 Another set of interoperability problems arise when enterprise 118 administrators are required to translate a set of technical 119 recommendations from service providers to configuration blocks across 120 one or more devices in the enterprise, which is usually an error 121 prone exercise. Additionally, such technical recommendations might 122 not be nuanced enough to intuitively allow the generation of specific 123 configuration blocks. 125 This draft introduces a mechanism using which an enterprise network 126 can solicit a detailed capability set from a SIP service provider; 127 the detailed capability set can subsequently be used by automaton or 128 an administrator to generate configuration blocks across one or more 129 devices within the enterprise to ensure successful service provider 130 peering. 132 2. Overview of Operations 134 This section details the configuration workflow proposed by this 135 draft. 137 2.1. Reference Architecture 139 Figure 1 illustrates a reference architecture that may be deployed to 140 support the mechanism described in this document. The enterprise 141 network consists of a SIP-PBX, media endpoints and a Session Border 142 Controller [RFC 7092 (https://tools.ietf.org/html/rfc7092)]. It may 143 also include additional components such as application servers for 144 voicemail, recording, fax etc. At a high level, the service provider 145 consists of a SIP signaling entity (SP-SSE), a media entity and a 146 HTTPS [RFC 7231 (https://tools.ietf.org/html/rfc7231)] server. 148 +-----------------------------------------------------+ 149 | +---------------+ +-----------------------+ | 150 | | | | | | 151 | | +----------+ | | +-------+ | | 152 | | | Cap | | HTTPS | | | | | 153 | | | Server |<-|---------|-->| | | | 154 | | | | | | | | +-----+ | | 155 | | +----------+ | | | | | SIP | | | 156 | | | | | |<->| PBX | | | 157 | | | | | | +-----+ | | 158 | | +----------+ | | | SBC | | | 159 | | | | | SIP | | | | | 160 | | | SP - SSE |<-|---------|-->| | +-----+ | | 161 | | | | | | | |<->| M.E.| | | 162 | | +----------+ | | | | | | | | 163 | | | | | | +-----+ | | 164 | | +----------+ | (S)RTP | | | | | 165 | | | Media |<-|---------|-->+-------+ | | 166 | | +----------+ | | | | 167 | +---------------+ +-----------------------+ | 168 | | 169 +-----------------------------------------------------+ 171 Figure 1: Reference Architecture 173 This draft makes use of the following terminology: 175 * Enterprise Network: A communications network infrastructure 176 deployed by an enterprise which interconnects with the service 177 provider network over SIP. The enterprise network could include 178 devices such as application servers, endpoints, call agents and 179 edge devices, among others. 181 * Edge Device: A device that is the last hop in the enterprise 182 network and that is the transit point for traffic entering and 183 leaving the enterprise. An edge device is typically a back-to- 184 back user agent (B2BUA) [RFC 7092 (https://tools.ietf.org/html/ 185 rfc7092)] such as a Session Border Controller (SBC). 187 * Service Provider Network: A communications network infrastructure 188 deployed by service providers. In the context of this draft, the 189 service provider network is accessible over SIP for the 190 establishment, modification and termination of calls and 191 accessible over HTTPS for the transfer of the capability set 192 document. The service provider network is also referred to as a 193 SIP Service Provider (SSP) or Internet Telephony Service Provider 194 (ITSP) network. 196 * Call Control: Call Control within a telephony networks refers to 197 software that is responsible for delivering its core 198 functionality. Call control not only provides the basic 199 functionality of setting up, sustaining and terminating calls, but 200 also provides the necessary control and logic required for 201 additional services within the telephony network. 203 * Capability Server: A server hosted in the service provider 204 network, such that this server is the target for capability set 205 document requests from the enterprise network. 207 * Capability Set: The term capability set (or capability set 208 document) refers collectively to a set of characteristics within 209 the service provider network, which when communicated to the 210 enterprise network, provides the enterprise network the 211 information required to interconnect with the service provider 212 network. The various parameters that constitute the capability 213 set relate to characteristics that are specific to signalling, 214 media, transport and security. Certain aspects of interconnecting 215 with service providers are out of scope of the capability set. 216 For example, the access technology used to interconnect with 217 service provider networks. 219 2.2. Configuration Workflow 221 A workflow that facilitates an enterprise network to solicit the 222 capability set of a SIP service provider ought to take into account 223 the following considerations: 225 * The configuration workflow must be based on a protocol or a set of 226 protocols commonly used between enterprise and service provider 227 telephony networks. 229 * The configuration workflow must be flexible enough to allow the 230 service provider network to dynamically offload different 231 capability sets to different enterprise networks based on the 232 identity of the enterprise network. 234 * Capability set documents obtained as a result of the configuration 235 workflow must be conducive to easy parsing by automaton. 236 Subsequently, automaton may be used for generation of appropriate 237 configuration blocks. 239 Taking the above considerations into account, this document proposes 240 a Hypertext Transfer Protocol (HTTP)-based workflow using which the 241 enterprise network can solicit and ultimately obtain the service 242 provider capability set. The enterprise network creates a well 243 formed HTTPS GET request to solicit the service provider capability 244 set. Subsequently, the HTTPS response from the SIP service provider 245 includes the capability set. The capability set is encoded in either 246 XML or JSON, thus ensuring that the response can be easily parsed by 247 automaton. 249 There are alternative mechanisms using which the SIP service provider 250 can offload its capability set. For example, the Session Initiation 251 Protocol (SIP) can be extended to define a new event package [RFC 252 6665 (https://tools.ietf.org/html/rfc6665)], such that the enterprise 253 network can establish a SIP subscription with the service provider 254 for its capability set; the SIP service provider can subsequently use 255 the SIP NOTIFY request to communicate its capability set or any state 256 deltas to its baseline capability set. 258 This mechanism is likely to result in a barrier to adoption for SIP 259 service providers and enterprise networks as equipment manufacturers 260 would have to first add support for such a SIP extension. A HTTPS- 261 based approach would be relatively easier to adopt as most edge 262 devices deployed in enterprise networks today already support HTTPS; 263 from the perspective of service provider networks, all that is 264 required is for them to deploy HTTPS servers that function as 265 capability servers. Additionally, most SIP service providers require 266 enterprise networks to register with them (using a SIP REGISTER 267 message) before any other SIP methods that initiate subscriptions 268 (SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a 269 SIP-based framework to obtain a capability set would require 270 operational changes on the part of service provider networks. 272 Yet another example of an alternative mechanism would be for service 273 providers and enterprise equipment manufacturers to agree on YANG 274 models [RFC 6020 (https://tools.ietf.org/html/rfc6020)] that enable 275 configuration to be pushed over NETCONF [RFC 6241 276 (https://tools.ietf.org/html/rfc6241)] to enterprise networks from a 277 centralised source hosted in service provider networks. The presence 278 of proprietary software logic for call and media handling in 279 enterprise devices would preclude the generation of a "one-size-fits- 280 all" YANG model. Additionally, service provider networks pushing 281 configuration to enterprises devices might lead to the loss of 282 implementation autonomy on the part of the enterprise network. 284 2.3. Transport 286 To solicit the capability set of a SIP service provider, the edge 287 element in an enterprise network generates a well-formed HTTPS GET 288 request. There are two reasons why it makes sense for the enterprise 289 edge element to generate the HTTPS request: 291 1. Edge elements are devices that normalise any mismatches between 292 the enterprise and service provider networks in the media and 293 signaling planes. As a result, when the capability set is 294 received from the SIP service provider network, the edge element 295 can generate appropriate configuration blocks (possibly across 296 multiple devices) to enable interconnection. 298 2. Given that edge elements are configured to "talk" to networks 299 external to the enterprise, the complexity in terms of NAT 300 traversal and firewall configuration would be minimal. 302 The HTTPS GET request is targeted at a capability server that is 303 managed by the SIP service provider such that this server processes, 304 and on successfully processing the request, includes the capability 305 set document in the response. The capability set document is 306 constructed according the guidelines of the YANG model described in 307 this draft. The capability set document included in a successful 308 response is formatted in either XML or JSON. The formatting depends 309 on the value of the "Accept" header field of the HTTP GET request. 310 More details about the formatting of the HTTP request and response 311 are provided in Section 4. 313 There could be situations wherein an enterprise telephony network 314 interconnects with its SIP service provider such that traffic between 315 the two networks traverses an intermediary SIP service provider 316 network. This could be a result of interconnect agreements between 317 the terminating and transit SIP service provider networks. In such 318 situations, the capability set provided to the enterprise network by 319 its SIP service provider must account for the characteristics of the 320 transit SIP service provider network from a signalling and media 321 perspective. For example, if the terminating SIP service provider 322 network supports the G.729 codec and the transit SIP service provider 323 network does not, G.729 must not be advertised in the capability set. 324 As another example, if the transit SIP service provider network 325 doesn't support a SIP extension, for instance, the SIP extension for 326 Reliable Provisional Responses as defined in RFC 3262, the 327 terminating SIP service provider network must not advertise support 328 for this extension in the capability set provided to the enterprise 329 network. How a terminating SIP service provider obtains the 330 characteristics of the intermediary SIP service provider network is 331 out of the scope of this document; however, one method could be for 332 the terminating SIP service provider to obtain the characteristics of 333 the intermediary SIP service provider by leveraging the YANG model 334 introduced in this document. 336 3. Conventions and Terminology 338 The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 339 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 340 this document are to be interpreted as described in BCP 14 341 (https://www.rfc-editor.org/refs/ref-bcp14.txt) 343 4. HTTP Transport 345 This section describes the use of HTTPS as a transport protocol for 346 the peering workflow. This workflow is based on HTTP version 1.1, 347 and as such is compatible with any future version of HTTP that is 348 backward compatible with HTTP 1.1. 350 4.1. HTTP Methods 352 The workflow defined in this document leverages the HTTPS GET method 353 and its corresponding response(s) to request for and subsequently 354 obtain the service provider capability set document. 356 4.2. Integrity and Confidentiality 358 Peering requests and responses are defined over HTTPS. However, due 359 to the sensitive nature of information transmitted between client and 360 server, it is required to secure HTTP using Transport Layer Security 361 [RFC 5246 (https://tools.ietf.org/html/rfc5246)]. The enterprise 362 edge element and capability server MUST be compliant with RFC 7235 363 (https://tools.ietf.org/html/rfc7235). The enterprise edge element 364 and capability server MUST support the use of the HTTPS uri scheme as 365 defined in RFC 7230 (https://tools.ietf.org/html/rfc7230). 367 4.3. Authenticated Client Identity 369 It is only required for the SIP service provider to authenticate the 370 client (enterprise edge element). How the SIP service provider 371 authenticates the client is out of the scope of this document, 372 however, methods such as HTTP Digest Authentication or validation of 373 the hostname presented in the certificate during the TLS exchange may 374 be used. 376 4.4. Encoding the Request 378 The edge element in the enterprise network generates a HTTPS GET 379 request such that the request-target is obtained using the procedure 380 outlined in section 6.6 The MIME types for the capability set 381 document defined in this draft are "application/peering-info+json" 382 and "application/peering-info+xml". Accordingly, the Accept header 383 field value MUST be restricted only to these MIME types. It is 384 possible that the edge element supports responses formatted in both 385 JSON and XML. In such situations, the edge element might generate a 386 HTTPS GET request such that the Accept header field includes both 387 MIME types along with the corresponding "qvalue" for each MIME type. 389 The generated HTTPS GET request MUST NOT use the "Expect" and "Range" 390 header fields. The requests MUST also not use any conditional 391 request. 393 4.5. Identifying the Request Target 395 HTTPS GET requests from enterprise edge elements MUST carry a valid 396 request-target. The enterprise edge element might obtain the URL of 397 the resource hosted on the capability server in one of two ways: 399 1. Manual Configuration 401 2. Discovery using the Webfinger Protocol 403 The complete HTTPS URLs to be used when authenticating the enterprise 404 edge element (optional) and obtaining the SIP service provider 405 capability set can be obtained from the SIP service provider 406 beforehand and entered into the edge element manually via some 407 interface - for example, a CLI or GUI. 409 However, if the resource URL is unknown to the administrator (and by 410 extension of that to the edge element), the WebFinger protocol RFC 411 7033 (https://tools.ietf.org/html/rfc5764) may be leveraged. 413 If an enterprise edge element attempts to discover the URL of the 414 endpoints hosted in the ssp1.example.com domain, it issues the 415 following request (line wraps are for display purposes only). 417 GET /.well-known/webfinger? 418 resource=http%3A%2F%2Fssp1.example.com 419 rel=capabilitySet 420 HTTP/1.1 421 Host: ssp1.example.com 423 HTTP/1.1 200 OK 424 Access-Control-Allow-Origin: * 425 Content-Type: application/jrd+json 426 { 427 "subject" : "http://ssp1.example.com", 428 "links" : 429 [ 430 { 431 "rel" : "capabilitySet", 432 "href" :"https://capserver.ssp1.com/capserver/capdoc.xml" 433 }, 434 ] 435 } 437 Once the target URI is obtained by an enterprise telephony network, 438 the URI may be dereferenced to obtain a unique capability set 439 document that is specific to that given enterprise telephony network. 440 The ITSP may use credentials to determine the identity of the 441 enterprise telephony network and provide the appropriate capability 442 set document. 444 TODO: Should we have a new link-relation type registered for ASAP? 446 4.6. Generating the response 448 Capability servers include the capability set documents in the body 449 of a successful response. Capability set documents MUST be formatted 450 in XML or JSON. For requests that are incorrectly formatted, the 451 capability server must generate a "400 Bad Request" response. If the 452 client (enterprise edge element) includes any other MIME types in 453 Accept header field other than "application/peering-info+json" or 454 "application/peering-info+xml", the capability set must reject the 455 request with a "406 Not Acceptable" response. 457 The capability server can respond to client requests with redirect 458 responses, specifically, the server can respond with the following 459 redirect responses: 461 1. 301 Moved Temporarily 463 2. 302 Found 465 3. 307 Temporary Redirect 467 The server SHOULD include the Location header field in such 468 responses. 470 5. State Deltas 472 Given that the service provider capability set is largely expected to 473 remain static, the work needed to implement an asynchronous push 474 mechanism to encode minor changes in the capability set document 475 (state deltas) is not commensurate with the benefits. Rather, 476 enterprise edge elements can poll capability servers at pre-defined 477 intervals to obtain the full capability set document. It is 478 recommended that capability servers are polled every 24 hours. 480 6. Encoding the Service Provider Capability Set 482 In the context of this draft, the capability set of a service 483 provider refers collectively to a set of characteristics which when 484 communicated to an enterprise network, provides it with sufficient 485 information to directly peer with the service provider network. The 486 capability set document is not designed to encode extremely granular 487 details of all features, services, and protocol extensions that are 488 supported by the service provider network. For example, it is 489 sufficient to encode that the service provider uses T.38 relay for 490 faxing, it is not required to know the value of the 491 "T38FaxFillBitRemoval" parameter. 493 The parameters within the capability set document represent a wide 494 array of characteristics, such that these characteristics 495 collectively disseminate sufficient information to enable direct IP 496 peering between enterprise and service provider networks. The 497 various parameters represented in the capability set are chosen based 498 on existing practises and common problem sets typically seen between 499 enterprise and service provider SIP networks. 501 7. Data Model for Capability Set 503 This section defines a YANG module for encoding the service provider 504 capability set. Section 9.1 provides the tree diagram, which is 505 followed by a description of the various nodes within the module 506 defined in this draft. 508 7.1. Tree Diagram 510 This section provides a tree diagram [RFC 8340 511 (https://tools.ietf.org/html/rfc8340)] for the "ietf-capability-set" 512 module. The interpretation of the symbols appearing in the tree 513 diagram is as follows: 515 * Brackets "[" and "]" enclose list keys. 517 * Abbreviations before data node names: "rw" means configuration 518 (read-write), and "ro" means state data (read-only). 520 * Symbols after data node names: "?" means an optional node, "!" 521 means a presence container, and "*" denotes a list and leaf-list. 523 * Parentheses enclose choice and case nodes, and case nodes are also 524 marked with a colon (":"). 526 * Ellipsis ("...") stands for contents of subtrees that are not 527 shown. 529 The data model for the peering capability document has the following 530 structure: 532 module: ietf-sip-auto-peering 533 +--rw peering-info 534 +--rw variant string 535 +--rw transport-info 536 | +--rw transport? enumeration 537 | +--rw registrar* host-port 538 | +--rw registrarRealm? string 539 | +--rw callControl* host-port 540 | +--rw dns* inet:ip-address 541 | +--rw outboundProxy? host-port 542 +--rw call-specs 543 | +--rw earlyMedia? boolean 544 | +--rw signalingForking? boolean 545 | +--rw supportedMethods? string 546 | +--rw numRange 547 | +--rw numRangeType? string 548 | +--rw count? int32 549 | +--rw value* string 550 +--rw media 551 | +--rw mediaTypeAudio 552 | | +--rw mediaFormat* string 553 | +--rw fax 554 | | +--rw protocol* enumeration 555 | +--rw rtp 556 | | +--rw RTPTrigger? boolean 557 | | +--rw symmetricRTP? boolean 558 | +--rw rtcp 559 | +--rw symmetricRTCP? boolean 560 | +--rw RTCPfeedback? boolean 561 +--rw dtmf 562 | +--rw payloadNumber? int8 563 | +--rw iteration? boolean 564 +--rw security 565 | +--rw signaling 566 | | +--rw type? string 567 | | +--rw version? string 568 | +--rw mediaSecurity 569 | | +--rw keyManagement? string 570 | +--rw certLocation? string 571 | +--rw secureTelephonyIdentity 572 | +--rw STIRCompliance? boolean 573 | +--rw certDelegation? boolean 574 | +--rw ACMEDirectory? string 575 +--rw extensions? string 577 7.2. YANG Model 579 This section defines the YANG module for the peering capability set 580 document. It imports modules (ietf-yang-types and ietf-inet-types) 581 from [RFC 6991 (https://tools.ietf.org/html/rfc6991)]. 583 module ietf-sip-auto-peering { 584 namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering"; 585 prefix "peering"; 587 description 588 "Data model for transmitting peering parameters from SP to 589 Enterprise"; 591 revision 2019-05-06 { 592 description "Initial revision of peering-response doc."; 593 } 595 import ietf-inet-types { 596 prefix "inet"; 597 } 599 typedef ipv4-address-port { 600 type string { 601 pattern "(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\" 602 + ".){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])" 603 + ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]" 604 + "{2}|655[1-2][0-9]|6553[1-5])$"; 605 } 606 description "The ipv4-address-port type represents an IPv4 607 address in dotted-quad notation followed by a port number."; 608 } 610 typedef ipv6-address-port { 611 type string { 612 pattern "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}" 613 + "((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|" 614 + "(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}" 615 + "(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))" 616 + ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]" 617 + "{2}|655[1-2][0-9]|6553[1-5])$"; 618 pattern 619 "(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|" 620 + "((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)" 621 + ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]" 622 + "{2}|655[1-2][0-9]|6553[1-5])$"; 623 } 624 description 625 "The ipv6-address type represents an IPv6 address in full, 626 mixed, shortened, and shortened-mixed notation followed by 627 a port number."; 628 } 630 typedef ip-address-port { 631 type union { 632 type ipv4-address-port; 633 type ipv6-address-port; 634 } 635 description 636 "The ip-address-port type represents an IP address:port number 637 and is IP version neutral."; 638 } 640 typedef domain-name-port { 641 type string { 642 pattern 643 "((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*" 644 + "([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)" 645 + "|\." 646 + ":^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]" 647 + "{2}655[1-2][0-9]|6553[1-5])$"; 648 length "1..258"; 649 } 650 description 651 "The domain-name-port type represents a DNS domain name 652 followed by a port number. The name SHOULD be fully qualified 653 whenever possible."; 654 } 656 typedef host-port { 657 type union { 658 type ip-address-port; 659 type domain-name-port; 660 } 661 description 662 "The host type represents either an IP address or a DNS 663 domain name followed by a port number."; 664 } 666 container peering-info { 667 leaf variant { 668 type string; 669 mandatory true; 670 description "Variant of peering-response document"; 671 } 672 container transport-info { 673 leaf transport { 674 type enumeration { 675 enum "TCP"; 676 enum "TLS"; 677 enum "UDP"; 678 enum "TCP;TLS"; 679 enum "TCP;TLS;UDP"; 680 enum "TCP;UDP"; 681 } 682 description "Transport Protocol(s) used in SIP 683 communication"; 684 } 686 leaf-list registrar { 687 type host-port; 688 max-elements 3; 689 description "List of service provider registrar servers"; 690 } 692 leaf registrarRealm { 693 type string; 694 description "Realm for REGISTER requests carrying 695 credentials"; 696 } 698 leaf-list callControl { 699 type host-port; 700 max-elements 3; 701 description "List of service provider call control servers"; 702 } 704 leaf-list dns { 705 type inet:ip-address; 706 max-elements 2; 707 description "IP address of the DNS Server(s) hosted by the 708 service provider"; 709 } 711 leaf outboundProxy { 712 type host-port; 713 description "SIP Outbound Proxy"; 714 } 715 } 717 container call-specs { 718 leaf earlyMedia { 719 type boolean; 720 description "Flag indicating whether the service provider 721 is expected to deliver early media."; 722 } 724 leaf signalingForking { 725 type boolean; 726 description "Flag indicating whether the service provider 727 is capable of forking incoming calls "; 728 } 730 leaf supportedMethods { 731 type string; 732 description "Leaf/Leaf List indicating the different SIP 733 methods support by the service provider."; 734 } 736 container numRange { 737 leaf numRangeType { 738 type string; 739 description "String indicating whether the DID number 740 range is passed by value or by reference" 741 } 743 leaf count { 744 when "../numRangeType = 'range' or 745 ../numRangeType = 'block'"; 746 type int32; 747 description "Number of DID numbers present in the number 748 range." 749 } 751 leaf-list value { 752 type string; 753 description "Value of the DID number range or URL being 754 passed as reference." 755 } 757 } 758 } 760 container media { 761 container mediaTypeAudio { 762 leaf-list mediaFormat { 763 type string; 764 description "Leaf List indicating the audio media formats 765 supported."; 766 } 767 } 768 container fax { 769 leaf-list protocol { 770 type enumeration { 771 enum "pass-through"; 772 enum "t38"; 773 } 774 max-elements 2; 775 description "Leaf List indicating the different fax 776 protocols supported by the service provider."; 777 } 778 } 780 container rtp { 781 leaf RTPTrigger { 782 type boolean; 783 description "Flag indicating whether the service provider 784 expects to receive the first media packet."; 785 } 787 leaf symmetricRTP { 788 type boolean; 789 description "Flag indicating whether the service provider 790 expects symmetric RTP defined in [@RFC4961]"; 791 } 792 } 794 container rtcp { 795 leaf symmetricRTCP { 796 type boolean; 797 description " Flag indicating whether the service 798 provider expects symmetric RTP defined in [@RFC4961]."; 799 } 801 leaf RTCPfeedback { 802 type boolean; 803 description "Flag Indicating support for RTP profile 804 extension for RTCP-based feedback, as defined in [@RFC4585]"; 805 } 806 } 807 } 809 container dtmf { 810 leaf payloadNumber { 811 type int8 { 812 range "96..127"; 813 } 814 description "Leaf that indicates the payload number(s) 815 supported by the service provider for DTMF relay via 816 Named-Telephony-Events"; 817 } 819 leaf iteration { 820 type boolean; 821 description "Flag identifying whether the service provider 822 supports NTE DTMF relay using the procedures of [@RFC2833] 823 or [@RFC4733] ."; 824 } 825 } 827 container security { 828 container signaling { 829 leaf type { 830 type string { 831 pattern "TLS"; 832 } 833 description "Type of signaling security supported."; 834 } 836 leaf version { 837 type string { 838 pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)"; 839 } 840 description "Indicates TLS version for SIP signaling"; 841 } 842 } 844 container mediaSecurity { 845 leaf keyManagement { 846 type string { 847 pattern "(SDES(;DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]" 848 + "\.[0-9])?)?)|(DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]" 849 + "\.[0-9])?)|(NULL)"; 850 } 851 description "Leaf that identifies the key management 852 methods supported by the service provider for SRTP."; 853 } 854 } 856 leaf certLocation { 857 type string; 858 description "Location of the service provider certificate 859 chain for SIP over TLS."; 860 } 862 container secureTelephonyIdentity { 863 leaf STIRCompliance { 864 type boolean; 865 description "Indicates whether the SIP service provider 866 is STIR compliant."; 867 } 869 leaf certDelegation { 870 type boolean; 871 description "Indicates whether a SIP service provider is 872 willing to delegate authority to the enterprise network 873 over its allocated number range(s)"; 874 } 876 leaf ACMEDirectory { 877 when "../certDelegation = 1 878 or ../certDelegation = 'true'"; 879 type string; 880 description "Directory object URL, when de-referenced, 881 provides a collection of field name-value pairs to 882 kickstart ACME."; 883 } 884 } 885 } 887 leaf extensions { 888 type string; 889 description "Lists the various SIP extensions supported by 890 the service provider."; 891 } 892 } 893 } 895 7.3. Node Definitions 897 This sub-sections provides the definition and encoding rules of the 898 various nodes of the YANG module defined in section 9.2 900 *capability-set*: This node serves as a container for all the other 901 nodes in the YANG module; the capability-set node is akin to the root 902 element of an XML schema. 904 *variant*: This node identifies the version number of the capability 905 set document. This draft defines the parameters for variant 1.0; 906 future specifications might define a richer parameter set, in which 907 case the variant must be changed to 2.0, 3.0 and so on. Future 908 extensions to the capability set document MUST also ensure that the 909 corresponding YANG module is defined. 911 *transport-info*: The transport-info node is a container that 912 encapsulates transport characteristics of SIP sessions between 913 enterprise and service provider networks. 915 *transport*: A leaf node that enumerates the different Transport 916 Layer protocols supported by the SIP service provider. Valid 917 transport layer protocols include: UDP, TCP, TLS or a combination of 918 them (with the exception of TLS and UDP). 920 *registrar*: A leaf-list that specifies the transport address of one 921 or more registrar servers in the service provider network. The 922 transport address of the registrar can be provided using a 923 combination of a valid IP address and port number, or a subdomain of 924 the SIP service provider network, or the fully qualified domain name 925 (FQDN) of the SIP service provider network. If the transport address 926 of a registrar is specified using either a subdomain or a fully 927 qualified domain name, the DNS element must be populated with one or 928 more valid DNS server IP addresses. 930 *callControl*: A leaf-list that specifies the transport address of 931 the call server(s) in the service provider network. The enterprise 932 network must use an applicable transport protocol in conjunction with 933 the call control server(s) transport address when transmitting call 934 setup requests. The transport address of a call server(s) within the 935 service provider network can be specified using a combination of a 936 valid IP address and port number, or a subdomain of the SIP service 937 provider network, or a fully qualified domain name of the SIP service 938 provider network. If the transport address of a call control 939 server(s) is specified using either a subdomain or a fully qualified 940 domain name, the DNS element must be populated with one or more valid 941 DNS server IP addresses. The transport address specified in this 942 element can also serve as the target for non-call requests such as 943 SIP OPTIONS. 945 *dns*: A leaf list that encodes the IP address of one or more DNS 946 servers hosted by the SIP service provider. If the enterprise 947 network is unaware of the IP address, port number, and transport 948 protocol of servers within the service provider network (for example, 949 the registrar and call control server), it must use DNS NAPTR and 950 SRV. Alternatively, if the enterprise network has the fully 951 qualified domain name of the SIP service provider network, it must 952 use DNS to resolve the said FQDN to an IP address. The dns element 953 encodes the IP address of one or more DNS servers hosted in the 954 service provider network. If however, either the registrar or 955 callControl elements or both are populated with a valid IP address 956 and port pair, the dns element must be set to the quadruple octet of 957 0.0.0.0 958 *outboundProxy*: A leaf list that specifies the transport address of 959 one or more outbound proxies. The transport address can be specified 960 by using a combination of an IP address and a port number, a 961 subdomain of the SIP service provider network, or a fully qualified 962 domain name and port number of the SIP service provider network. If 963 the outbound-proxy sub-element is populated with a valid transport 964 address, it represents the default destination for all outbound SIP 965 requests and therefore, the registrar and callControl elements must 966 be populated with the quadruple octet of 0.0.0.0 968 *call-specs*: A container that encapsulates information about call 969 specifications, restrictions and additional handling criteria for SIP 970 calls between the enterprise and service provider network. 972 *earlyMedia*: A leaf that specifies whether the service provider 973 network is expected to deliver in-band announcements/tones before 974 call connect. The P-Early-Media header field can be used to indicate 975 pre-connect delivery of tones and announcements on a per-call basis. 976 However, given that signalling and media could traverse a large 977 number of intermediaries with varying capabilities (in terms of 978 handling of the P-Early-Media header field) within the enterprise, 979 such devices can be appropriately configured for media cut through if 980 it is known before-hand that early media is expected for some or all 981 of the outbound calls. This element is a Boolean type, where a value 982 of 1/true signifies that the service provider is capable of early 983 media. A value of 0/false signifies that the service provider is not 984 expected to generate early media. 986 *signalingForking*: A leaf that specifies whether outbound call 987 requests from the enterprise might be forked on the service provider 988 network that MAY lead to multiple early dialogs. This information 989 would be useful to the enterprise network in appropriately handling 990 multiple early dialogs reliably and in enforcing local policy. This 991 element is a Boolean type, where a value of 1/true signifies that the 992 service provider network can potentially fork outbound call requests 993 from the enterprise. A value of 0/false indicates that the service 994 provider will not fork outbound call requests. 996 *supportedMethods*: A leaf node that specifies the various SIP 997 methods supported by the SIP service provider. The list of supported 998 methods help to appropriately configuration various devices within 999 the enterprise network. For example, if the service provider 1000 enumerates support for the OPTIONS method, the enterprise network 1001 could periodically send OPTIONS requests as a keep-alive mechanism. 1003 *numRange*: Is a container that specifies the Direct Inward Dial 1004 (DID) number range allocated to the enterprise network by the SIP 1005 service provider. The DID number range allocated by the service 1006 provider to the enterprise network might be a contiguous or a non- 1007 contiguous block. The number range allocated to an enterprise can be 1008 communicated as a value or as a reference. For large enterprise 1009 networks, the size of the DID range might run into several hundred 1010 numbers. For situations in which the enterprise is allocated a large 1011 DID number range or a non-contiguous number range it is RECOMMENDED 1012 that the SIP service provider communicate this information by 1013 reference, that is, through a URL. The enterprise network is 1014 required to de-reference this URL in order to obtain the DID number 1015 range allocated by the SIP service provider. The numRange container 1016 can be used more than once. Refer to the example provided in 1017 Section 10.1. 1019 *numRangeType*: A leaf node that indicates whether the DID range is 1020 communicated by value or by reference. It can have a value of 1021 'range', 'block' or 'reference'. 1023 *count*: A leaf node that indicates the size of the DID number range. 1024 The number range may be contiguous or non-contiguous. This leaf node 1025 MUST NOT be included when using the 'reference' numRangeType value. 1027 *value*: A leaf-list that encapsulates the DID number range allocated 1028 to the enterprise. If the numRangeType value is set to 'range' or 1029 'block', this is the list of numbers allocated to the enterprise. If 1030 the numRangeType value is set to 'reference', this is the URL of the 1031 resource containing the DID number range. To ensure ease of parsing, 1032 it is RECOMMENDED that the resource contain a number range formatted 1033 as if it were being passed as a block or range. 1035 *media*: A container that is used to collectively encapsulate the 1036 characteristics of UDP-based audio streams. A future extension to 1037 this draft may extend the media container to describe other media 1038 types. The media container is also used to encapsulate basic 1039 information about Real-Time Transport Protocol (RTP) and Real-Time 1040 Transport Control Protocol (RTCP) from the perspective of the service 1041 provider network. As of the date of writing this draft, video media 1042 streams aren't exchanged between enterprise and service provider SIP 1043 networks. 1045 *mediaTypeAudio*: A container for the mediaFormat leaf-list. This 1046 container collectively encapsulates the various audio media formats 1047 supported by the SIP service provider. 1049 *mediaFormat*: A leaf-list encoding the various audio media formats 1050 supported by the SIP service provider. The relative ordering of 1051 different media format leaf nodes from left to right indicates 1052 preference from the perspective of the service provider. Each 1053 mediaFormat node begins with the encoding name of the media format, 1054 which is the same encoding name as used in the "RTP/AVP" and "RTP/ 1055 SAVP" profiles. The encoding name is followed by required and 1056 optional parameters for the given media format as specified when the 1057 media format is registered [RFC 4855 (https://tools.ietf.org/html/ 1058 rfc4855)]. Given that the parameters of media formats can vary from 1059 one communication session to another, for example, across two 1060 separate communication sessions, the packetization time (ptime) used 1061 for the PCMU media format might vary from 10 to 30 ms, the parameters 1062 included in the format element must be the ones that are expected to 1063 be invariant from the perspective of the service provider. Providing 1064 information about supported media formats and their respective 1065 parameters, allows enterprise networks to configure the media plane 1066 characteristics of various devices such as endpoints and middleboxes. 1067 The encoding name, one or more required parameters, one or more 1068 optional parameters are all separated by a semicolon. The formatting 1069 of a given media format parameter, must follow the formatting rules 1070 as specified for that media format. 1072 *fax*: A container that encapsulates the fax protocol(s) supported by 1073 the SIP service provider. The fax container encloses a leaf-list 1074 (named protocol) that enumerates whether the service provider 1075 supports t38 relay, protocol-based fax passthrough or both. The 1076 relative ordering of leaf nodes within the leaf lists indicates 1077 preference. 1079 *rtp*: A container that encapsulates generic characteristics of RTP 1080 sessions between the enterprise and service provider network. This 1081 node is a container for the "RTPTrigger" and "SymmetricRTP" leaf 1082 nodes. 1084 *RTPTrigger*: A leaf node indicating whether the SIP service provider 1085 network always expects the enterprise network to send the first RTP 1086 packet for an established communication session. This information is 1087 useful in scenarios such as "hairpinned" calls, in which the caller 1088 and callee are on the service provider network and because of sub- 1089 optimal media routing, an enterprise device such as an SBC is 1090 retained in the media path. Based on the encoding of this node, it 1091 is possible to configure enterprise devices such as SBCs to start 1092 streaming media (possibly filled with silence payloads) toward the 1093 address:port tuples provided by caller and callee. This node is a 1094 Boolean type. A value of 1/true indicates that the service provider 1095 expects the enterprise network to send the first RTP packet, whereas 1096 a value of 0/false indicates that the service provider network does 1097 not require the enterprise network to send the first media packet. 1098 While the practise of preserving the enterprise network in a 1099 hairpinned call flow is fairly common, it is recommended that SIP 1100 service providers avoid this practise. In the context of a 1101 hairpinned call, the enterprise device retained in the call flow can 1102 easily eavesdrop on the conversation between the offnet parties. 1104 *symmetricRTP*: A leaf node indicating whether the SIP service 1105 provider expects the enterprise network to use symmetric RTP as 1106 defined in RFC 4961 (https://tools.ietf.org/html/rfc4961). 1107 Uncovering this expectation is useful in scenarios where "latching" 1108 [RFC 7362 (https://tools.ietf.org/html/rfc7362)] is implemented in 1109 the service provider network. This node is a Boolean type, a value 1110 of 1/true indicates that the service provider expects the enterprise 1111 network to use symmetric RTP, whereas a value of 0/false indicates 1112 that the enterprise network can use asymmetric RTP. 1114 *rtcp*: A container that encapsulates generic characteristics of RTCP 1115 sessions between the enterprise and service provider network. This 1116 node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf 1117 nodes. 1119 *RTCPFeedback*: A leaf node that indicates whether the SIP service 1120 provider supports the RTP profile extension for RTCP-based feedback 1121 RFC 4585 (https://tools.ietf.org/html/rfc4585). Media sessions 1122 spanning enterprise and service provider networks, are rarely made to 1123 flow directly between the caller and callee, rather, it is often the 1124 case that media traffic flows through network intermediaries such as 1125 SBCs. As a result, RTCP traffic from the service provider network is 1126 intercepted by these intermediaries, which in turn can either pass 1127 across RTCP traffic unmodified or modify RTCP traffic before it is 1128 forwarded to the endpoint in the enterprise network. Modification of 1129 RTCP traffic would be required, for example, if the intermediary has 1130 performed media payload transformation operations such as transcoding 1131 or transrating. In a similar vein, for the RTCP-based feedback 1132 mechanism as defined in RFC 4585 (https://tools.ietf.org/html/ 1133 rfc4585) to be truly effective, intermediaries must ensure that 1134 feedback messages are passed reliably and with the correct formatting 1135 to enterprise endpoints. This might require additional configuration 1136 and considerations that need to be dealt with at the time of 1137 provisioning the intermediary device. This node is a Boolean type, a 1138 value of 1/true indicates that the service provider supports the RTP 1139 profile extension for RTP-based feedback and a value of 0/false 1140 indicates that the service provider does not support the RTP profile 1141 extension for RTP-based feedback. 1143 *symmetricRTCP*: A leaf node indicating whether the SIP service 1144 provider expects the enterprise network to use symmetric RTCP as 1145 defined in RFC 4961 (https://tools.ietf.org/html/rfc4961). This node 1146 is a Boolean type, a value of 1 indicates that the service provider 1147 expects symmetric RTCP reports, whereas a value of 0 indicates that 1148 the enterprise can use asymmetric RTCP. 1150 *dtmf*: A container that describes the various aspects of DTMF relay 1151 via RTP Named Telephony Events. The dtmf container allows SIP 1152 service providers to specify two facets of DTMF relay via Named 1153 Telephony Events: 1155 1. The payload type number using the payloadNumber leaf node. 1157 2. Support for RFC 2833 (https://tools.ietf.org/html/rfc2833) or RFC 1158 4733 (https://tools.ietf.org/html/rfc4733) using the iteration 1159 leaf node. 1161 In the context of named telephony events, senders and receivers may 1162 negotiate asymmetric payload type numbers. For example, the sender 1163 might advertise payload type number 97 and the receiver might 1164 advertise payload type number 101. In such instances, it is either 1165 required for middleboxes to interwork payload type numbers or allow 1166 the endpoints to send and receive asymmetric payload numbers. The 1167 behaviour of middleboxes in this context is largely dependent on 1168 endpoint capabilities or on service provider constraints. Therefore, 1169 the payloadNumber leaf node can be used to determine middlebox 1170 configuration before-hand. 1172 RFC 4733 (https://tools.ietf.org/html/rfc4733) iterates over RFC 2833 1173 (https://tools.ietf.org/html/rfc2833) by introducing certain changes 1174 in the way NTE events are transmitted. SIP service providers can 1175 indicate support for RFC 4733 (https://tools.ietf.org/html/rfc4733) 1176 by setting the iteration flag to 1 or indicating support for RFC 2833 1177 (https://tools.ietf.org/html/rfc2833) by setting the iteration flag 1178 to 0. 1180 *security*: A container that encapsulates characteristics about 1181 encrypting signalling streams between the enterprise and SIP service 1182 provider networks. 1184 *signaling*: A container that encapsulates the type of security 1185 protocol for the SIP communication between the enterprise SBC and the 1186 service provider. 1188 *type*: A leaf node that specifies the protocol used for protecting 1189 SIP signalling messages between the enterprise and service provider 1190 network. The value of the type leaf node is only defined for 1191 Transport Layer Security (TLS). Accordingly, if TLS is allowed for 1192 SIP sessions between the enterprise and service provider network, the 1193 type leaf node is set to the string "tls". 1195 *version*: A leaf node that specifies the version(s) of TLS supported 1196 in decimal format. If multiple versions of TLS are supported, they 1197 should be separated by semi-colons. If the service provider does not 1198 support TLS for protecting SIP sessions, the signalling element is 1199 set to the string "NULL". 1201 *mediaSecurity*: A container that describes the various 1202 characteristics of securing media streams between enterprise and 1203 service provider networks. 1205 *keyManagement*: A leaf node that specifies the key management method 1206 used by the service provider. Possible values of this node include: 1207 "SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP 1208 service provider uses the methods defined in RFC 4568 1209 (https://tools.ietf.org/html/rfc4568) for the purpose of key 1210 management. A value of "DTLS-SRTP" signifies that the SIP service 1211 provider uses the methods defined in RFC 5764 1212 (https://tools.ietf.org/html/rfc5764) for the purpose of key 1213 management. If the value of this leaf node is set to "DTLS-SRTP", 1214 the various versions of DTLS supported by the SIP service provider 1215 MUST be encoded as per the formatting rules of Section 9.2. If the 1216 service provider does not support media security, the keyManagement 1217 node MUST be set to "NULL". 1219 *certLocation:*: If the enterprise network is required to exchange 1220 SIP traffic over TLS with the SIP service provider, and if the SIP 1221 service provider is capable of accepting TLS connections from the 1222 enterprise network, it may be required for the SIP service provider 1223 certificates to be pre-installed on the enterprise edge element. In 1224 such situations, the certLocation leaf node is populated with a URL, 1225 which when dereferenced, provides a single PEM encoded file that 1226 contains all certificates in the chain of trust. This is an optional 1227 leaf node. 1229 *secureTelephonyIdentity*: A container that is used to collectively 1230 encapsulate Secure Telephony Identity Revisited (STIR) 1231 characteristics. 1233 *STIRCompliance*: A leaf node that indicates whether the SIP service 1234 provider is STIR compliant. This node is a Boolean type, a value 1/ 1235 true indicates that the SIP service provider is STIR compliant. A 1236 value of 0/false indicates that the SIP service provider is not STIR 1237 compliant. A SIP service provider being STIR compliant has 1238 implications for inbound and outbound calls, from the perspective of 1239 the enterprise network. 1241 For inbound calls received from a STIR compliant SIP service 1242 provider, the enterprise edge element can be configured to 1243 appropriately handle calls based on their "attestation value". For 1244 example, calls with an attestation value of "A" (Full Attestation) 1245 are allowed to go through, while calls with an attestation value of 1246 "C" (Gateway Attestation) may be flagged for administrative analysis. 1248 For outgoing calls placed to a STIR compliant SIP service provider, 1249 the enterprise edge element must ensure that the calling number 1250 populated in SIP From header field (or in trusted environments, the 1251 P-Asserted-Identity header field), is as per what the service 1252 provider expects. This is so that the Authentication Service running 1253 in the SIP service provider network can determine if it is 1254 authoritative for the calling number presented by the enterprise 1255 network. 1257 *certDelegation*: A leaf node value that indicates whether a SIP 1258 service provider that allocates one or more number ranges to an 1259 enterprise network, is willing to delegate authority to the 1260 enterprise network over that number range(s). This node is a Boolean 1261 type, a value of 1/true indicates that the SIP service provider is 1262 willing to delegate authority to the enterprise network over one or 1263 more number ranges. A value of 0/false indicates that the SIP 1264 service provider is not willing to delegate authority to the 1265 enterprise network over one or more number ranges. This leaf node 1266 MUST only be included in the capability set if the value of the 1267 STIRCompliance leaf node is set to 1/true. In order to obtain 1268 delegate certificates, the enterprise network must be made aware of 1269 the scope of delegation - the number or number range(s) over which 1270 the SIP service provider is willing to delegate authority. This 1271 information is included in the numRange container. 1273 *ACMEDirectory*: For delegate certificates that are obtained by the 1274 enterprise network using Automatic Certificate Management Environment 1275 (ACME), this leaf node value provides the URL of the directory object 1276 (https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme- 1277 18#section-7.1.1). The directory object URL, when de-referenced, 1278 provides a collection of field name-value pairs. Certain field name- 1279 value pairs provided in the response are used to bootstrap the 1280 process the obtaining delegate certificates. This leaf node MUST 1281 only be included in the capability set if the value of the 1282 certDelegation leaf node is set to 1/true. 1284 *extensions*: A leaf node that is a semicolon separated list of all 1285 possible SIP option tags supported by the service provider network. 1286 These extensions must be referenced using name registered under IANA. 1287 If the service provider network does not support any extensions to 1288 baseline SIP, the extensions node must be set to "NULL". 1290 7.4. Extending the Capability Set 1292 There are situations in which equipment manufactures or service 1293 providers would benefit from extending the YANG module defined in 1294 this draft. For example, service providers could extend the YANG 1295 module to include information that further simplifies direct IP 1296 peering. Such information could include: trunk group identifiers, 1297 direct-inward-dial (DID) number ranges allocated to the enterprise, 1298 customer/enterprise account numbers, service provider support 1299 numbers, among others. Extension of the module can be achieved by 1300 importing the module defined in this draft. An example is provided 1301 below: Consider a new YANG module "vendorA" specified for VendorA's 1302 enterprise SBC. The "vendorA-config" YANG module is configured as 1303 follows: 1305 module vendorA-config { 1306 namespace "urn:ietf:params:xml:ns:yang:vendorA-config"; 1307 prefix "vendorA"; 1309 description 1310 "Data model for configuring VendorA Enterprise SBC"; 1312 revision 2020-05-06 { 1313 description "Initial revision of VendorA Enterprise SBC configuration data model"; 1314 } 1316 import ietf-peering { 1317 prefix "peering"; 1318 } 1320 augment "/peering:peering-info" { 1321 container vendorAConfig { 1322 leaf vendorAConfigParam1 { 1323 type int32; 1324 description "vendorA configuration parameter 1 (SBC Device ID)"; 1325 } 1327 leaf vendorAConfigParam2 { 1328 type string; 1329 description "vendorA configuration parameter 2 (SBC Device name)"; 1330 } 1331 description "Container for vendorA SBC configuration"; 1332 } 1333 } 1334 } 1336 In the example above, a custom module named "vendorA-config" uses the 1337 "augment" statement as defined in Section 4.2.8 of [RFC 7950 1338 (https://tools.ietf.org/html/rfc7950)] to extend the module defined 1339 in this draft. 1341 8. Processing the Capability Set Response 1343 This section provides a non-normative description of the procedures 1344 that could be carried out by the enterprise network after obtaining 1345 the SIP service provider capability set. On obtaining the capability 1346 set, the enterprise edge element can parse the various fields within 1347 the capability set and generate configuration blocks. For example, 1348 the configuration required to successfully register a SIP trunk with 1349 the SIP registrar hosted in the service provider network, the 1350 configuration required to ensure that fax calls are handled 1351 appropriately, the configuration required to advertise only audio 1352 codecs supported by the SIP service provider, among many other 1353 configuration blocks. A configuration block generated for an almost 1354 identical SIP service provider capability set document is likely 1355 going to differ drastically from one vendor to the next. 1357 Enterprise edge elements are usually capable of normalising 1358 mismatches in the signalling and media planes between the enterprise 1359 and service provider SIP networks. As a result, most, if not all of 1360 the configuration blocks required to enable successful SIP service 1361 provider peering might need to be added on the edge element. In 1362 situations wherein configuration blocks need to be distributed across 1363 multiple devices, some mechanism, that is out of scope of this 1364 document might be used to communicate the specific fields of capacity 1365 set and their corresponding value. Alternatively, a human 1366 administrator could go through the capability set document and 1367 configure the edge element (and if required, other devices in the 1368 enterprise network appropriately. 1370 9. Examples 1372 This section provides examples of how capability set documents that 1373 leverage the YANG module defined in this document can be encoded over 1374 JSON or XML as well as the exchange of messages between the 1375 enterprise edge element and the service provider to acquire the 1376 capability set document. 1378 9.1. XML Capability Set Document 1380 1383 1.0 1384 1385 TCP;TLS;UDP 1386 registrar1.voip.example.com:5060 1387 registrar2.voip.example.com:5060 1388 voip.example.com 1389 callServer1.voip.example.com:5060 1390 192.168.12.25:5065 1391 8.8.8.8 1392 208.67.222.222 1393 0.0.0.0 1394 1395 1396 true 1397 false 1398 INVITE;OPTIONS;BYE;CANCEL;ACK;PRACK;SUBSCRIBE;NOTIFY;REGISTER 1399 1400 range 1401 20 1402 19725455000 1403 1404 1405 block 1406 2 1407 1972546000 1408 1972546001 1409 1410 1411 1412 1413 PCMU;rate=8000;ptime=20 1414 G729;rate=8000;annexb=yes 1415 G722;rate=8000;bitrate=56k,64k 1416 1417 1418 pass-through 1419 t38 1420 1421 1422 true 1423 true 1424 1425 1426 true 1427 true 1428 1429 1430 1431 101 1432 0 1433 1434 1435 1436 TLS 1437 1.0;1.2 1438 1439 1440 SDES;DTLS-SRTP,version=1.2 1441 1442 https://sipserviceprovider.com/certificateList.pem 1443 1444 true 1445 true 1446 https://sipserviceprovider.com/acme.html 1447 1448 1449 timer;rel100;gin;path 1450 1452 9.2. Example Exchange 1454 This section depicts an example of the configuration flow that 1455 ultimately results in the enterprise edge element obtaining the 1456 capability set document from the SIP service provider. Assuming the 1457 enterprise edge element has been pre-configured with the request 1458 target for the capability set document or has dynamically found the 1459 request target, the edge element generates a HTTPS GET request. This 1460 request can be challenged by the service provider to authenticate the 1461 enterprise. 1463 GET /capdoc?trunkid=trunkent1456 HTTP/1.1 1464 Host: capserver.ssp1.com 1465 Accept:application/peering-info+xml 1467 The capability set document is obtained in the body of the response 1468 and is encoded in XML. 1470 HTTP/1.1 200 OK 1471 Content-Type: application/peering-info+xml 1472 Content-Length: nnn 1474 1475 … 1476 1478 10. Security Considerations 1480 [TBD] 1482 11. Acknowledgments 1484 [TBD] 1486 12. Normative References 1488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1489 Requirement Levels", BCP 14, RFC 2119, 1490 DOI 10.17487/RFC2119, March 1997, 1491 . 1493 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 1494 Digits, Telephony Tones and Telephony Signals", RFC 2833, 1495 DOI 10.17487/RFC2833, May 2000, 1496 . 1498 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1499 A., Peterson, J., Sparks, R., Handley, M., and E. 1500 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1501 DOI 10.17487/RFC3261, June 2002, 1502 . 1504 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1505 "Extended RTP Profile for Real-time Transport Control 1506 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1507 DOI 10.17487/RFC4585, July 2006, 1508 . 1510 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1511 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1512 DOI 10.17487/RFC4733, December 2006, 1513 . 1515 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1516 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1517 . 1519 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1520 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 1521 . 1523 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1524 (TLS) Protocol Version 1.2", RFC 5246, 1525 DOI 10.17487/RFC5246, August 2008, 1526 . 1528 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1529 the Network Configuration Protocol (NETCONF)", RFC 6020, 1530 DOI 10.17487/RFC6020, October 2010, 1531 . 1533 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1534 and A. Bierman, Ed., "Network Configuration Protocol 1535 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1536 . 1538 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1539 DOI 10.17487/RFC6665, July 2012, 1540 . 1542 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1543 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1544 . 1546 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1547 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1548 . 1550 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 1551 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 1552 2013, . 1554 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1555 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1556 DOI 10.17487/RFC7231, June 2014, 1557 . 1559 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 1560 Traversal (HNT) for Media in Real-Time Communication", 1561 RFC 7362, DOI 10.17487/RFC7362, September 2014, 1562 . 1564 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1565 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1566 . 1568 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1569 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1570 . 1572 Authors' Addresses 1574 Kaustubh Inamdar 1575 Unaffiliated 1577 Email: kaustubh.ietf@gmail.com 1579 Sreekanth Narayanan 1580 Cisco Systems 1582 Email: sreenara@cisco.com 1584 Cullen Jennings 1585 Cisco Systems 1587 Email: fluffy@iii.ca