idnits 2.17.1 draft-ietf-asap-sip-auto-peer-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 39 instances of too long lines in the document, the longest one being 67 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 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 (April 1, 2021) is 1121 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) -- Looks like a reference, but probably isn't: '2' on line 98 -- Looks like a reference, but probably isn't: '3' on line 134 -- Looks like a reference, but probably isn't: '11' on line 361 -- Looks like a reference, but probably isn't: '12' on line 363 == Missing Reference: 'TBD' is mentioned on line 1287, but not defined == Missing Reference: '0-9' is mentioned on line 778, but not defined == Missing Reference: '1-9' is mentioned on line 778, but not defined == Missing Reference: '0-4' is mentioned on line 560, but not defined == Missing Reference: '0-5' is mentioned on line 560, but not defined == Missing Reference: '1-5' is mentioned on line 587, but not defined == Missing Reference: '1-4' is mentioned on line 587, but not defined == Missing Reference: '1-2' is mentioned on line 587, but not defined -- Looks like a reference, but probably isn't: '01' on line 560 -- Looks like a reference, but probably isn't: '16' on line 1008 -- Looks like a reference, but probably isn't: '18' on line 1022 -- Looks like a reference, but probably isn't: '19' on line 1033 -- Looks like a reference, but probably isn't: '20' on line 1045 -- Looks like a reference, but probably isn't: '21' on line 1057 -- Looks like a reference, but probably isn't: '22' on line 1057 -- Looks like a reference, but probably isn't: '23' on line 1071 -- Looks like a reference, but probably isn't: '24' on line 1071 -- Looks like a reference, but probably isn't: '25' on line 1073 -- Looks like a reference, but probably isn't: '26' on line 1074 -- Looks like a reference, but probably isn't: '27' on line 1105 -- Looks like a reference, but probably isn't: '28' on line 1107 == Unused Reference: 'RFC2119' is defined on line 1293, but no explicit reference was found in the text == Unused Reference: 'RFC2833' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 1303, but no explicit reference was found in the text == Unused Reference: 'RFC4585' is defined on line 1309, but no explicit reference was found in the text == Unused Reference: 'RFC4733' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'RFC4855' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'RFC4961' is defined on line 1324, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1328, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: 'RFC6665' is defined on line 1343, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 1347, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'RFC7033' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 1359, but no explicit reference was found in the text == Unused Reference: 'RFC7362' is defined on line 1364, but no explicit reference was found in the text == Unused Reference: 'RFC8340' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 1373, 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: 7 errors (**), 0 flaws (~~), 30 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ASAP K. Inamdar 3 Internet-Draft S. Narayanan 4 Expires: October 3, 2021 C. Jennings 5 Cisco Systems 6 April 1, 2021 8 Automatic Peering for SIP Trunks 9 draft-ietf-asap-sip-auto-peer-00 11 Abstract 13 This draft specifies a configuration workflow to enable enterprise 14 Session Initiation Protocol (SIP) networks to solicit the capability 15 set of a SIP service provider network. The capability set can 16 subsequently be used to configure features and services on the 17 enterprise edge element, such as a Session Border Controller (SBC), 18 to ensure smooth peering between enterprise and service provider 19 networks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 3, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 57 3. Reference Architecture . . . . . . . . . . . . . . . . . . . 3 58 4. Configuration Workflow . . . . . . . . . . . . . . . . . . . 5 59 5. Overview of Operations . . . . . . . . . . . . . . . . . . . 6 60 6. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 8 62 6.2. Integrity and Confidentiality . . . . . . . . . . . . . . 8 63 6.3. Authenticated Client Identity . . . . . . . . . . . . . . 8 64 6.4. Encoding the Request . . . . . . . . . . . . . . . . . . 8 65 6.5. Generating the response . . . . . . . . . . . . . . . . . 9 66 6.6. Identifying the Request Target . . . . . . . . . . . . . 9 67 7. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8. Encoding the Service Provider Capability Set . . . . . . . . 10 69 9. Data Model for Capability Set . . . . . . . . . . . . . . . . 10 70 9.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 71 9.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 17 73 9.4. Extending the Capability Set . . . . . . . . . . . . . . 24 74 10. Example Capability Set Document Encoding . . . . . . . . . . 25 75 10.1. XML Capability Set Document . . . . . . . . . . . . . . 26 76 11. Example Exchange . . . . . . . . . . . . . . . . . . . . . . 27 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 81 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 84 1. Introduction 86 The deployment of a Session Initiation Protocol [RFC 3261 [1]] (SIP)- 87 based infrastructure in enterprise and service provider communication 88 networks is increasing at a rapid pace. Consequently, direct IP 89 peering between enterprise and service provider networks is quickly 90 replacing traditional methods of interconnection between enterprise 91 and service provider networks. Currently published standards provide 92 a strong foundation over which direct IP peering can be realized. 93 However, given the sheer number of these standards, it is often not 94 clear which behavioral subsets, extensions to baseline protocols and 95 operating principles ought to be implemented by service provider and 96 enterprise networks to ensure successful peering. 98 The SIP Connect technical recommendations [2] aim to solve this 99 problem by providing a master reference that promotes seamless 100 peering between enterprise and service provider SIP networks. 101 However, despite the extensive set of implementation rules and 102 operating guidelines, interoperability issues between service 103 provider and enterprise networks persist. This is in large part 104 because service providers and equipment manufacturers aren't required 105 to enforce the guidelines of the technical specifications and have a 106 fair degree of freedom to deviate from them. Consequently, 107 enterprise administrators usually undertake a fairly rigorous regimen 108 of testing, analysis and troubleshooting to arrive at a configuration 109 block that ensures seamless service provider peering. However, this 110 workflow complements the SIP Connect technical recommendations, in 111 that both endeavours aim to promote/achieve interop between the 112 enterprise and service provider. 114 Another set of interoperability problems arise when enterprise 115 administrators are required to translate a set of technical 116 recommendations from service providers to configuration blocks across 117 one or more devices in the enterprise, which is usually an error 118 prone exercise. Additionally, such technical recommendations might 119 not be nuanced enough to intuitively allow the generation of specific 120 configuration blocks. 122 This draft introduces a mechanism using which an enterprise network 123 can solicit a detailed capability set from a SIP service provider; 124 the detailed capability set can subsequently be used by automaton or 125 an administrator to generate configuration blocks across one or more 126 devices within the enterprise to ensure successful service provider 127 peering. 129 2. Conventions and Terminology 131 The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 132 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 133 this document are to be interpreted as described in RFC 2119 [3] 135 3. Reference Architecture 137 Figure 1 illustrates a reference architecture that may be deployed to 138 support the mechanism described in this document. The enterprise 139 network consists of a SIP-PBX, media endpoints and a Session Border 140 Controller [RFC 7092 [4]]. It may also include additional components 141 such as application servers for voicemail, recording, fax etc. At a 142 high level, the service provider consists of a SIP signaling entity 143 (SP-SSE), a media entity and a HTTPS [RFC 7231 [5]] server. 145 +-----------------------------------------------------+ 146 | +---------------+ +-----------------------+ | 147 | | | | | | 148 | | +----------+ | | +-------+ | | 149 | | | Cap | | HTTPS | | | | | 150 | | | Server |<-|---------|-->| | | | 151 | | | | | | | | +-----+ | | 152 | | +----------+ | | | | | SIP | | | 153 | | | | | |<->| PBX | | | 154 | | | | | | +-----+ | | 155 | | +----------+ | | | SBC | | | 156 | | | | | SIP | | | | | 157 | | | SP - SSE |<-|---------|-->| | +-----+ | | 158 | | | | | | | |<->| M.E.| | | 159 | | +----------+ | | | | | | | | 160 | | | | | | +-----+ | | 161 | | +----------+ | (S)RTP | | | | | 162 | | | Media |<-|---------|-->+-------+ | | 163 | | +----------+ | | | | 164 | +---------------+ +-----------------------+ | 165 | | 166 +-----------------------------------------------------+ 168 Figure 1: Reference Architecture 170 This draft makes use of the following terminology: 172 o Enterprise Network: A communications network infrastructure 173 deployed by an enterprise which interconnects with the service 174 provider network over SIP. The enterprise network could include 175 devices such as application servers, endpoints, call agents and 176 edge devices, among others. 178 o Edge Device: A device that is the last hop in the enterprise 179 network and that is the transit point for traffic entering and 180 leaving the enterprise. An edge device is typically a back-to- 181 back user agent (B2BUA) [RFC 7092 [6]] such as a Session Border 182 Controller (SBC). 184 o Service Provider Network: A communications network infrastructure 185 deployed by service providers. In the context of this draft, the 186 service provider network is accessible over SIP for the 187 establishment, modification and termination of calls and 188 accessible over HTTPS for the transfer of the capability set 189 document. The service provider network is also referred to as a 190 SIP Service Provider (SSP) or Internet Telephony Service Provider 191 (ITSP) network. 193 o Call Control: Call Control within a telephony networks refers to 194 software that is responsible for delivering its core 195 functionality. Call control not only provides the basic 196 functionality of setting up, sustaining and terminating calls, but 197 also provides the necessary control and logic required for 198 additional services within the telephony network. 200 o Capability Server: A server hosted in the service provider 201 network, such that this server is the target for capability set 202 document requests from the enterprise network. 204 o Capability Set: This specification uses the term capability set 205 (or capability set document) to refer collectivity to a set of 206 characteristics within the service provider network, which when 207 communicated to the enterprise network, provides the enterprise 208 network the information required to interconnect with the service 209 provider network. The various parameters that constitute the 210 capability set relate to characteristics that are specific to 211 signalling, media, transport and security. Certain aspects of 212 interconnecting with service providers are out of scope of the 213 capability set. For example, the access technology used to 214 interconnect with service provider networks. 216 4. Configuration Workflow 218 A workflow that facilitates an enterprise network to solicit the 219 capability set of a SIP service provider ought to take into account 220 the following considerations: 222 o The configuration workflow must be based on a protocol or a set of 223 protocols commonly used between enterprise and service provider 224 telephony networks. 226 o The configuration workflow must be flexible enough to allow the 227 service provider network to dynamically offload different 228 capability sets to different enterprise networks based on the 229 identity of the enterprise network. 231 o Capability set documents obtained as a result of the configuration 232 workflow must be conducive to easy parsing by automaton. 233 Subsequently, automaton may be used for generation of appropriate 234 configuration blocks. 236 Taking the above considerations into account, this document proposes 237 a Hypertext Transfer Protocol (HTTP)-based workflow using which the 238 enterprise network can solicit and ultimately obtain the service 239 provider capability set. The enterprise network creates a well 240 formed HTTPS GET request to solicit the service provider capability 241 set. Subsequently, the HTTPS response from the SIP service provider 242 includes the capability set. The capability set is encoded in either 243 XML or JSON, thus ensuring that the response can be easily parsed by 244 automaton. 246 There are alternative mechanisms using which the SIP service provider 247 can offload its capability set. For example, the Session Initiation 248 Protocol (SIP) can be extended to define a new event package [RFC 249 6665 [7]], such that the enterprise network can establish a SIP 250 subscription with the service provider for its capability set; the 251 SIP service provider can subsequently use the SIP NOTIFY request to 252 communicate its capability set or any state deltas to its baseline 253 capability set. 255 This mechanism is likely to result in a barrier to adoption for SIP 256 service providers and enterprise networks as equipment manufacturers 257 would have to first add support for such a SIP extension. A HTTPS- 258 based approach would be relatively easier to adopt as most edge 259 devices deployed in enterprise networks today already support HTTPS; 260 from the perspective of service provider networks, all that is 261 required is for them to deploy HTTPS servers that function as 262 capability servers. Additionally, most SIP service providers require 263 enterprise networks to register with them (using a SIP REGISTER 264 message) before any other SIP methods that initiate subscriptions 265 (SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a 266 SIP-based framework to obtain a capability set would require 267 operational changes on the part of service provider networks. 269 Yet another example of an alternative mechanism would be for service 270 providers and enterprise equipment manufacturers to agree on YANG 271 models [RFC 6020 [8]] that enable configuration to be pushed over 272 NETCONF [RFC 6241 [9]] to enterprise networks from a centralised 273 source hosted in service provider networks. The presence of 274 proprietary software logic for call and media handling in enterprise 275 devices would preclude the generation of a "one-size-fits-all" YANG 276 model. Additionally, service provider networks pushing configuration 277 to enterprises devices might lead to the loss of implementation 278 autonomy on the part of the enterprise network. 280 5. Overview of Operations 282 To solicit the capability set of a SIP service provider, the edge 283 element in an enterprise network generates a well-formed HTTPS GET 284 request. There are two reasons why it makes sense for the enterprise 285 edge element to generate the HTTPs request: 287 1. Edge elements are devices that normalise any mismatches between 288 the enterprise and service provider networks in the media and 289 signaling planes. As a result, when the capability set is 290 received from the SIP service provider network, the edge element 291 can generate appropriate configuration blocks (possibly across 292 multiple devices) to enable interconnection. 294 2. Given that edge elements are configured to "talk" to networks 295 external to the enterprise, the complexity in terms of NAT 296 traversal and firewall configuration would be minimal. 298 The HTTPS GET request is targeted at a capability server that is 299 managed by the SIP service provider such that this server processes, 300 and on successfully processing the request, includes the capability 301 set document in the response. The capability set document is 302 constructed according the guidelines of the YANG model described in 303 this draft. The capability set document included in a successful 304 response is formatted in either XML or JSON. The formatting depends 305 on the value of the "Accept" header field of the HTTP GET request. 306 More details about the formatting of the HTTP request and response 307 are provided in Section 6. 309 There could be situations wherein an enterprise telephony network 310 interconnects with its SIP service provider such that traffic between 311 the two networks traverses an intermediary SIP service provider 312 network. This could be a result of interconnect agreements between 313 the terminating and transit SIP service provider networks. In such 314 situations, the capability set provided to the enterprise network by 315 its SIP service provider must account for the characteristics of the 316 transit SIP service provider network from a signalling and media 317 perspective. For example, if the terminating SIP service provider 318 network supports the G.729 codec and the transit SIP service provider 319 network does not, G.729 must not be advertised in the capability set. 320 As another example, if the transit SIP service provider network 321 doesn't support a SIP extension, for instance, the SIP extension for 322 Reliable Provisional Responses as defined in RFC 3262, the 323 terminating SIP service provider network must not advertise support 324 for this extension in the capability set provided to the enterprise 325 network. How a terminating SIP service provider obtains the 326 characteristics of the intermediary SIP service provider network is 327 out of the scope of this document; however, one method could be for 328 the terminating SIP service provider to obtain the characteristics of 329 the intermediary SIP service provider by leveraging the YANG model 330 introduced in this document. 332 Figure 1 provides a reference architecture in which this workflow may 333 be implemented. The architecture depicted in Figure 1 consists of an 334 enterprise telephony network and a SIP service provider network, such 335 that the enterprise network attempts to provision SIP trunking 336 services for the first time. For the sake of simplicity, the 337 enterprise and service provider networks are decomposed into their 338 core constituent elements. 340 6. HTTP Transport 342 This section describes the use of HTTPS as a transport protocol for 343 the peering workflow. This workflow is based on HTTP version 1.1, 344 and as such is compatible with any future version of HTTP that is 345 backward compatible with HTTP 1.1. 347 6.1. HTTP Methods 349 The workflow defined in this document leverages the HTTPS GET method 350 and its corresponding response(s) to request for and subsequently 351 obtain the service provider capability set document. The HTTPS POST 352 method and its corresponding response(s) is also used for client 353 authentication. 355 6.2. Integrity and Confidentiality 357 Peering requests and responses are defined over HTTPS. However, due 358 to the sensitive nature of information transmitted between client and 359 server, it is required to secure HTTP using Transport Layer Security 360 [RFC 5246 [10]]. The enterprise edge element and capability server 361 MUST be compliant with RFC 7235 [11]. The enterprise edge element 362 and capability server MUST support the use of the https uri scheme as 363 defined in RFC 7230 [12]. 365 6.3. Authenticated Client Identity 367 It is only required for the SIP service provider to authenticate the 368 client (enterprise edge element). How the SIP service provider 369 authenticates the client is out of the scope of this document, 370 however, methods such as HTTP Digest Authentication may be used. 372 6.4. Encoding the Request 374 The edge element in the enterprise network generates a HTTPS GET 375 request such that the request-target is obtained using the procedure 376 outlined in section 6.6 The MIME types for the capability set 377 document defined in this draft are "application/peering-info+json" 378 and "application/peering-info+xml". Accordingly, the Accept header 379 field value MUST be restricted only to these MIME types. It is 380 possible that the edge element supports responses formatted in both 381 JSON and XML. In such situations, the edge element might generate a 382 HTTPS GET request such that the Accept header field includes both 383 MIME types along with the corresponding "qvalue" for each MIME type. 385 The generated HTTPS GET request must not use the "Expect" and "Range" 386 header fields. The requests must also not use any conditional 387 request. 389 6.5. Generating the response 391 Capability servers include the capability set documents in the body 392 of a successful response. Capability set documents MUST be formatted 393 in XML or JSON. For requests that are incorrectly formatted, the 394 capability server must generate a "400 Bad Request" response. If the 395 client (enterprise edge element) includes any other MIME types in 396 Accept header field other than "application/peering-info+json" or 397 "application/peering-info+xml", the capability set must reject the 398 request with a "406 Not Acceptable" response. 400 The capability server can respond to client requests with redirect 401 responses, specifically, the server can respond with the following 402 redirect responses: 404 1. 301 Moved Temporarily 406 2. 302 Found 408 3. 307 Temporary Redirect 410 The server SHOULD include the Location header field in such 411 responses. 413 6.6. Identifying the Request Target 415 HTTPS GET requests from enterprise edge elements MUST carry a valid 416 request-target. The enterprise edge element might obtain the URL of 417 the resource hosted on the capability server in one of two ways: 419 1. 1. Manual Configuration 421 2. 2. Discovery [TBD] 423 7. State Deltas 425 Given that the service provider capability set is largely expected to 426 remain static, the work needed to implement an asynchronous push 427 mechanism to encode minor changes in the capability set document 428 (state deltas) is not commensurate with the benefits. Rather, 429 enterprise edge elements can poll capability servers at pre-defined 430 intervals to obtain the full capability set document. It is 431 recommended that capability servers are polled every 24 hours. 433 8. Encoding the Service Provider Capability Set 435 In the context of this draft, the capability set of a service 436 provider refers collectively to a set of characteristics which when 437 communicated to an enterprise network, provides it with sufficient 438 information to directly peer with the service provider network. The 439 capability set document is not designed to encode extremely granular 440 details of all features, services, and protocol extensions that are 441 supported by the service provider network. For example, it is 442 sufficient to encode that the service provider uses T.38 relay for 443 faxing, it is not required to know the value of the 444 "T38FaxFillBitRemoval" parameter. 446 The parameters within the capability set document represent a wide 447 array of characteristics, such that these characteristics 448 collectively disseminate sufficient information to enable direct IP 449 peering between enterprise and service provider networks. The 450 various parameters represented in the capability set are chosen based 451 on existing practises and common problem sets typically seen between 452 enterprise and service provider SIP networks. 454 9. Data Model for Capability Set 456 This section defines a YANG module for encoding the service provider 457 capability set. Section 9.1 provides the tree diagram, which is 458 followed by a description of the various nodes within the module 459 defined in this draft. 461 9.1. Tree Diagram 463 This section provides a tree diagram [RFC 8340 [13]] for the "ietf- 464 capability-set" module. The interpretation of the symbols appearing 465 in the tree diagram is as follows: 467 o Brackets "[" and "]" enclose list keys. 469 o Abbreviations before data node names: "rw" means configuration 470 (read-write), and "ro" means state data (read-only). 472 o Symbols after data node names: "?" means an optional node, "!" 473 means a presence container, and "*" denotes a list and leaf-list. 475 o Parentheses enclose choice and case nodes, and case nodes are also 476 marked with a colon (":"). 478 o Ellipsis ("...") stands for contents of subtrees that are not 479 shown. 481 The data model for the peering capability document has the following 482 structure: 484 +--rw peering-response 485 +--rw variant string 486 +--rw transport-info 487 | +--rw transport? enumeration 488 | +--rw registrar* host-port 489 | +--rw registrarRealm? string 490 | +--rw callControl* host-port 491 | +--rw dns* inet:ip-address 492 | +--rw outboundProxy? host-port 493 +--rw call-specs 494 | +--rw earlyMedia? boolean 495 | +--rw signalingForking? boolean 496 | +--rw supportedMethods? string 497 | +--rw numRange 498 | +--rw numRangeType* string 499 | +--rw count* int32 500 | +--rw value* string 501 +--rw media 502 | +--rw mediaTypeAudio 503 | | +--rw mediaFormat* string 504 | +--rw fax 505 | | +--rw protocol* enumeration 506 | +--rw rtp 507 | | +--rw RTPTrigger? boolean 508 | | +--rw symmetricRTP? boolean 509 | +--rw rtcp 510 | +--rw symmetricRTCP? boolean 511 | +--rw RTCPfeedback? boolean 512 +--rw dtmf 513 | +--rw payloadNumber? int8 514 | +--rw iteration? boolean 515 +--rw security 516 | +--rw signaling 517 | +--rw type* string 518 | +--rw version* string 519 | +--rw mediaSecurity 520 | +--rw keyManagement? string 521 | +--rw certLocation string 522 +--rw extensions? string 524 9.2. YANG Model 526 This section defines the YANG module for the peering capability set 527 document. It imports modules (ietf-yang-types and ietf-inet-types) 528 from [RFC 6991 [14]]. 530 module ietf-sip-auto-peering { 531 namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering"; 532 prefix "peering"; 534 description 535 "Data model for transmitting peering parameters from SP to Enterprise"; 537 revision 2019-05-06 { 538 description "Initial revision of peering-response doc."; 539 } 541 import ietf-inet-types { 542 prefix "inet"; 543 } 545 typedef ipv4-address-port { 546 type string { 547 pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 548 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 549 + ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$'; 550 } 551 description "The ipv4-address-port type represents an IPv4 address in 552 dotted-quad notation followed by a port number."; 553 } 555 typedef ipv6-address-port { 556 type string { 557 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 558 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 559 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 560 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 561 + ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$'; 562 pattern 563 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 564 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 565 + ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$'; 566 } 567 description 568 "The ipv6-address type represents an IPv6 address in full, 569 mixed, shortened, and shortened-mixed notation followed by a port number."; 570 } 571 typedef ip-address-port { 572 type union { 573 type ipv4-address-port; 574 type ipv6-address-port; 575 } 576 description 577 "The ip-address-port type represents an IP address:port number 578 and is IP version neutral."; 579 } 581 typedef domain-name-port { 582 type string { 583 pattern 584 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 585 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 586 + '|\.' 587 + ':^()([1-9]|[1-5]?[0-9]{2,4}|6[1-4][0-9]{3}|65[1-4][0-9]{2}|655[1-2][0-9]|6553[1-5])$'; 588 length "1..258"; 589 } 590 description 591 "The domain-name-port type represents a DNS domain name followed by a port number. 592 The name SHOULD be fully qualified whenever possible."; 593 } 595 typedef host-port { 596 type union { 597 type ip-address-port; 598 type domain-name-port; 599 } 600 description 601 "The host type represents either an IP address or a DNS 602 domain name followed by a port number."; 603 } 605 container peering-info { 606 leaf variant { 607 type string; 608 mandatory true; 609 description "Variant of peering-response document"; 610 } 612 container transport-info { 613 leaf transport { 614 type enumeration { 615 enum "TCP"; 616 enum "TLS"; 617 enum "UDP"; 618 enum "TCP;TLS"; 619 enum "TCP;TLS;UDP"; 620 enum "TCP;UDP"; 621 } 622 description "Transport Protocol(s) used in SIP communication"; 623 } 625 leaf-list registrar { 626 type host-port; 627 max-elements 3; 628 description "List of service provider registrar servers"; 629 } 631 leaf registrarRealm { 632 type string; 633 description "Realm for REGISTER requests carrying credentials"; 634 } 636 leaf-list callControl { 637 type host-port; 638 max-elements 3; 639 description "List of service provider call control servers"; 640 } 642 leaf-list dns { 643 type inet:ip-address; 644 max-elements 2; 645 description "IP address of the DNS Server(s) hosted by the service provider"; 646 } 648 leaf outboundProxy { 649 type host-port; 650 description "SIP Outbound Proxy"; 651 } 652 } 654 container call-specs { 655 leaf earlyMedia { 656 type boolean; 657 description "Flag indicating whether the service provider is expected 658 to deliver early media."; 659 } 661 leaf signalingForking { 662 type boolean; 663 description "Flag indicating whether the service provider is capable 664 of forking incoming calls "; 665 } 666 leaf supportedMethods { 667 type string; 668 description "Leaf/Leaf List indicating the different SIP methods 669 support by the service provider."; 670 } 672 container numRange { 673 leaf numRangeType { 674 type string; 675 description "String indicating whether the DID number range is passed 676 by value or by reference" 677 } 679 leaf count { 680 when "../numRangeType = 'range' or ../numRangeType = 'block'"; 681 type int32; 682 description "Number of DID numbers present in the number range." 683 } 685 leaf-list value { 686 type string; 687 description "Value of the DID number range or URL being passed as 688 reference." 689 } 691 } 692 } 694 container media { 695 container mediaTypeAudio { 696 leaf-list mediaFormat { 697 type string; 698 description "Leaf List indicating the audio media formats supported."; 699 } 700 } 702 container fax { 703 leaf-list protocol { 704 type enumeration { 705 enum "pass-through"; 706 enum "t38"; 707 } 708 max-elements 2; 709 description "Leaf List indicating the different fax protocols 710 supported by the service provider."; 711 } 712 } 713 container rtp { 714 leaf RTPTrigger { 715 type boolean; 716 description "Flag indicating whether the service provider expects to 717 receive the first media packet."; 718 } 720 leaf symmetricRTP { 721 type boolean; 722 description "Flag indicating whether the service provider expects 723 symmetric RTP defined in [@RFC4961]"; 724 } 725 } 727 container rtcp { 728 leaf symmetricRTCP { 729 type boolean; 730 description " Flag indicating whether the service provider expects 731 symmetric RTP defined in [@RFC4961]."; 732 } 734 leaf RTCPfeedback { 735 type boolean; 736 description "Flag Indicating support for RTP profile extension for 737 RTCP-based feedback, as defined in [@RFC4585]"; 738 } 739 } 740 } 742 container dtmf { 743 leaf payloadNumber { 744 type int8 { 745 range "96..127"; 746 } 747 description "Leaf that indicates the payload number(s) supported by 748 the service provider for DTMF relay via Named-Telephony-Events"; 749 } 751 leaf iteration { 752 type boolean; 753 description "Flag identifying whether the service provider supports 754 NTE DTMF relay using the procedures of [@RFC2833] or [@RFC4733] ."; 755 } 756 } 758 container security { 759 container signaling { 760 leaf type { 761 type string { 762 pattern "TLS"; 763 } 764 description "Type of signaling security supported."; 765 } 767 leaf version { 768 type string { 769 pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)"; 770 } 771 description "Indicates TLS version for SIP signaling"; 772 } 773 } 775 container mediaSecurity { 776 leaf keyManagement { 777 type string { 778 pattern "(SDES(;DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]\.[0-9])?)?)|(DTLS-SRTP,version=[1-9]\.[0-9](,[1-9]\.[0-9])?)|(NULL)"; 779 } 780 description "Leaf that identifies the key management methods 781 supported by the service provider for SRTP."; 782 } 783 } 785 leaf certLocation { 786 type string; 787 description "Location of the service provider certificate chain for SIP over TLS."; 788 } 789 } 791 leaf extensions { 792 type string; 793 description "Lists the various SIP extensions supported by SP"; 794 } 795 } 796 } 798 9.3. Node Definitions 800 This sub-sections provides the definition and encoding rules of the 801 various nodes of the YANG module defined in section 9.2 803 *capability-set*: This node serves as a container for all the other 804 nodes in the YANG module; the capability-set node is akin to the root 805 element of an XML schema. 807 *variant*: This node identifies the version number of the capability 808 set document. This draft defines the parameters for variant 1.0; 809 future specifications might define a richer parameter set, in which 810 case the variant must be changed to 2.0, 3.0 and so on. Future 811 extensions to the capability set document MUST also ensure that the 812 corresponding YANG module is defined. 814 *transport-info*: The transport-info node is a container that 815 encapsulates transport characteristics of SIP sessions between 816 enterprise and service provider networks. 818 *transport*: A leaf node that enumerates the different Transport 819 Layer protocols supported by the SIP service provider. Valid 820 transport layer protocols include: UDP, TCP, TLS or a combination of 821 them (with the exception of TLS and UDP). 823 *registrar*: A leaf-list that specifies the transport address of one 824 or more registrar servers in the service provider network. The 825 transport address of the registrar can be provided using a 826 combination of a valid IP address and port number, or a subdomain of 827 the SIP service provider network, or the fully qualified domain name 828 (FQDN) of the SIP service provider network. If the transport address 829 of a registrar is specified using either a subdomain or a fully 830 qualified domain name, the DNS element must be populated with one or 831 more valid DNS server IP addresses. 833 *callControl*: A leaf-list that specifies the transport address of 834 the call server(s) in the service provider network. The enterprise 835 network must use an applicable transport protocol in conjunction with 836 the call control server(s) transport address when transmitting call 837 setup requests. The transport address of a call server(s) within the 838 service provider network can be specified using a combination of a 839 valid IP address and port number, or a subdomain of the SIP service 840 provider network, or a fully qualified domain name of the SIP service 841 provider network. If the transport address of a call control 842 server(s) is specified using either a subdomain or a fully qualified 843 domain name, the DNS element must be populated with one or more valid 844 DNS server IP addresses. The transport address specified in this 845 element can also serve as the target for non-call requests such as 846 SIP OPTIONS. 848 *dns*: A leaf list that encodes the IP address of one or more DNS 849 servers hosted by the SIP service provider. If the enterprise 850 network is unaware of the IP address, port number, and transport 851 protocol of servers within the service provider network (for example, 852 the registrar and call control server), it must use DNS NAPTR and 853 SRV. Alternatively, if the enterprise network has the fully 854 qualified domain name of the SIP service provider network, it must 855 use DNS to resolve the said FQDN to an IP address. The dns element 856 encodes the IP address of one or more DNS servers hosted in the 857 service provider network. If however, either the registrar or 858 callControl elements or both are populated with a valid IP address 859 and port pair, the dns element must be set to the quadruple octet of 860 0.0.0.0 862 *outboundProxy*: A leaf list that specifies the transport address of 863 one or more outbound proxies. The transport address can be specified 864 by using a combination of an IP address and a port number, a 865 subdomain of the SIP service provider network, or a fully qualified 866 domain name and port number of the SIP service provider network. If 867 the outbound-proxy sub-element is populated with a valid transport 868 address, it represents the default destination for all outbound SIP 869 requests and therefore, the registrar and callControl elements must 870 be populated with the quadruple octet of 0.0.0.0 872 *call-specs*: A container that encapsulates information about call 873 specifications, restrictions and additional handling criteria for SIP 874 calls between the enterprise and service provider network. 876 *earlyMedia*: A leaf that specifies whether the service provider 877 network is expected to deliver in-band announcements/tones before 878 call connect. The P-Early-Media header field can be used to indicate 879 pre-connect delivery of tones and announcements on a per-call basis. 880 However, given that signalling and media could traverse a large 881 number of intermediaries with varying capabilities (in terms of 882 handling of the P-Early-Media header field) within the enterprise, 883 such devices can be appropriately configured for media cut through if 884 it is known before-hand that early media is expected for some or all 885 of the outbound calls. This element is a Boolean type, where a value 886 of 1/true signifies that the service provider is capable of early 887 media. A value of 0/false signifies that the service provider is not 888 expected to generate early media. 890 *signalingForking*: A leaf that specifies whether outbound call 891 requests from the enterprise might be forked on the service provider 892 network that MAY lead to multiple early dialogs. This information 893 would be useful to the enterprise network in appropriately handling 894 multiple early dialogs reliably and in enforcing local policy. This 895 element is a Boolen type, where a value of 1/true signifies that the 896 service provider network can potentially fork outbound call requests 897 from the enterprise. A value of 0/false indicates that the service 898 provider will not fork outbound call requests. 900 *supportedMethods*: A leaf node that specifies the various SIP 901 methods supported by the SIP service provider. The list of supported 902 methods help to appropriately configuration various devices within 903 the enterprise network. For example, if the service provider 904 enumerates support for the OPTIONS method, the enterprise network 905 could periodically send OPTIONS requests as a keep-alive mechanism. 907 *numRange*: Is a container that specifies the Direct Inward Dial 908 (DID) number range allocated to the enterprise network by the SIP 909 service provider. The DID number range allocated by the service 910 provider to the enterprise network might be a contiguous or a non- 911 contiguous block. The number range allocated to an enterprise can be 912 communicated as a value or as a reference. For large enterprise 913 networks, the size of the DID range might run into several hundred 914 numbers. For situations in which the enterprise is allocated a large 915 DID number range or a non-contiguous number range it is RECOMMENDED 916 that the SIP service provider communicate this information by 917 reference, that is, through a URL. The enterprise network is 918 required to de-reference this URL in order to obtain the DID number 919 range allocated by the SIP service provider. The numRange container 920 can be used more than once. Refer to the example provided in 921 Section 10.1. 923 *numRangeType*: A leaf node that indicates whether the DID range is 924 communicated by value or by reference. It can have a value of 925 'range', 'block' or 'reference'. 927 *count*: A leaf node that indicates the size of the DID number range. 928 The number range may be contiguous or non-contiguous. This leaf node 929 MUST NOT be included when using the 'reference' numRangeType value. 931 *value*: A leaf-list that encapsulates the DID number range allocated 932 to the enterprise. If the numRangeType value is set to 'range' or 933 'block', this is the list of numbers allocated to the enterprise. If 934 the numRangeType value is set to 'reference', this is the URL of the 935 resource containing the DID number range. To ensure ease of parsing, 936 it is RECOMMENDED that the resource contain a number range formatted 937 as if it were being passed as a block or range. 939 *media*: A container that is used to collectively encapsulate the 940 characteristics of UDP-based audio streams. A future extension to 941 this draft may extend the media container to describe other media 942 types. The media container is also used to encapsulate basic 943 information about Real-Time Transport Protocol (RTP) and Real-Time 944 Transport Control Protocol (RTCP) from the perspective of the service 945 provider network. 947 *mediaTypeAudio*: A container for the mediaFormat leaf-list. This 948 container collectively encapsulates the various audio media formats 949 supported by the SIP service provider. 951 *mediaFormat*: A leaf-list encoding the various audio media formats 952 supported by the SIP service provider. The relative ordering of 953 different media format leaf nodes from left to right indicates 954 preference from the perspective of the service provider. Each 955 mediaFormat node begins with the encoding name of the media format, 956 which is the same encoding name as used in the "RTP/AVP" and "RTP/ 957 SAVP" profiles. The encoding name is followed by required and 958 optional parameters for the given media format as specified when the 959 media format is registered [RFC 4855 [15]]. Given that the 960 parameters of media formats can vary from one communication session 961 to another, for example, across two separate communication sessions, 962 the packetization time (ptime) used for the PCMU media format might 963 vary from 10 to 30 ms, the parameters included in the format element 964 must be the ones that are expected to be invariant from the 965 perspective of the service provider. Providing information about 966 supported media formats and their respective parameters, allows 967 enterprise networks to configure the media plane characteristics of 968 various devices such as endpoints and middleboxes. The encoding 969 name, one or more required parameters, one or more optional 970 parameters are all separated by a semicolon. The formatting of a 971 given media format parameter, must follow the formatting rules as 972 specified for that media format. 974 *fax*: A container that encapsulates the fax protocol(s) supported by 975 the SIP service provider. The fax container encloses a leaf-list 976 (named protocol) that enumerates whether the service provider 977 supports t38 relay, protocol-based fax passthrough or both. The 978 relative ordering of leaf nodes within the leaf lists indicates 979 preference. 981 *rtp*: A container that encapsulates generic characteristics of RTP 982 sessions between the enterprise and service provider network. This 983 node is a container for the "RTPTrigger" and "SymmetricRTP" leaf 984 nodes. 986 *RTPTrigger*: A leaf node indicating whether the SIP service provider 987 network always expects the enterprise network to send the first RTP 988 packet for an established communication session. This information is 989 useful in scenarios such as "hairpinned" calls, in which the caller 990 and callee are on the service provider network and because of sub- 991 optimal media routing, an enterprise device such as an SBC is 992 retained in the media path. Based on the encoding of this node, it 993 is possible to configure enterprise devices such as SBCs to start 994 streaming media (possibly filled with silence payloads) toward the 995 address:port tuples provided by caller and callee. This node is a 996 Boolean type. A value of 1/true indicates that the service provider 997 expects the enterprise network to send the first RTP packet, whereas 998 a value of 0/false indicates that the service provider network does 999 not require the enterprise network to send the first media packet. 1000 While the practise of preserving the enterprise network in a 1001 hairpinned call flow is fairly common, it is recommended that SIP 1002 service providers avoid this practise. In the context of a 1003 hairpinned call, the enterprise device retained in the call flow can 1004 easily eavesdrop on the conversation between the offnet parties. 1006 *symmetricRTP*: A leaf node indicating whether the SIP service 1007 provider expects the enterprise network to use symmetric RTP as 1008 defined in RFC 4961 [16]. Uncovering this expectation is useful in 1009 scenarios where "latching" [RFC 7362 [17]] is implemented in the 1010 service provider network. This node is a Boolean type, a value of 1/ 1011 true indicates that the service provider expects the enterprise 1012 network to use symmetric RTP, whereas a value of 0/false indicates 1013 that the enterprise network can use asymmetric RTP. 1015 *rtcp*: A container that encapsulates generic characteristics of RTCP 1016 sessions between the enterprise and service provider network. This 1017 node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf 1018 nodes. 1020 *RTCPFeedback*: A leaf node that indicates whether the SIP service 1021 provider supports the RTP profile extension for RTCP-based feedback 1022 RFC 4585 [18]. Media sessions spanning enterprise and service 1023 provider networks, are rarely made to flow directly between the 1024 caller and callee, rather, it is often the case that media traffic 1025 flows through network intermediaries such as SBCs. As a result, RTCP 1026 traffic from the service provider network is intercepted by these 1027 intermediaries, which in turn can either pass across RTCP traffic 1028 unmodified or modify RTCP traffic before it is forwarded to the 1029 endpoint in the enterprise network. Modification of RTCP traffic 1030 would be required, for example, if the intermediary has performed 1031 media payload transformation operations such as transcoding or 1032 transrating. In a similar vein, for the RTCP-based feedback 1033 mechanism as defined in RFC 4585 [19] to be truly effective, 1034 intermediaries must ensure that feedback messages are passed reliably 1035 and with the correct formatting to enterprise endpoints. This might 1036 require additional configuration and considerations that need to be 1037 dealt with at the time of provisioning the intermediary device. This 1038 node is a Boolean type, a value of 1/true indicates that the service 1039 provider supports the RTP profile extension for RTP-based feedback 1040 and a value of 0/false indicates that the service provider does not 1041 support the RTP profile extension for RTP-based feedback. 1043 *symmetricRTCP*: A leaf node indicating whether the SIP service 1044 provider expects the enterprise network to use symmetric RTCP as 1045 defined in RFC 4961 [20]. This node is a Boolean type, a value of 1 1046 indicates that the service provider expects symmetric RTCP reports, 1047 whereas a value of 0 indicates that the enterprise can use asymmetric 1048 RTCP. 1050 *dtmf*: A container that describes the various aspects of DTMF relay 1051 via RTP Named Telephony Events. The dtmf container allows SIP 1052 service providers to specify two facets of DTMF relay via Named 1053 Telephony Events: 1055 1. The payload type number using the payloadNumber leaf node. 1057 2. Support for RFC 2833 [21] or RFC 4733 [22] using the iteration 1058 leaf node. 1060 In the context of named telephony events, senders and receivers may 1061 negotiate asymmetric payload type numbers. For example, the sender 1062 might advertise payload type number 97 and the receiver might 1063 advertise payload type number 101. In such instances, it is either 1064 required for middleboxes to interwork payload type numbers or allow 1065 the endpoints to send and receive asymmetric payload numbers. The 1066 behaviour of middleboxes in this context is largely dependent on 1067 endpoint capabilities or on service provider constraints. Therefore, 1068 the payloadNumber leaf node can be used to determine middlebox 1069 configuration before-hand. 1071 RFC 4733 [23] iterates over RFC 2833 [24] by introducing certain 1072 changes in the way NTE events are transmitted. SIP service providers 1073 can indicate support for RFC 4733 [25] by setting the iteration flag 1074 to 1 or indicating support for RFC 2833 [26] by setting the iteration 1075 flag to 0. 1077 *security*: A container that encapsulates characteristics about 1078 encrypting signalling streams between the enterprise and SIP service 1079 provider networks. 1081 *signaling*: A container that encapsulates the type of security 1082 protocol for the SIP communication between the enterprise SBC and the 1083 service provider. 1085 *type*: A leaf node that specifies the protocol used for protecting 1086 SIP signalling messages between the enterprise and service provider 1087 network. The value of the type leaf node is only defined for 1088 Transport Layer Security (TLS). Accordingly, if TLS is allowed for 1089 SIP sessions between the enterprise and service provider network, the 1090 type leaf node is set to the string "tls". 1092 *version*: A leaf node that specifies the version(s) of TLS supported 1093 in decimal format. If multiple versions of TLS are supported, they 1094 should be separated by semi-colons. If the service provide does not 1095 support TLS for protecting SIP sessions, the signalling element is 1096 set to the string "NULL". 1098 *mediaSecurity*: A container that describes the various 1099 characteristics of securing media streams between enterprise and 1100 service provider networks. 1102 *keyManagement*: A leaf node that specifies the key management method 1103 used by the service provider. Possible values of this node include: 1104 "SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP 1105 service provider uses the methods defined in RFC 4568 [27] for the 1106 purpose of key management. A value of "DTLS-SRTP" signifies that the 1107 SIP service provider uses the methods defined in RFC 5764 [28] for 1108 the purpose of key management. If the value of this leaf node is set 1109 to "DTLS-SRTP", the various versions of DTLS supported by the SIP 1110 service provider MUST be encoded as per the formatting rules of 1111 Section 9.2. If the service provider does not support media 1112 security, the keyManagement node MUST be set to "NULL". 1114 *certLocation:*: If the enterprise network is required to exchange 1115 SIP traffic over TLS with the SIP service provider, and if the SIP 1116 service provider is capable of accepting TLS connections from the 1117 enterprise network, it may be required for the SIP service provider 1118 certificates to be pre-installed on the enterprise edge element. In 1119 such situations, the certLocation leaf node is populated with a URL, 1120 which when dereferenced, provides a single PEM encoded file that 1121 contains all certificates in the chain of trust. This is an optional 1122 leaf node. 1124 *extensions*: A leaf node that is a semicolon separated list of all 1125 possible SIP option tags supported by the service provider network. 1126 These extensions must be referenced using name registered under IANA. 1127 If the service provider network does not support any extensions to 1128 baseline SIP, the extensions node must be set to "NULL". 1130 9.4. Extending the Capability Set 1132 There are situations in which equipment manufactures or service 1133 providers would benefit from extending the YANG module defined in 1134 this draft. For example, service providers could extend the YANG 1135 module to include information that further simplifies direct IP 1136 peering. Such information could include: trunk group identifiers, 1137 direct-inward-dial (DID) number ranges allocated to the enterprise, 1138 customer/enterprise account numbers, service provider support 1139 numbers, among others. Extension of the module can be achieved by 1140 importing the module defined in this draft. An example is provided 1141 below: Consider a new YANG module "vendorA" specified for VendorA's 1142 enterprise SBC. The "vendorA-config" YANG module is configured as 1143 follows: 1145 module vendorA-config { 1146 namespace "urn:ietf:params:xml:ns:yang:vendorA-config"; 1147 prefix "vendorA"; 1149 description 1150 "Data model for configuring VendorA Enterprise SBC"; 1152 revision 2020-05-06 { 1153 description "Initial revision of VendorA Enterprise SBC configuration data model"; 1154 } 1156 import ietf-peering { 1157 prefix "peering"; 1158 } 1160 augment "/peering:peering-info" { 1161 container vendorAConfig { 1162 leaf vendorAConfigParam1 { 1163 type int32; 1164 description "vendorA configuration parameter 1 (SBC Device ID)"; 1165 } 1167 leaf vendorAConfigParam2 { 1168 type string; 1169 description "vendorA configuration parameter 2 (SBC Device name)"; 1170 } 1171 description "Container for vendorA SBC configuration"; 1172 } 1173 } 1174 } 1176 In the example above, a custom module named "vendorA-config" uses the 1177 "augment" statement as defined in Section 4.2.8 of [RFC 7950 [29]] to 1178 extend the module defined in this draft. 1180 10. Example Capability Set Document Encoding 1182 This section provides examples of how capability set documents that 1183 leverage the YANG module defined in this document can be encoded over 1184 JSON or XML. 1186 10.1. XML Capability Set Document 1188 1191 1.0 1192 1193 TCP;TLS;UDP 1194 registrar1.voip.example.com:5060 1195 registrar2.voip.example.com:5060 1196 voip.example.com 1197 callServer1.voip.example.com:5060 1198 192.168.12.25:5065 1199 8.8.8.8 1200 208.67.222.222 1201 0.0.0.0 1202 1203 1204 true 1205 false 1206 INVITE;OPTIONS;BYE;CANCEL;ACK;PRACK;SUBSCRIBE;NOTIFY;REGISTER 1207 1208 range 1209 20 1210 19725455000 1211 1212 1213 block 1214 2 1215 1972546000 1216 1972546001 1217 1218 1219 1220 1221 PCMU;rate=8000;ptime=20 1222 G729;rate=8000;annexb=yes 1223 G722;rate=8000;bitrate=56k,64k 1224 1225 1226 pass-through 1227 t38 1228 1229 1230 true 1231 true 1232 1233 1234 true 1235 true 1236 1237 1238 1239 101 1240 0 1241 1242 1243 1244 TLS 1245 1.0;1.2 1246 1247 1248 SDES;DTLS-SRTP,version=1.2 1249 1250 https://sipserviceprovider.com/certificateList.pem 1251 1252 timer;rel100;gin;path 1253 1255 11. Example Exchange 1257 This section depicts an example of the configuration flow that 1258 ultimately results in the enterprise edge element obtaining the 1259 capability set document from the SIP service provider. Assuming the 1260 enterprise edge element has been pre-configured with the request 1261 target for the capability set document or has dynamically found the 1262 request target, the edge element generates a HTTPS GET request. This 1263 request can be challenged by the service provider to authenticate the 1264 enterprise. 1266 GET //capdoc?trunkid=trunkent1456 HTTP/1.1 1267 Host: capserver.ssp1.com 1268 Accept:application/peering-info+xml 1270 The capability set document is obtained in the body of the response 1271 and is encoded in XML. 1273 HTTP/1.1 200 OK 1274 Content-Type: application/peering-info+xml 1275 Content-Length: nnn 1277 1278 ... 1279 1281 12. Security Considerations 1283 [TBD] 1285 13. Acknowledgments 1287 [TBD] 1289 14. References 1291 14.1. Normative References 1293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1294 Requirement Levels", BCP 14, RFC 2119, 1295 DOI 10.17487/RFC2119, March 1997, 1296 . 1298 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 1299 Digits, Telephony Tones and Telephony Signals", RFC 2833, 1300 DOI 10.17487/RFC2833, May 2000, 1301 . 1303 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1304 A., Peterson, J., Sparks, R., Handley, M., and E. 1305 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1306 DOI 10.17487/RFC3261, June 2002, 1307 . 1309 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1310 "Extended RTP Profile for Real-time Transport Control 1311 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1312 DOI 10.17487/RFC4585, July 2006, 1313 . 1315 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1316 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1317 DOI 10.17487/RFC4733, December 2006, 1318 . 1320 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1321 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1322 . 1324 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1325 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 1326 . 1328 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1329 (TLS) Protocol Version 1.2", RFC 5246, 1330 DOI 10.17487/RFC5246, August 2008, 1331 . 1333 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1334 the Network Configuration Protocol (NETCONF)", RFC 6020, 1335 DOI 10.17487/RFC6020, October 2010, 1336 . 1338 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1339 and A. Bierman, Ed., "Network Configuration Protocol 1340 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1341 . 1343 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1344 DOI 10.17487/RFC6665, July 2012, 1345 . 1347 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1348 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1349 . 1351 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1352 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1353 . 1355 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 1356 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 1357 2013, . 1359 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1360 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1361 DOI 10.17487/RFC7231, June 2014, 1362 . 1364 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 1365 Traversal (HNT) for Media in Real-Time Communication", 1366 RFC 7362, DOI 10.17487/RFC7362, September 2014, 1367 . 1369 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1370 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1371 . 1373 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1374 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1375 . 1377 Authors' Addresses 1379 Kaustubh Inamdar 1380 Cisco Systems 1382 Email: kinamdar@cisco.com 1384 Sreekanth Narayanan 1385 Cisco Systems 1387 Email: sreenara@cisco.com 1389 Cullen Jennings 1390 Cisco Systems 1392 Email: fluffy@iii.ca