idnits 2.17.1 draft-kinamdar-dispatch-sip-auto-peer-05.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 are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 362: '... MUST be compliant with RFC 7235 [11]. The enterprise edge element...' RFC 2119 keyword, line 363: '...apability server MUST support the use ...' RFC 2119 keyword, line 380: '... field value MUST be restricted only...' RFC 2119 keyword, line 393: '...bility set documents MUST be formatted...' RFC 2119 keyword, line 411: '... The server SHOULD include the Locat...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2021) is 1182 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: 'TBD' on line 1356 -- Looks like a reference, but probably isn't: '0-9' on line 779 -- Looks like a reference, but probably isn't: '1-9' on line 779 -- Looks like a reference, but probably isn't: '0-4' on line 561 -- Looks like a reference, but probably isn't: '0-5' on line 561 -- Looks like a reference, but probably isn't: '1-5' on line 588 -- Looks like a reference, but probably isn't: '1-4' on line 588 -- Looks like a reference, but probably isn't: '1-2' on line 588 == Missing Reference: '01' is mentioned on line 561, but not defined == Missing Reference: '16' is mentioned on line 1393, but not defined == Missing Reference: '21' is mentioned on line 1403, but not defined == Missing Reference: '22' is mentioned on line 1405, but not defined == Missing Reference: '23' is mentioned on line 1407, but not defined == Missing Reference: '24' is mentioned on line 1409, but not defined == Missing Reference: '25' is mentioned on line 1411, but not defined == Missing Reference: '26' is mentioned on line 1413, but not defined == Missing Reference: '27' is mentioned on line 1415, but not defined == Missing Reference: '28' is mentioned on line 1417, but not defined == Missing Reference: '30' is mentioned on line 1421, but not defined == Missing Reference: '31' is mentioned on line 1423, but not defined == Missing Reference: '33' is mentioned on line 1427, but not defined == Missing Reference: '35' is mentioned on line 1431, but not defined == Missing Reference: '36' is mentioned on line 1433, but not defined == Missing Reference: '39' is mentioned on line 1439, but not defined == Missing Reference: '40' is mentioned on line 1441, but not defined == Missing Reference: '41' is mentioned on line 1443, but not defined == Missing Reference: '42' is mentioned on line 1445, but not defined == Missing Reference: '43' is mentioned on line 1447, but not defined == Missing Reference: '44' is mentioned on line 1449, but not defined == Missing Reference: '45' is mentioned on line 1451, but not defined == Missing Reference: '48' is mentioned on line 1457, but not defined == Missing Reference: '29' is mentioned on line 1419, but not defined == Missing Reference: '32' is mentioned on line 1425, but not defined == Missing Reference: '34' is mentioned on line 1429, but not defined == Missing Reference: '37' is mentioned on line 1435, but not defined == Missing Reference: '46' is mentioned on line 1453, but not defined == Missing Reference: '47' is mentioned on line 1455, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 3 errors (**), 0 flaws (~~), 32 warnings (==), 11 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: July 31, 2021 C. Jennings 5 Cisco Systems 6 January 27, 2021 8 Automatic Peering for SIP Trunks 9 draft-kinamdar-dispatch-sip-auto-peer-05 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 July 31, 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 80 13.2. Informative References . . . . . . . . . . . . . . . . . 28 81 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 82 15.1. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 85 1. Introduction 87 The deployment of a Session Initiation Protocol [RFC 3261 [1]] (SIP)- 88 based infrastructure in enterprise and service provider communication 89 networks is increasing at a rapid pace. Consequently, direct IP 90 peering between enterprise and service provider networks is quickly 91 replacing traditional methods of interconnection between enterprise 92 and service provider networks. Currently published standards provide 93 a strong foundation over which direct IP peering can be realized. 94 However, given the sheer number of these standards, it is often not 95 clear which behavioral subsets, extensions to baseline protocols and 96 operating principles ought to be implemented by service provider and 97 enterprise networks to ensure successful peering. 99 The SIP Connect technical recommendations [2] aim to solve this 100 problem by providing a master reference that promotes seamless 101 peering between enterprise and service provider SIP networks. 102 However, despite the extensive set of implementation rules and 103 operating guidelines, interoperability issues between service 104 provider and enterprise networks persist. This is in large part 105 because service providers and equipment manufacturers aren't required 106 to enforce the guidelines of the technical specifications and have a 107 fair degree of freedom to deviate from them. Consequently, 108 enterprise administrators usually undertake a fairly rigorous regimen 109 of testing, analysis and troubleshooting to arrive at a configuration 110 block that ensures seamless service provider peering. However, this 111 workflow complements the SIP Connect technical recommendations, in 112 that both endeavours aim to promote/achieve interop between the 113 enterprise and service provider. 115 Another set of interoperability problems arise when enterprise 116 administrators are required to translate a set of technical 117 recommendations from service providers to configuration blocks across 118 one or more devices in the enterprise, which is usually an error 119 prone exercise. Additionally, such technical recommendations might 120 not be nuanced enough to intuitively allow the generation of specific 121 configuration blocks. 123 This draft introduces a mechanism using which an enterprise network 124 can solicit a detailed capability set from a SIP service provider; 125 the detailed capability set can subsequently be used by automaton or 126 an administrator to generate configuration blocks across one or more 127 devices within the enterprise to ensure successful service provider 128 peering. 130 2. Conventions and Terminology 132 The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 133 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 134 this document are to be interpreted as described in RFC 2119 [3] 136 3. Reference Architecture 138 Figure 1 illustrates a reference architecture that may be deployed to 139 support the mechanism described in this document. The enterprise 140 network consists of a SIP-PBX, media endpoints and a Session Border 141 Controller [RFC 7092 [4]]. It may also include additional components 142 such as application servers for voicemail, recording, fax etc. At a 143 high level, the service provider consists of a SIP signaling entity 144 (SP-SSE), a media entity and a HTTPS [RFC 7231 [5]] server. 146 +-----------------------------------------------------+ 147 | +---------------+ +-----------------------+ | 148 | | | | | | 149 | | +----------+ | | +-------+ | | 150 | | | Cap | | HTTPS | | | | | 151 | | | Server |<-|---------|-->| | | | 152 | | | | | | | | +-----+ | | 153 | | +----------+ | | | | | SIP | | | 154 | | | | | |<->| PBX | | | 155 | | | | | | +-----+ | | 156 | | +----------+ | | | SBC | | | 157 | | | | | SIP | | | | | 158 | | | SP - SSE |<-|---------|-->| | +-----+ | | 159 | | | | | | | |<->| M.E.| | | 160 | | +----------+ | | | | | | | | 161 | | | | | | +-----+ | | 162 | | +----------+ | (S)RTP | | | | | 163 | | | Media |<-|---------|-->+-------+ | | 164 | | +----------+ | | | | 165 | +---------------+ +-----------------------+ | 166 | | 167 +-----------------------------------------------------+ 169 Figure 1: Reference Architecture 171 This draft makes use of the following terminology: 173 o Enterprise Network: A communications network infrastructure 174 deployed by an enterprise which interconnects with the service 175 provider network over SIP. The enterprise network could include 176 devices such as application servers, endpoints, call agents and 177 edge devices, among others. 179 o Edge Device: A device that is the last hop in the enterprise 180 network and that is the transit point for traffic entering and 181 leaving the enterprise. An edge device is typically a back-to- 182 back user agent (B2BUA) [RFC 7092 [6]] such as a Session Border 183 Controller (SBC). 185 o Service Provider Network: A communications network infrastructure 186 deployed by service providers. In the context of this draft, the 187 service provider network is accessible over SIP for the 188 establishment, modification and termination of calls and 189 accessible over HTTPS for the transfer of the capability set 190 document. The service provider network is also referred to as a 191 SIP Service Provider (SSP) or Internet Telephony Service Provider 192 (ITSP) network. 194 o Call Control: Call Control within a telephony networks refers to 195 software that is responsible for delivering its core 196 functionality. Call control not only provides the basic 197 functionality of setting up, sustaining and terminating calls, but 198 also provides the necessary control and logic required for 199 additional services within the telephony network. 201 o Capability Server: A server hosted in the service provider 202 network, such that this server is the target for capability set 203 document requests from the enterprise network. 205 o Capability Set: This specification uses the term capability set 206 (or capability set document) to refer collectivity to a set of 207 characteristics within the service provider network, which when 208 communicated to the enterprise network, provides the enterprise 209 network the information required to interconnect with the service 210 provider network. The various parameters that constitute the 211 capability set relate to characteristics that are specific to 212 signalling, media, transport and security. Certain aspects of 213 interconnecting with service providers are out of scope of the 214 capability set. For example, the access technology used to 215 interconnect with service provider networks. 217 4. Configuration Workflow 219 A workflow that facilitates an enterprise network to solicit the 220 capability set of a SIP service provider ought to take into account 221 the following considerations: 223 o The configuration workflow must be based on a protocol or a set of 224 protocols commonly used between enterprise and service provider 225 telephony networks. 227 o The configuration workflow must be flexible enough to allow the 228 service provider network to dynamically offload different 229 capability sets to different enterprise networks based on the 230 identity of the enterprise network. 232 o Capability set documents obtained as a result of the configuration 233 workflow must be conducive to easy parsing by automaton. 234 Subsequently, automaton may be used for generation of appropriate 235 configuration blocks. 237 Taking the above considerations into account, this document proposes 238 a Hypertext Transfer Protocol (HTTP)-based workflow using which the 239 enterprise network can solicit and ultimately obtain the service 240 provider capability set. The enterprise network creates a well 241 formed HTTPS GET request to solicit the service provider capability 242 set. Subsequently, the HTTPS response from the SIP service provider 243 includes the capability set. The capability set is encoded in either 244 XML or JSON, thus ensuring that the response can be easily parsed by 245 automaton. 247 There are alternative mechanisms using which the SIP service provider 248 can offload its capability set. For example, the Session Initiation 249 Protocol (SIP) can be extended to define a new event package [RFC 250 6665 [7]], such that the enterprise network can establish a SIP 251 subscription with the service provider for its capability set; the 252 SIP service provider can subsequently use the SIP NOTIFY request to 253 communicate its capability set or any state deltas to its baseline 254 capability set. 256 This mechanism is likely to result in a barrier to adoption for SIP 257 service providers and enterprise networks as equipment manufacturers 258 would have to first add support for such a SIP extension. A HTTPS- 259 based approach would be relatively easier to adopt as most edge 260 devices deployed in enterprise networks today already support HTTPS; 261 from the perspective of service provider networks, all that is 262 required is for them to deploy HTTPS servers that function as 263 capability servers. Additionally, most SIP service providers require 264 enterprise networks to register with them (using a SIP REGISTER 265 message) before any other SIP methods that initiate subscriptions 266 (SIP SUBSCRIBE) or calls (SIP INVITE) are processed. As a result, a 267 SIP-based framework to obtain a capability set would require 268 operational changes on the part of service provider networks. 270 Yet another example of an alternative mechanism would be for service 271 providers and enterprise equipment manufacturers to agree on YANG 272 models [RFC 6020 [8]] that enable configuration to be pushed over 273 NETCONF [RFC 6241 [9]] to enterprise networks from a centralised 274 source hosted in service provider networks. The presence of 275 proprietary software logic for call and media handling in enterprise 276 devices would preclude the generation of a "one-size-fits-all" YANG 277 model. Additionally, service provider networks pushing configuration 278 to enterprises devices might lead to the loss of implementation 279 autonomy on the part of the enterprise network. 281 5. Overview of Operations 283 To solicit the capability set of a SIP service provider, the edge 284 element in an enterprise network generates a well-formed HTTPS GET 285 request. There are two reasons why it makes sense for the enterprise 286 edge element to generate the HTTPs request: 288 1. Edge elements are devices that normalise any mismatches between 289 the enterprise and service provider networks in the media and 290 signaling planes. As a result, when the capability set is 291 received from the SIP service provider network, the edge element 292 can generate appropriate configuration blocks (possibly across 293 multiple devices) to enable interconnection. 295 2. Given that edge elements are configured to "talk" to networks 296 external to the enterprise, the complexity in terms of NAT 297 traversal and firewall configuration would be minimal. 299 The HTTPS GET request is targeted at a capability server that is 300 managed by the SIP service provider such that this server processes, 301 and on successfully processing the request, includes the capability 302 set document in the response. The capability set document is 303 constructed according the guidelines of the YANG model described in 304 this draft. The capability set document included in a successful 305 response is formatted in either XML or JSON. The formatting depends 306 on the value of the "Accept" header field of the HTTPS GET request. 307 More details about the formatting of the HTTPS request and response 308 are provided in Section 6. 310 There could be situations wherein an enterprise telephony network 311 interconnects with its SIP service provider such that traffic between 312 the two networks traverses an intermediary SIP service provider 313 network. This could be a result of interconnect agreements between 314 the terminating and transit SIP service provider networks. In such 315 situations, the capability set provided to the enterprise network by 316 its SIP service provider must account for the characteristics of the 317 transit SIP service provider network from a signalling and media 318 perspective. For example, if the terminating SIP service provider 319 network supports the G.729 codec and the transit SIP service provider 320 network does not, G.729 must not be advertised in the capability set. 321 As another example, if the transit SIP service provider network 322 doesn't support a SIP extension, for instance, the SIP extension for 323 Reliable Provisional Responses as defined in RFC 3262, the 324 terminating SIP service provider network must not advertise support 325 for this extension in the capability set provided to the enterprise 326 network. How a terminating SIP service provider obtains the 327 characteristics of the intermediary SIP service provider network is 328 out of the scope of this document; however, one method could be for 329 the terminating SIP service provider to obtain the characteristics of 330 the intermediary SIP service provider by leveraging the YANG model 331 introduced in this document. 333 Figure 1 provides a reference architecture in which this workflow may 334 be implemented. The architecture depicted in Figure 1 consists of an 335 enterprise telephony network and a SIP service provider network, such 336 that the enterprise network attempts to provision SIP trunking 337 services for the first time. For the sake of simplicity, the 338 enterprise and service provider networks are decomposed into their 339 core constituent elements. 341 6. HTTP Transport 343 This section describes the use of HTTPS as a transport protocol for 344 the peering workflow. This workflow is based on HTTP version 1.1, 345 and as such is compatible with any future version of HTTP that is 346 backward compatible with HTTP 1.1. 348 6.1. HTTP Methods 350 The workflow defined in this document leverages the HTTPS GET method 351 and its corresponding response(s) to request for and subsequently 352 obtain the service provider capability set document. The HTTPS POST 353 method and its corresponding response(s) is also used for client 354 authentication. 356 6.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 [10]]. The enterprise edge element and capability server 362 MUST be compliant with RFC 7235 [11]. The enterprise edge element 363 and capability server MUST support the use of the https uri scheme as 364 defined in RFC 7230 [12]. 366 6.3. Authenticated Client Identity 368 It is only required for the SIP service provider to authenticate the 369 client (enterprise edge element). How the SIP service provider 370 authenticates the client is out of the scope of this document, 371 however, methods such as HTTP Digest Authentication may be used. 373 6.4. Encoding the Request 375 The edge element in the enterprise network generates a HTTPS GET 376 request such that the request-target is obtained using the procedure 377 outlined in section 6.6 The MIME types for the capability set 378 document defined in this draft are "application/peering-info+json" 379 and "application/peering-info+xml". Accordingly, the Accept header 380 field value MUST be restricted only to these MIME types. It is 381 possible that the edge element supports responses formatted in both 382 JSON and XML. In such situations, the edge element might generate a 383 HTTPS GET request such that the Accept header field includes both 384 MIME types along with the corresponding "qvalue" for each MIME type. 386 The generated HTTPS GET request must not use the "Expect" and "Range" 387 header fields. The requests must also not use any conditional 388 request. 390 6.5. Generating the response 392 Capability servers include the capability set documents in the body 393 of a successful response. Capability set documents MUST be formatted 394 in XML or JSON. For requests that are incorrectly formatted, the 395 capability server must generate a "400 Bad Request" response. If the 396 client (enterprise edge element) includes any other MIME types in 397 Accept header field other than "application/peering-info+json" or 398 "application/peering-info+xml", the capability set must reject the 399 request with a "406 Not Acceptable" response. 401 The capability server can respond to client requests with redirect 402 responses, specifically, the server can respond with the following 403 redirect responses: 405 1. 301 Moved Temporarily 407 2. 302 Found 409 3. 307 Temporary Redirect 411 The server SHOULD include the Location header field in such 412 responses. 414 6.6. Identifying the Request Target 416 HTTPS GET requests from enterprise edge elements MUST carry a valid 417 request-target. The enterprise edge element might obtain the URL of 418 the resource hosted on the capability server in one of two ways: 420 1. Manual Configuration 422 2. Discovery [TBD] 424 7. State Deltas 426 Given that the service provider capability set is largely expected to 427 remain static, the work needed to implement an asynchronous push 428 mechanism to encode minor changes in the capability set document 429 (state deltas) is not commensurate with the benefits. Rather, 430 enterprise edge elements can poll capability servers at pre-defined 431 intervals to obtain the full capability set document. It is 432 recommended that capability servers are polled every 24 hours. 434 8. Encoding the Service Provider Capability Set 436 In the context of this draft, the capability set of a service 437 provider refers collectively to a set of characteristics which when 438 communicated to an enterprise network, provides it with sufficient 439 information to directly peer with the service provider network. The 440 capability set document is not designed to encode extremely granular 441 details of all features, services, and protocol extensions that are 442 supported by the service provider network. For example, it is 443 sufficient to encode that the service provider uses T.38 relay for 444 faxing, it is not required to know the value of the 445 "T38FaxFillBitRemoval" parameter. 447 The parameters within the capability set document represent a wide 448 array of characteristics, such that these characteristics 449 collectively disseminate sufficient information to enable direct IP 450 peering between enterprise and service provider networks. The 451 various parameters represented in the capability set are chosen based 452 on existing practises and common problem sets typically seen between 453 enterprise and service provider SIP networks. 455 9. Data Model for Capability Set 457 This section defines a YANG module for encoding the service provider 458 capability set. Section 9.1 provides the tree diagram, which is 459 followed by a description of the various nodes within the module 460 defined in this draft. 462 9.1. Tree Diagram 464 This section provides a tree diagram [RFC 8340 [13]] for the "ietf- 465 capability-set" module. The interpretation of the symbols appearing 466 in the tree diagram is as follows: 468 o Brackets "[" and "]" enclose list keys. 470 o Abbreviations before data node names: "rw" means configuration 471 (read-write), and "ro" means state data (read-only). 473 o Symbols after data node names: "?" means an optional node, "!" 474 means a presence container, and "*" denotes a list and leaf-list. 476 o Parentheses enclose choice and case nodes, and case nodes are also 477 marked with a colon (":"). 479 o Ellipsis ("...") stands for contents of subtrees that are not 480 shown. 482 The data model for the peering capability document has the following 483 structure: 485 +--rw peering-response 486 +--rw variant string 487 +--rw transport-info 488 | +--rw transport? enumeration 489 | +--rw registrar* host-port 490 | +--rw registrarRealm? string 491 | +--rw callControl* host-port 492 | +--rw dns* inet:ip-address 493 | +--rw outboundProxy? host-port 494 +--rw call-specs 495 | +--rw earlyMedia? boolean 496 | +--rw signalingForking? boolean 497 | +--rw supportedMethods? string 498 | +--rw numRange 499 | +--rw numRangeType* string 500 | +--rw count* int32 501 | +--rw value* string 502 +--rw media 503 | +--rw mediaTypeAudio 504 | | +--rw mediaFormat* string 505 | +--rw fax 506 | | +--rw protocol* enumeration 507 | +--rw rtp 508 | | +--rw RTPTrigger? boolean 509 | | +--rw symmetricRTP? boolean 510 | +--rw rtcp 511 | +--rw symmetricRTCP? boolean 512 | +--rw RTCPfeedback? boolean 513 +--rw dtmf 514 | +--rw payloadNumber? int8 515 | +--rw iteration? boolean 516 +--rw security 517 | +--rw signaling 518 | +--rw type* string 519 | +--rw version* string 520 | +--rw mediaSecurity 521 | +--rw keyManagement? string 522 | +--rw certLocation string 523 +--rw extensions? string 525 9.2. YANG Model 527 This section defines the YANG module for the peering capability set 528 document. It imports modules (ietf-yang-types and ietf-inet-types) 529 from [RFC 6991 [14]]. 531 module ietf-sip-auto-peering { 532 namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering"; 533 prefix "peering"; 535 description 536 "Data model for transmitting peering parameters from SP to Enterprise"; 538 revision 2019-05-06 { 539 description "Initial revision of peering-response doc."; 540 } 542 import ietf-inet-types { 543 prefix "inet"; 544 } 546 typedef ipv4-address-port { 547 type string { 548 pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 549 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 550 + ':^()([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])$'; 551 } 552 description "The ipv4-address-port type represents an IPv4 address in 553 dotted-quad notation followed by a port number."; 554 } 556 typedef ipv6-address-port { 557 type string { 558 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 559 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 560 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 561 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 562 + ':^()([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])$'; 563 pattern 564 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 565 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 566 + ':^()([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])$'; 567 } 568 description 569 "The ipv6-address type represents an IPv6 address in full, 570 mixed, shortened, and shortened-mixed notation followed by a port number."; 571 } 572 typedef ip-address-port { 573 type union { 574 type ipv4-address-port; 575 type ipv6-address-port; 576 } 577 description 578 "The ip-address-port type represents an IP address:port number 579 and is IP version neutral."; 580 } 582 typedef domain-name-port { 583 type string { 584 pattern 585 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 586 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 587 + '|\.' 588 + ':^()([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])$'; 589 length "1..258"; 590 } 591 description 592 "The domain-name-port type represents a DNS domain name followed by a port number. 593 The name SHOULD be fully qualified whenever possible."; 594 } 596 typedef host-port { 597 type union { 598 type ip-address-port; 599 type domain-name-port; 600 } 601 description 602 "The host type represents either an IP address or a DNS 603 domain name followed by a port number."; 604 } 606 container peering-info { 607 leaf variant { 608 type string; 609 mandatory true; 610 description "Variant of peering-response document"; 611 } 613 container transport-info { 614 leaf transport { 615 type enumeration { 616 enum "TCP"; 617 enum "TLS"; 618 enum "UDP"; 619 enum "TCP;TLS"; 620 enum "TCP;TLS;UDP"; 621 enum "TCP;UDP"; 622 } 623 description "Transport Protocol(s) used in SIP communication"; 624 } 626 leaf-list registrar { 627 type host-port; 628 max-elements 3; 629 description "List of service provider registrar servers"; 630 } 632 leaf registrarRealm { 633 type string; 634 description "Realm for REGISTER requests carrying credentials"; 635 } 637 leaf-list callControl { 638 type host-port; 639 max-elements 3; 640 description "List of service provider call control servers"; 641 } 643 leaf-list dns { 644 type inet:ip-address; 645 max-elements 2; 646 description "IP address of the DNS Server(s) hosted by the service provider"; 647 } 649 leaf outboundProxy { 650 type host-port; 651 description "SIP Outbound Proxy"; 652 } 653 } 655 container call-specs { 656 leaf earlyMedia { 657 type boolean; 658 description "Flag indicating whether the service provider is expected 659 to deliver early media."; 660 } 662 leaf signalingForking { 663 type boolean; 664 description "Flag indicating whether the service provider is capable 665 of forking incoming calls "; 666 } 667 leaf supportedMethods { 668 type string; 669 description "Leaf/Leaf List indicating the different SIP methods 670 support by the service provider."; 671 } 673 container numRange { 674 leaf numRangeType { 675 type string; 676 description "String indicating whether the DID number range is passed 677 by value or by reference" 678 } 680 leaf count { 681 when "../numRangeType = 'range' or ../numRangeType = 'block'"; 682 type int32; 683 description "Number of DID numbers present in the number range." 684 } 686 leaf-list value { 687 type string; 688 description "Value of the DID number range or URL being passed as 689 reference." 690 } 692 } 693 } 695 container media { 696 container mediaTypeAudio { 697 leaf-list mediaFormat { 698 type string; 699 description "Leaf List indicating the audio media formats supported."; 700 } 701 } 703 container fax { 704 leaf-list protocol { 705 type enumeration { 706 enum "pass-through"; 707 enum "t38"; 708 } 709 max-elements 2; 710 description "Leaf List indicating the different fax protocols 711 supported by the service provider."; 712 } 713 } 714 container rtp { 715 leaf RTPTrigger { 716 type boolean; 717 description "Flag indicating whether the service provider expects to 718 receive the first media packet."; 719 } 721 leaf symmetricRTP { 722 type boolean; 723 description "Flag indicating whether the service provider expects 724 symmetric RTP defined in [@RFC4961]"; 725 } 726 } 728 container rtcp { 729 leaf symmetricRTCP { 730 type boolean; 731 description " Flag indicating whether the service provider expects 732 symmetric RTP defined in [@RFC4961]."; 733 } 735 leaf RTCPfeedback { 736 type boolean; 737 description "Flag Indicating support for RTP profile extension for 738 RTCP-based feedback, as defined in [@RFC4585]"; 739 } 740 } 741 } 743 container dtmf { 744 leaf payloadNumber { 745 type int8 { 746 range "96..127"; 747 } 748 description "Leaf that indicates the payload number(s) supported by 749 the service provider for DTMF relay via Named-Telephony-Events"; 750 } 752 leaf iteration { 753 type boolean; 754 description "Flag identifying whether the service provider supports 755 NTE DTMF relay using the procedures of [@RFC2833] or [@RFC4733] ."; 756 } 757 } 759 container security { 760 container signaling { 761 leaf type { 762 type string { 763 pattern "TLS"; 764 } 765 description "Type of signaling security supported."; 766 } 768 leaf version { 769 type string { 770 pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)"; 771 } 772 description "Indicates TLS version for SIP signaling"; 773 } 774 } 776 container mediaSecurity { 777 leaf keyManagement { 778 type string { 779 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)"; 780 } 781 description "Leaf that identifies the key management methods 782 supported by the service provider for SRTP."; 783 } 784 } 786 leaf certLocation { 787 type string; 788 description "Location of the service provider certificate chain for SIP over TLS."; 789 } 790 } 792 leaf extensions { 793 type string; 794 description "Lists the various SIP extensions supported by SP"; 795 } 796 } 797 } 799 9.3. Node Definitions 801 This sub-sections provides the definition and encoding rules of the 802 various nodes of the YANG module defined in section 9.2 804 *capability-set*: This node serves as a container for all the other 805 nodes in the YANG module; the capability-set node is akin to the root 806 element of an XML schema. 808 *variant*: This node identifies the version number of the capability 809 set document. This draft defines the parameters for variant 1.0; 810 future specifications might define a richer parameter set, in which 811 case the variant must be changed to 2.0, 3.0 and so on. Future 812 extensions to the capability set document MUST also ensure that the 813 corresponding YANG module is defined. 815 *transport-info*: The transport-info node is a container that 816 encapsulates transport characteristics of SIP sessions between 817 enterprise and service provider networks. 819 *transport*: A leaf node that enumerates the different Transport 820 Layer protocols supported by the SIP service provider. Valid 821 transport layer protocols include: UDP, TCP, TLS or a combination of 822 them (with the exception of TLS and UDP). 824 *registrar*: A leaf-list that specifies the transport address of one 825 or more registrar servers in the service provider network. The 826 transport address of the registrar can be provided using a 827 combination of a valid IP address and port number, or a subdomain of 828 the SIP service provider network, or the fully qualified domain name 829 (FQDN) of the SIP service provider network. If the transport address 830 of a registrar is specified using either a subdomain or a fully 831 qualified domain name, the DNS element must be populated with one or 832 more valid DNS server IP addresses. 834 *callControl*: A leaf-list that specifies the transport address of 835 the call server(s) in the service provider network. The enterprise 836 network must use an applicable transport protocol in conjunction with 837 the call control server(s) transport address when transmitting call 838 setup requests. The transport address of a call server(s) within the 839 service provider network can be specified using a combination of a 840 valid IP address and port number, or a subdomain of the SIP service 841 provider network, or a fully qualified domain name of the SIP service 842 provider network. If the transport address of a call control 843 server(s) is specified using either a subdomain or a fully qualified 844 domain name, the DNS element must be populated with one or more valid 845 DNS server IP addresses. The transport address specified in this 846 element can also serve as the target for non-call requests such as 847 SIP OPTIONS. 849 *dns*: A leaf list that encodes the IP address of one or more DNS 850 servers hosted by the SIP service provider. If the enterprise 851 network is unaware of the IP address, port number, and transport 852 protocol of servers within the service provider network (for example, 853 the registrar and call control server), it must use DNS NAPTR and 854 SRV. Alternatively, if the enterprise network has the fully 855 qualified domain name of the SIP service provider network, it must 856 use DNS to resolve the said FQDN to an IP address. The dns element 857 encodes the IP address of one or more DNS servers hosted in the 858 service provider network. If however, either the registrar or 859 callControl elements or both are populated with a valid IP address 860 and port pair, the dns element must be set to the quadruple octet of 861 0.0.0.0 863 *outboundProxy*: A leaf list that specifies the transport address of 864 one or more outbound proxies. The transport address can be specified 865 by using a combination of an IP address and a port number, a 866 subdomain of the SIP service provider network, or a fully qualified 867 domain name and port number of the SIP service provider network. If 868 the outbound-proxy sub-element is populated with a valid transport 869 address, it represents the default destination for all outbound SIP 870 requests and therefore, the registrar and callControl elements must 871 be populated with the quadruple octet of 0.0.0.0 873 *call-specs*: A container that encapsulates information about call 874 specifications, restrictions and additional handling criteria for SIP 875 calls between the enterprise and service provider network. 877 *earlyMedia*: A leaf that specifies whether the service provider 878 network is expected to deliver in-band announcements/tones before 879 call connect. The P-Early-Media header field can be used to indicate 880 pre-connect delivery of tones and announcements on a per-call basis. 881 However, given that signalling and media could traverse a large 882 number of intermediaries with varying capabilities (in terms of 883 handling of the P-Early-Media header field) within the enterprise, 884 such devices can be appropriately configured for media cut through if 885 it is known before-hand that early media is expected for some or all 886 of the outbound calls. This element is a Boolean type, where a value 887 of 1/true signifies that the service provider is capable of early 888 media. A value of 0/false signifies that the service provider is not 889 expected to generate early media. 891 *signalingForking*: A leaf that specifies whether outbound call 892 requests from the enterprise might be forked on the service provider 893 network that MAY lead to multiple early dialogs. This information 894 would be useful to the enterprise network in appropriately handling 895 multiple early dialogs reliably and in enforcing local policy. This 896 element is a Boolen type, where a value of 1/true signifies that the 897 service provider network can potentially fork outbound call requests 898 from the enterprise. A value of 0/false indicates that the service 899 provider will not fork outbound call requests. 901 *supportedMethods*: A leaf node that specifies the various SIP 902 methods supported by the SIP service provider. The list of supported 903 methods help to appropriately configuration various devices within 904 the enterprise network. For example, if the service provider 905 enumerates support for the OPTIONS method, the enterprise network 906 could periodically send OPTIONS requests as a keep-alive mechanism. 908 *numRange*: Is a container that specifies the Direct Inward Dial 909 (DID) number range allocated to the enterprise network by the SIP 910 service provider. The DID number range allocated by the service 911 provider to the enterprise network might be a contiguous or a non- 912 contiguous block. The number range allocated to an enterprise can be 913 communicated as a value or as a reference. For large enterprise 914 networks, the size of the DID range might run into several hundred 915 numbers. For situations in which the enterprise is allocated a large 916 DID number range or a non-contiguous number range it is RECOMMENDED 917 that the SIP service provider communicate this information by 918 reference, that is, through a URL. The enterprise network is 919 required to de-reference this URL in order to obtain the DID number 920 range allocated by the SIP service provider. The numRange container 921 can be used more than once. Refer to the example provided in 922 Section 10.1. 924 *numRangeType*: A leaf node that indicates whether the DID range is 925 communicated by value or by reference. It can have a value of 926 'range', 'block' or 'reference'. 928 *count*: A leaf node that indicates the size of the DID number range. 929 The number range may be contiguous or non-contiguous. This leaf node 930 MUST NOT be included when using the 'reference' numRangeType value. 932 *value*: A leaf-list that encapsulates the DID number range allocated 933 to the enterprise. If the numRangeType value is set to 'range' or 934 'block', this is the list of numbers allocated to the enterprise. If 935 the numRangeType value is set to 'reference', this is the URL of the 936 resource containing the DID number range. To ensure ease of parsing, 937 it is RECOMMENDED that the resource contain a number range formatted 938 as if it were being passed as a block or range. 940 *media*: A container that is used to collectively encapsulate the 941 characteristics of UDP-based audio streams. A future extension to 942 this draft may extend the media container to describe other media 943 types. The media container is also used to encapsulate basic 944 information about Real-Time Transport Protocol (RTP) and Real-Time 945 Transport Control Protocol (RTCP) from the perspective of the service 946 provider network. 948 *mediaTypeAudio*: A container for the mediaFormat leaf-list. This 949 container collectively encapsulates the various audio media formats 950 supported by the SIP service provider. 952 *mediaFormat*: A leaf-list encoding the various audio media formats 953 supported by the SIP service provider. The relative ordering of 954 different media format leaf nodes from left to right indicates 955 preference from the perspective of the service provider. Each 956 mediaFormat node begins with the encoding name of the media format, 957 which is the same encoding name as used in the "RTP/AVP" and "RTP/ 958 SAVP" profiles. The encoding name is followed by required and 959 optional parameters for the given media format as specified when the 960 media format is registered [RFC 4855 [15]]. Given that the 961 parameters of media formats can vary from one communication session 962 to another, for example, across two separate communication sessions, 963 the packetization time (ptime) used for the PCMU media format might 964 vary from 10 to 30 ms, the parameters included in the format element 965 must be the ones that are expected to be invariant from the 966 perspective of the service provider. Providing information about 967 supported media formats and their respective parameters, allows 968 enterprise networks to configure the media plane characteristics of 969 various devices such as endpoints and middleboxes. The encoding 970 name, one or more required parameters, one or more optional 971 parameters are all separated by a semicolon. The formatting of a 972 given media format parameter, must follow the formatting rules as 973 specified for that media format. 975 *fax*: A container that encapsulates the fax protocol(s) supported by 976 the SIP service provider. The fax container encloses a leaf-list 977 (named protocol) that enumerates whether the service provider 978 supports t38 relay, protocol-based fax passthrough or both. The 979 relative ordering of leaf nodes within the leaf lists indicates 980 preference. 982 *rtp*: A container that encapsulates generic characteristics of RTP 983 sessions between the enterprise and service provider network. This 984 node is a container for the "RTPTrigger" and "SymmetricRTP" leaf 985 nodes. 987 *RTPTrigger*: A leaf node indicating whether the SIP service provider 988 network always expects the enterprise network to send the first RTP 989 packet for an established communication session. This information is 990 useful in scenarios such as "hairpinned" calls, in which the caller 991 and callee are on the service provider network and because of sub- 992 optimal media routing, an enterprise device such as an SBC is 993 retained in the media path. Based on the encoding of this node, it 994 is possible to configure enterprise devices such as SBCs to start 995 streaming media (possibly filled with silence payloads) toward the 996 address:port tuples provided by caller and callee. This node is a 997 Boolean type. A value of 1/true indicates that the service provider 998 expects the enterprise network to send the first RTP packet, whereas 999 a value of 0/false indicates that the service provider network does 1000 not require the enterprise network to send the first media packet. 1001 While the practise of preserving the enterprise network in a 1002 hairpinned call flow is fairly common, it is recommended that SIP 1003 service providers avoid this practise. In the context of a 1004 hairpinned call, the enterprise device retained in the call flow can 1005 easily eavesdrop on the conversation between the offnet parties. 1007 *symmetricRTP*: A leaf node indicating whether the SIP service 1008 provider expects the enterprise network to use symmetric RTP as 1009 defined in RFC 4961 [16]. Uncovering this expectation is useful in 1010 scenarios where "latching" [RFC 7362 [17]] is implemented in the 1011 service provider network. This node is a Boolean type, a value of 1/ 1012 true indicates that the service provider expects the enterprise 1013 network to use symmetric RTP, whereas a value of 0/false indicates 1014 that the enterprise network can use asymmetric RTP. 1016 *rtcp*: A container that encapsulates generic characteristics of RTCP 1017 sessions between the enterprise and service provider network. This 1018 node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf 1019 nodes. 1021 *RTCPFeedback*: A leaf node that indicates whether the SIP service 1022 provider supports the RTP profile extension for RTCP-based feedback 1023 RFC 4585 [18]. Media sessions spanning enterprise and service 1024 provider networks, are rarely made to flow directly between the 1025 caller and callee, rather, it is often the case that media traffic 1026 flows through network intermediaries such as SBCs. As a result, RTCP 1027 traffic from the service provider network is intercepted by these 1028 intermediaries, which in turn can either pass across RTCP traffic 1029 unmodified or modify RTCP traffic before it is forwarded to the 1030 endpoint in the enterprise network. Modification of RTCP traffic 1031 would be required, for example, if the intermediary has performed 1032 media payload transformation operations such as transcoding or 1033 transrating. In a similar vein, for the RTCP-based feedback 1034 mechanism as defined in RFC 4585 [19] to be truly effective, 1035 intermediaries must ensure that feedback messages are passed reliably 1036 and with the correct formatting to enterprise endpoints. This might 1037 require additional configuration and considerations that need to be 1038 dealt with at the time of provisioning the intermediary device. This 1039 node is a Boolean type, a value of 1/true indicates that the service 1040 provider supports the RTP profile extension for RTP-based feedback 1041 and a value of 0/false indicates that the service provider does not 1042 support the RTP profile extension for RTP-based feedback. 1044 *symmetricRTCP*: A leaf node indicating whether the SIP service 1045 provider expects the enterprise network to use symmetric RTCP as 1046 defined in RFC 4961 [20]. This node is a Boolean type, a value of 1 1047 indicates that the service provider expects symmetric RTCP reports, 1048 whereas a value of 0 indicates that the enterprise can use asymmetric 1049 RTCP. 1051 *dtmf*: A container that describes the various aspects of DTMF relay 1052 via RTP Named Telephony Events. The dtmf container allows SIP 1053 service providers to specify two facets of DTMF relay via Named 1054 Telephony Events: 1056 1. The payload type number using the payloadNumber leaf node. 1058 2. Support for RFC 2833 [21] or RFC 4733 [22] using the iteration 1059 leaf node. 1061 In the context of named telephony events, senders and receivers may 1062 negotiate asymmetric payload type numbers. For example, the sender 1063 might advertise payload type number 97 and the receiver might 1064 advertise payload type number 101. In such instances, it is either 1065 required for middleboxes to interwork payload type numbers or allow 1066 the endpoints to send and receive asymmetric payload numbers. The 1067 behaviour of middleboxes in this context is largely dependent on 1068 endpoint capabilities or on service provider constraints. Therefore, 1069 the payloadNumber leaf node can be used to determine middlebox 1070 configuration before-hand. 1072 RFC 4733 [23] iterates over RFC 2833 [24] by introducing certain 1073 changes in the way NTE events are transmitted. SIP service providers 1074 can indicate support for RFC 4733 [25] by setting the iteration flag 1075 to 1 or indicating support for RFC 2833 [26] by setting the iteration 1076 flag to 0. 1078 *security*: A container that encapsulates characteristics about 1079 encrypting signalling streams between the enterprise and SIP service 1080 provider networks. 1082 *signaling*: A container that encapsulates the type of security 1083 protocol for the SIP communication between the enterprise SBC and the 1084 service provider. 1086 *type*: A leaf node that specifies the protocol used for protecting 1087 SIP signalling messages between the enterprise and service provider 1088 network. The value of the type leaf node is only defined for 1089 Transport Layer Security (TLS). Accordingly, if TLS is allowed for 1090 SIP sessions between the enterprise and service provider network, the 1091 type leaf node is set to the string "tls". 1093 *version*: A leaf node that specifies the version(s) of TLS supported 1094 in decimal format. If multiple versions of TLS are supported, they 1095 should be separated by semi-colons. If the service provide does not 1096 support TLS for protecting SIP sessions, the signalling element is 1097 set to the string "NULL". 1099 *mediaSecurity*: A container that describes the various 1100 characteristics of securing media streams between enterprise and 1101 service provider networks. 1103 *keyManagement*: A leaf node that specifies the key management method 1104 used by the service provider. Possible values of this node include: 1105 "SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP 1106 service provider uses the methods defined in RFC 4568 [27] for the 1107 purpose of key management. A value of "DTLS-SRTP" signifies that the 1108 SIP service provider uses the methods defined in RFC 5764 [28] for 1109 the purpose of key management. If the value of this leaf node is set 1110 to "DTLS-SRTP", the various versions of DTLS supported by the SIP 1111 service provider MUST be encoded as per the formatting rules of 1112 Section 9.2. If the service provider does not support media 1113 security, the keyManagement node MUST be set to "NULL". 1115 *certLocation:*: If the enterprise network is required to exchange 1116 SIP traffic over TLS with the SIP service provider, and if the SIP 1117 service provider is capable of accepting TLS connections from the 1118 enterprise network, it may be required for the SIP service provider 1119 certificates to be pre-installed on the enterprise edge element. In 1120 such situations, the certLocation leaf node is populated with a URL, 1121 which when dereferenced, provides a single PEM encoded file that 1122 contains all certificates in the chain of trust. This is an optional 1123 leaf node. 1125 *extensions*: A leaf node that is a semicolon separated list of all 1126 possible SIP option tags supported by the service provider network. 1127 These extensions must be referenced using name registered under IANA. 1128 If the service provider network does not support any extensions to 1129 baseline SIP, the extensions node must be set to "NULL". 1131 9.4. Extending the Capability Set 1133 There are situations in which equipment manufactures or service 1134 providers would benefit from extending the YANG module defined in 1135 this draft. For example, service providers could extend the YANG 1136 module to include information that further simplifies direct IP 1137 peering. Such information could include: trunk group identifiers, 1138 direct-inward-dial (DID) number ranges allocated to the enterprise, 1139 customer/enterprise account numbers, service provider support 1140 numbers, among others. Extension of the module can be achieved by 1141 importing the module defined in this draft. An example is provided 1142 below: Consider a new YANG module "vendorA" specified for VendorA's 1143 enterprise SBC. The "vendorA-config" YANG module is configured as 1144 follows: 1146 module vendorA-config { 1147 namespace "urn:ietf:params:xml:ns:yang:vendorA-config"; 1148 prefix "vendorA"; 1150 description 1151 "Data model for configuring VendorA Enterprise SBC"; 1153 revision 2020-05-06 { 1154 description "Initial revision of VendorA Enterprise SBC configuration data model"; 1155 } 1157 import ietf-peering { 1158 prefix "peering"; 1159 } 1161 augment "/peering:peering-info" { 1162 container vendorAConfig { 1163 leaf vendorAConfigParam1 { 1164 type int32; 1165 description "vendorA configuration parameter 1 (SBC Device ID)"; 1166 } 1168 leaf vendorAConfigParam2 { 1169 type string; 1170 description "vendorA configuration parameter 2 (SBC Device name)"; 1171 } 1172 description "Container for vendorA SBC configuration"; 1173 } 1174 } 1175 } 1177 In the example above, a custom module named "vendorA-config" uses the 1178 "augment" statement as defined in Section 4.2.8 of [RFC 7950 [29]] to 1179 extend the module defined in this draft. 1181 10. Example Capability Set Document Encoding 1183 This section provides examples of how capability set documents that 1184 leverage the YANG module defined in this document can be encoded over 1185 JSON or XML. 1187 10.1. XML Capability Set Document 1189 1192 1.0 1193 1194 TCP;TLS;UDP 1195 registrar1.voip.example.com:5060 1196 registrar2.voip.example.com:5060 1197 voip.example.com 1198 callServer1.voip.example.com:5060 1199 192.168.12.25:5065 1200 8.8.8.8 1201 208.67.222.222 1202 0.0.0.0 1203 1204 1205 true 1206 false 1207 INVITE;OPTIONS;BYE;CANCEL;ACK;PRACK;SUBSCRIBE;NOTIFY;REGISTER 1208 1209 range 1210 20 1211 19725455000 1212 1213 1214 block 1215 2 1216 1972546000 1217 1972546001 1218 1219 1220 1221 1222 PCMU;rate=8000;ptime=20 1223 G729;rate=8000;annexb=yes 1224 G722;rate=8000;bitrate=56k,64k 1225 1226 1227 pass-through 1228 t38 1229 1230 1231 true 1232 true 1233 1234 1235 true 1236 true 1237 1238 1239 1240 101 1241 0 1242 1243 1244 1245 TLS 1246 1.0;1.2 1247 1248 1249 SDES;DTLS-SRTP,version=1.2 1250 1251 https://sipserviceprovider.com/certificateList.pem 1252 1253 timer;rel100;gin;path 1254 1256 11. Example Exchange 1258 This section depicts an example of the configuration flow that 1259 ultimately results in the enterprise edge element obtaining the 1260 capability set document from the SIP service provider. Assuming the 1261 enterprise edge element has been pre-configured with the request 1262 target for the capability set document or has dynamically found the 1263 request target, the edge element generates a HTTPS GET request. This 1264 request can be challenged by the service provider to authenticate the 1265 enterprise. 1267 GET //capdoc?trunkid=trunkent1456 HTTP/1.1 1268 Host: capserver.ssp1.com 1269 Accept:application/peering-info+xml 1271 The capability set document is obtained in the body of the response 1272 and is encoded in XML. 1274 HTTP/1.1 200 OK 1275 Content-Type: application/peering-info+xml 1276 Content-Length: nnn 1278 1279 ... 1280 1282 12. Security Considerations 1284 [TBD] 1286 13. References 1288 13.1. Normative References 1290 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1291 Levels", BCP 14, RFC 2119 [30], March 1997. 1293 [4] Bjorklund, M., "YANG - A Data Modeling Language for the Network 1294 Configuration Protocol (NETCONF)", RFC 6020 [31], October 2010. 1296 [8] Schoenwaelder, J., "Common YANG Data Types", RFC 6991 [32], July 1297 2013. 1299 13.2. Informative References 1301 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1302 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1303 Session Initiation Protocol", RFC 3261 [33], June 2002. 1305 [3] Roach, A. B., "SIP-Specific Event Notification", RFC 6665 [34], 1306 July 2012. 1308 [5] Fielding, R., Reschke, J., "Hypertext Transfer Protocol 1309 (HTTP/1.1): Semantics and Content", RFC 7231 [35], June 2014. 1311 [6] Enns, R., Bjorklund, M., Schoenwaelder, J., Bierman, A., "Network 1312 Configuration Protocol (NETCONF)", RFC 6241 [36], June 2011. 1314 [7] Bjorklund, M., Berger, L., "YANG Tree Diagrams", RFC 8340 [37], 1315 March 2018. 1317 [9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", RFC 4961 1318 [38], July 2007. 1320 [10] Ott, J., Wenger, S., Sato, N., Burmeister, C., Matsushita, 1321 "Extended RTP Profile for Real-time Transport Control Protocol 1322 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585 [39], July 2006. 1324 [11] Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits, 1325 Telephony Tones and Telephony Signals", RFC 2833 [40], May 2000. 1327 [12] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits, 1328 Telephony Tones, and Telephony Signals", RFC 4733 [41], December, 1329 2006. 1331 [13] Casner, S., "Media Type Registration of RTP Payload Formats", 1332 RFC 4855 [42], February 2007. 1334 [14] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) 1335 Protocol Version 1.2", RFC 5246 [43], August 2008. 1337 [15] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1338 Version 1.3", RFC 8446 [44], August 2018. 1340 [17] Ivov, E., Kaplan, H., Wing, D., "Latching: Hosted NAT Traversal 1341 (HNT) for Media in Real-Time Communication", RFC 7362 [45], September 1342 2014. 1344 [18] Jones, P., Salgueiro, G., Jones, M., Smarr, J., "WebFinger", 1345 [RFC 7033 [46]], September 2013. 1347 [19] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC 1348 6749 [47]], October 2012. 1350 [20] "SIP-PBX / Service Provider Interoperability SIPconnect 2.0 - 1351 Technical Recommendation", SIP Forum, SIP CONNECT 2.0 [48], December 1352 7, 2016 1354 14. Acknowledgments 1356 [TBD] 1358 15. References 1360 15.1. URIs 1362 [1] https://tools.ietf.org/html/rfc3261 1364 [2] https://www.sipforum.org/download/sipconnect-technical- 1365 recommendation-version-2-0/?wpdmdl=2818 1367 [3] https://tools.ietf.org/html/rfc2119 1369 [4] https://tools.ietf.org/html/rfc7092 1371 [5] https://tools.ietf.org/html/rfc7231 1373 [6] https://tools.ietf.org/html/rfc7092 1375 [7] https://tools.ietf.org/html/rfc6665 1377 [8] https://tools.ietf.org/html/rfc6020 1379 [9] https://tools.ietf.org/html/rfc6241 1381 [10] https://tools.ietf.org/html/rfc5246 1383 [11] https://tools.ietf.org/html/rfc7235 1385 [12] https://tools.ietf.org/html/rfc7230 1387 [13] https://tools.ietf.org/html/rfc8340 1389 [14] https://tools.ietf.org/html/rfc6991 1391 [15] https://tools.ietf.org/html/rfc4855 1393 [16] https://tools.ietf.org/html/rfc4961 1395 [17] https://tools.ietf.org/html/rfc7362 1397 [18] https://tools.ietf.org/html/rfc4585 1399 [19] https://tools.ietf.org/html/rfc4585 1401 [20] https://tools.ietf.org/html/rfc4961 1403 [21] https://tools.ietf.org/html/rfc2833 1405 [22] https://tools.ietf.org/html/rfc4733 1407 [23] https://tools.ietf.org/html/rfc4733 1409 [24] https://tools.ietf.org/html/rfc2833 1411 [25] https://tools.ietf.org/html/rfc4733 1413 [26] https://tools.ietf.org/html/rfc2833 1415 [27] https://tools.ietf.org/html/rfc4568 1417 [28] https://tools.ietf.org/html/rfc5764 1419 [29] https://tools.ietf.org/html/rfc7950 1421 [30] https://tools.ietf.org/html/rfc2119 1423 [31] https://tools.ietf.org/html/rfc6020 1425 [32] https://tools.ietf.org/html/rfc6991 1427 [33] https://tools.ietf.org/html/rfc3261 1429 [34] https://tools.ietf.org/html/rfc6665 1431 [35] https://tools.ietf.org/html/rfc7231 1433 [36] https://tools.ietf.org/html/rfc6241 1435 [37] https://tools.ietf.org/html/rfc8040 1437 [38] https://tools.ietf.org/html/rfc4961 1439 [39] https://tools.ietf.org/html/rfc4585 1441 [40] https://tools.ietf.org/html/rfc2833 1443 [41] https://tools.ietf.org/html/rfc4733 1445 [42] https://tools.ietf.org/html/rfc4855 1447 [43] https://tools.ietf.org/html/rfc5246 1449 [44] https://tools.ietf.org/html/rfc8446 1451 [45] https://tools.ietf.org/html/rfc7362 1453 [46] https://tools.ietf.org/html/rfc7033 1455 [47] https://tools.ietf.org/html/rfc6749 1457 [48] https://www.sipforum.org/download/sipconnect-technical- 1458 recommendation-version-2-0-2/ 1460 Authors' Addresses 1462 Kaustubh Inamdar 1463 Cisco Systems 1465 Email: kinamdar@cisco.com 1467 Sreekanth Narayanan 1468 Cisco Systems 1470 Email: sreenara@cisco.com 1471 Cullen Jennings 1472 Cisco Systems 1474 Email: fluffy@iii.ca