idnits 2.17.1 draft-kinamdar-dispatch-sip-auto-peer-01.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 issues found here. 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 34 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. 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 (November 3, 2019) is 1607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 1192, but not defined == Missing Reference: '0-9' is mentioned on line 730, but not defined == Missing Reference: '1-9' is mentioned on line 730, but not defined == Missing Reference: '0-4' is mentioned on line 529, but not defined == Missing Reference: '0-5' is mentioned on line 529, but not defined == Missing Reference: '1-5' is mentioned on line 557, but not defined == Missing Reference: '1-4' is mentioned on line 557, but not defined == Missing Reference: '1-2' is mentioned on line 557, but not defined -- Looks like a reference, but probably isn't: '01' on line 529 -- Obsolete informational reference (is this intentional?): RFC 2833 (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Inamdar 3 Internet-Draft S. Narayanan 4 Intended status: Standards Track C. Jennings 5 Expires: May 6, 2020 Cisco Systems 6 November 3, 2019 8 Automatic Peering for SIP Trunks 9 draft-kinamdar-dispatch-sip-auto-peer-01 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 May 6, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 7 62 6.2. Integrity and Confidentiality . . . . . . . . . . . . . . 7 63 6.3. Authenticated Client Identity . . . . . . . . . . . . . . 8 64 6.4. Encoding the Request . . . . . . . . . . . . . . . . . . 8 65 6.5. Generating the Response . . . . . . . . . . . . . . . . . 8 66 6.6. Identifying the Request Target . . . . . . . . . . . . . 9 67 7. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8. Encoding the Service Provider Capability Set . . . . . . . . 9 69 9. Data Model for Capability Set . . . . . . . . . . . . . . . . 10 70 9.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 71 9.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 17 73 9.4. Extending the Capability Set . . . . . . . . . . . . . . 23 74 10. Example Capability Set Document Encoding . . . . . . . . . . 24 75 10.1. XML Capability Set Document . . . . . . . . . . . . . . 24 76 11. Example Exchange . . . . . . . . . . . . . . . . . . . . . . 26 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 81 14.2. Informative References . . . . . . . . . . . . . . . . . 27 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 84 1. Introduction 86 The deployment of a Session Initiation Protocol (SIP)-based 87 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. 93 Currently published standards provide a strong foundation over which 94 direct IP peering can be realized. However, given the sheer number 95 of these standards, it is often not clear which behavioral subsets, 96 extensions to baseline protocols and operating principles ought to be 97 implemented by service provider and enterprise networks to ensure 98 successful peering. 100 The SIP Connect technical recommendations aim to solve this problem 101 by providing a master reference that promotes seamless peering 102 between enterprise and service provider SIP networks. However, 103 despite the extensive set of implementation rules and operating 104 guidelines, interoperability issues between service provider and 105 enterprise networks persist. This is in large part because service 106 providers and equipment manufacturers aren't required to enforce the 107 guidelines of the technical specifications and have a fair degree of 108 freedom to deviate from them. Consequently, enterprise 109 administrators usually undertake a fairly rigorous regimen of 110 testing, analysis and troubleshooting to arrive at a configuration 111 block that ensures seamless service provider peering. However, this 112 workflow complements the SIP Connect technical recommendations, in 113 that both endeavours aim to promote/achieve interoperability between the 114 enterprise and service provider. 116 Another set of interoperability problems arise when enterprise 117 administrators are required to translate a set of technical 118 recommendations from service providers to configuration blocks across 119 one or more devices in the enterprise, which is usually an error 120 prone exercise. Additionally, such technical recommendations might 121 not be nuanced enough to intuitively allow the generation of specific 122 configuration blocks. 124 This draft introduces a mechanism using which an enterprise network 125 can solicit a detailed capability set from a SIP service provider; 126 the detailed capability set can subsequently be used by automaton or 127 an administrator to generate configuration blocks across one or more 128 devices within the enterprise to ensure successful service provider 129 peering. 131 2. Conventions and Terminology 133 The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 134 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 135 this document are to be interpreted as described in [RFC2119] 137 3. Reference Architecture 139 Figure 1 illustrates a reference architecture that may be deployed to 140 support the mechanism described in this document. The enterprise 141 network consists of a SIP-PBX, media endpoints and a Session Border 142 Controller. It may also include additional components such as 143 application servers for voicemail, recording, fax etc. At a high 144 level, the service provider consists of a SIP signaling entity (SP- 145 SSE), a media entity and a HTTP(S) server. 147 +-----------------------------------------------------+ 148 | +---------------+ +-----------------------+ | 149 | | | | | | 150 | | +----------+ | | +-------+ | | 151 | | | Cap | | HTTPS | | | | | 152 | | | Server |<-|---------|-->| | | | 153 | | | | | | | | +-----+ | | 154 | | +----------+ | | | | | SIP | | | 155 | | | | | |<->| PBX | | | 156 | | | | | | +-----+ | | 157 | | +----------+ | | | SBC | | | 158 | | | | | SIP | | | | | 159 | | | SP - SSE |<-|---------|-->| | +-----+ | | 160 | | | | | | | |<->| M.E.| | | 161 | | +----------+ | | | | | | | | 162 | | | | | | +-----+ | | 163 | | +----------+ | SRTP | | | | | 164 | | | Media |<-|---------|-->+-------+ | | 165 | | +----------+ | | | | 166 | +---------------+ +-----------------------+ | 167 | | 168 +-----------------------------------------------------+ 170 Figure 1: Reference Architecture 172 This draft makes use of the following terminology: 174 o Enterprise Network: A communications network infrastructure 175 deployed by an enterprise which interconnects with the service 176 provider network over SIP. The enterprise network could include 177 devices such as application servers, endpoints, call agents and 178 edge devices among others. 180 o Edge Device: A device that is the last hop in the enterprise 181 network and that is the transit point for traffic entering and 182 leaving the enterprise. An edge device is typically a back-to- 183 back user agent (B2BUA) such as a Session Border 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 HTTP(S) 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. These networks typically interconnect with other 193 service provider networks over SIP or ISDN. 195 o Call Control: Call Control within a telephony networks refers to 196 software that is responsible for delivering its core 197 functionality. Call control not only provides the basic 198 functionality of setting up, sustaining and terminating calls, but 199 also provides the necessary control and logic required for 200 additional services within the telephony network. 202 o Capability Server: A server hosted in the service provider 203 network, such that this server is the target for capability set 204 document requests from the enterprise network. 206 o Capability Set: This specification uses the term capability set 207 (or capability set document) to refer collectively to a set of 208 characteristics within the service provider network, which when 209 communicated to the enterprise network allows it to obtain 210 sufficient information required to peer successfully with the 211 service provider network. 213 4. Configuration Workflow 215 A workflow that facilitates an enterprise network to solicit the 216 capability set of a SIP service provider ought to take into account 217 the following considerations: 219 o The configuration workflow must be based on a protocol or a set of 220 protocols commonly used between enterprise and service provider 221 telephony networks. 223 o The configuration workflow must be flexible enough to allow the 224 service provider network to dynamically offload different 225 capability sets to different enterprise networks based on the 226 identity of the enterprise network. 228 o Capability set documents obtained as a result of the configuration 229 workflow must be conducive to easy parsing by automaton. 230 Subsequently, automaton may be used for generation of appropriate 231 configuration blocks. 233 Taking the above considerations into account, this document proposes 234 a Hypertext Transfer Protocol (HTTP)-based workflow using which the 235 enterprise network can solicit and ultimately obtain the service 236 provider capability set. The enterprise network creates a well 237 formed HTTPS GET request to solicit the service provider capability 238 set. Subsequently, the HTTPS response from the SIP service provider 239 includes the capability set. The capability set is encoded in either 240 XML or JSON, thus ensuring that the response can be easily parsed by 241 automaton. 243 There are alternative mechanisms using which the SIP service provider 244 can offload its capability set. For example, the Session Initiation 245 Protocol (SIP) can be extended to define a new event package 246 [RFC6665], such that the enterprise network can establish a SIP 247 subscription with the service provider for its capability set; the 248 SIP service provider can subsequently use the SIP NOTIFY request to 249 communicate its capability set or any state deltas to its baseline 250 capability set. This mechanism is likely to result in a significant 251 amount of operational complexity. For example, not only would this 252 workflow require enterprise and service provider equipment 253 manufacturers to upgrade their software stacks, but it would also 254 create a significant amount of ambiguity in terms of which device in 255 the service provider network handles subscriptions and generates 256 notifications. Yet another example of an alternative mechanism would 257 be for service providers and enterprise equipment manufacturers to 258 agree on YANG models [RFC6020] that enable configuration to be pushed 259 over NETCONF [RFC6241] to enterprise networks from a centralized 260 source hosted in service provider networks. The presence of 261 proprietary software logic for call and media handling in enterprise 262 devices would preclude the generation of a "one-size-fits-all" YANG 263 model. Additionally, service provider networks pushing configuration 264 to enterprises devices might lead to the loss of implementation 265 autonomy on the part of the enterprise network. 267 5. Overview of Operations 269 To solicit the capability set of the SIP service provider, the edge 270 element in the enterprise network generates a well-formed HTTPS GET 271 request. There are two reasons why it makes sense for the enterprise 272 edge element to generate the HTTPs request: 274 1. Edge elements are devices that normalize any mismatches between 275 the enterprise and service provider networks in the media and 276 signaling planes. As a result, when the capability set is 277 received from the SIP service provider network, the edge element 278 can generate appropriate configuration blocks (possibly across 279 multiple devices) to enable smooth IP peering. 281 2. Given that edge elements are configured to "talk" to networks 282 external to the enterprise, the complexity in terms of NAT 283 traversal and firewall configuration would be minimal. 285 The HTTPs GET request is targeted at a capability server that is 286 managed by the SIP service provider such that this server processes, 287 and on successfully processing the request, includes the capability 288 set document in the response. The capability set document is 289 constructed according the guidelines of the YANG model described in 290 this draft. The capability set document included in a successful 291 response is formatted in either XML or JSON. The formatting depends 292 on the value of the "Accept" header field of the HTTP GET request. 293 More details about the formatting of the HTTP request and response 294 are provided in Section 6 296 Figure 1 provides a reference architecture in which this workflow may 297 be implemented. The architecture depicted in Figure 1 consists of an 298 enterprise telephony network and a SIP service provider network, such 299 that the enterprise network attempts to provision SIP trunking 300 services for the first time. For the sake of simplicity, the 301 enterprise and service provider networks are decomposed into their 302 core constituent elements. 304 6. HTTP Transport 306 This section describes the use of HTTP as a transport protocol for 307 the peering workflow. This workflow is based on HTTP version 1.1 309 6.1. HTTP Methods 311 The workflow defined in this document leverages the HTTP GET method 312 and its corresponding response(s) to request for and subsequently 313 obtain the service provider capability set document. The HTTP POST 314 method and its corresponding response(s) is also used for client 315 authentication. 317 To ensure the smooth operation of this workflow, this draft enforces 318 certain controls (not to be confused with HTTP controls as defined in 319 [RFC7231] on the HTTP client and server. These controls as they 320 relate to formatting, operational guidelines, security concerns and 321 more, are detailed in subsequent sections of this draft. 323 6.2. Integrity and Confidentiality 325 Peering requests and responses are defined over HTTP. However, due 326 to the sensitive nature of information transmitted between client and 327 server, it is required to secure HTTP using Transport Layer Security. 328 The enterprise edge element and capability server MUST be compliant 329 to [RFC7235]. The enterprise edge element and capability server MUST 330 support the use of the https uri scheme as defined in [RFC7230]. 332 6.3. Authenticated Client Identity 334 The configuration workflow and corresponding YANG model described in 335 this draft allow for smooth IP peering between enterprise and SIP 336 service provider networks by encoding the essential session and media 337 characteristics. It is NOT RECOMMENDED to encode information that is 338 sensitive in nature. It is only required for the client (enterprise 339 edge element) to authenticate the SIP service provider. 341 6.4. Encoding the Request 343 The edge element in the enterprise network generates a HTTPS GET 344 request with the request-target obtained either manually or 345 automatically. The MIME types for the capability set document 346 defined in this draft is "application/peering-info+xml". 347 Accordingly, the Accept header field value MUST be restricted only 348 to these MIME types. It is possible that the edge element supports 349 responses formatted in both JSON and XML. In such situations, the 350 edge element might generate a HTTPS GET request such that the Accept 351 header field includes both MIME types long with the corresponding 352 "qvalue" for each MIME type. 354 The generated HTTPS GET request MUST NOT use the "Expect" and "Range" 355 header fields. The requests also MUST NOT use any conditional 356 request. 358 6.5. Generating the Response 360 Capability servers include the capability set documents in the body 361 of a successful response. Capability set documents MUST be formatted 362 in XML or JSON. For requests that are incorrectly formatted, the 363 capability server SHOULD generate a "400 Bad Request" response. If 364 the client (enterprise edge element) includes any other MIME types in 365 Accept header field other than "application/peering-info+json" or 366 "application/peering-info+xml", the capability set MUST reject the 367 request with a "406 Not Acceptable" response. 369 The capability server can respond to client requests with redirect 370 responses, specifically, the server can respond with the following 371 redirect responses: 373 1. 301 Moved Temporarily 375 2. 302 Found 377 3. 307 Temporary Redirect 378 The server SHOULD include the Location header field in such 379 responses. 381 For requests that carry an invalid bearer token in the Authorization 382 header field, the capability server SHOULD respond with a HTTP 401 383 status code. 385 6.6. Identifying the Request Target 387 HTTPS GET requests from enterprise edge elements MUST carry a valid 388 request-target. The enterprise edge element might obtain the URL of 389 the resource hosted on the capability server in one of two ways: 391 1. Manual Configuration 393 2. Discovery and Automatic configuration 395 [TBD] 397 7. State Deltas 399 Given that the service provider capability set is largely expected to 400 remain static, the work needed to implement an asynchronous push 401 mechanism to encode minor changes in the capability set document 402 (state deltas) is not commensurate with the benefits. Rather, 403 enterprise edge elements can poll capability servers at pre-defined 404 intervals to obtain the full capability set document. It is 405 RECOMMENDED that capability servers are polled every 24 hours. 407 8. Encoding the Service Provider Capability Set 409 In the context of this draft, the capability set of a service 410 provider refers collectively to a set of characteristics which when 411 communicated to an enterprise network, provides it with sufficient 412 information to directly peer with the service provider network. The 413 capability set document is not designed to encode extremely granular 414 details of all features, services, and protocol extensions that are 415 supported by the service provider network. For example, it is 416 sufficient to encode that the service provider uses T.38 relay for 417 faxing, it is not required to know the value of the 418 "T38FaxFillBitRemoval" parameter. 420 The parameters within the capability set document represent a wide 421 array of characteristics, such that these characteristics 422 collectively disseminate sufficient information to enable direct IP 423 peering between enterprise and service provider networks. The 424 various parameters represented in the capability set are chosen based 425 on existing practises and common problem sets typically seen between 426 enterprise and service provider SIP networks. 428 9. Data Model for Capability Set 430 This section defines a YANG module for encoding the service provider 431 capability set. Section 9.1 provides the tree diagram, which is 432 followed by a description of the various nodes within the module 433 defined in this draft. 435 9.1. Tree Diagram 437 This section provides a tree diagram [RFC8340] for the "ietf- 438 capability-set" module. The interpretation of the symbols appearing 439 in the tree diagram is as follows: 441 o Brackets "[" and "]" enclose list keys. 443 o Abbreviations before data node names: "rw" means configuration 444 (read-write), and "ro" means state data (read-only). 446 o Symbols after data node names: "?" means an optional node, "!" 447 means a presence container, and "*" denotes a list and leaf-list. 449 o Parentheses enclose choice and case nodes, and case nodes are also 450 marked with a colon (":"). 452 o Ellipsis ("...") stands for contents of subtrees that are not 453 shown. 455 The data model for the peering capability document has the following 456 structure: 458 module: ietf-sip-auto-peering 459 +--rw peering-info 460 +--rw variant string 461 +--rw transport-info 462 | +--rw transport? enumeration 463 | +--rw registrar* host-port 464 | +--rw registrarRealm? string 465 | +--rw callControl* host-port 466 | +--rw dns* inet:ip-address 467 | +--rw outboundProxy? host-port 468 +--rw call-specs 469 | +--rw earlyMedia? boolean 470 | +--rw signalingForking? boolean 471 | +--rw supportedMethods? string 472 +--rw media 473 | +--rw mediaTypeAudio 474 | | +--rw mediaFormat* string 475 | +--rw fax 476 | | +--rw protocol* enumeration 477 | +--rw rtp 478 | | +--rw RTPTrigger? boolean 479 | | +--rw symmetricRTP? boolean 480 | +--rw rtcp 481 | +--rw symmetricRTCP? boolean 482 | +--rw RTCPfeedback? boolean 483 +--rw dtmf 484 | +--rw payloadNumber? int8 485 | +--rw iteration? boolean 486 +--rw security 487 | +--rw signaling 488 | | +--rw type? string 489 | | +--rw version? string 490 | +--rw mediaSecurity 491 | +--rw keyManagement? string 492 +--rw extensions? string 494 9.2. YANG Model 496 This section defines the YANG module for the peering capability set 497 document. It imports modules (ietf-yang-types and ietf-inet-types) 498 from [RFC6991]. 500 module ietf-sip-auto-peering { 501 namespace "urn:ietf:params:xml:ns:ietf-sip-auto-peering"; 502 prefix "peering"; 504 description 505 "Data model for transmitting peering parameters from SP to Enterprise"; 506 revision 2019-05-06 { 507 description "Initial revision of peering-response doc."; 508 } 510 import ietf-inet-types { 511 prefix "inet"; 512 } 514 typedef ipv4-address-port { 515 type string { 516 pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 517 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 518 + ':^()([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])$'; 519 } 520 description "The ipv4-address-port type represents an IPv4 address in 521 dotted-quad notation followed by a port number."; 522 } 524 typedef ipv6-address-port { 525 type string { 526 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 527 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 528 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 529 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 530 + ':^()([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])$'; 531 pattern 532 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 533 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 534 + ':^()([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])$'; 535 } 536 description 537 "The ipv6-address type represents an IPv6 address in full, 538 mixed, shortened, and shortened-mixed notation followed by a port number."; 539 } 541 typedef ip-address-port { 542 type union { 543 type ipv4-address-port; 544 type ipv6-address-port; 545 } 546 description 547 "The ip-address-port type represents an IP address:port number 548 and is IP version neutral."; 549 } 551 typedef domain-name-port { 552 type string { 553 pattern 554 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 555 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 556 + '|\.' 557 + ':^()([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])$'; 558 length "1..258"; 559 } 560 description 561 "The domain-name-port type represents a DNS domain name followed by a port number. 562 The name SHOULD be fully qualified whenever possible."; 563 } 565 typedef host-port { 566 type union { 567 type ip-address-port; 568 type domain-name-port; 569 } 570 description 571 "The host type represents either an IP address or a DNS 572 domain name followed by a port number."; 573 } 575 container peering-info { 576 leaf variant { 577 type string; 578 mandatory true; 579 description "Variant of peering-response document"; 580 } 582 container transport-info { 583 leaf transport { 584 type enumeration { 585 enum "TCP"; 586 enum "TLS"; 587 enum "UDP"; 588 enum "TCP;TLS"; 589 enum "TCP;TLS;UDP"; 590 enum "TCP;UDP"; 591 } 592 description "Transport Protocol(s) used in SIP communication"; 593 } 595 leaf-list registrar { 596 type host-port; 597 max-elements 3; 598 description "List of service provider registrar servers"; 599 } 601 leaf registrarRealm { 602 type string; 603 description "Realm for REGISTER requests carrying credentials"; 604 } 606 leaf-list callControl { 607 type host-port; 608 max-elements 3; 609 description "List of service provider call control servers"; 610 } 612 leaf-list dns { 613 type inet:ip-address; 614 max-elements 2; 615 description "IP address of the DNS Server(s) hosted by the service provider"; 616 } 618 leaf outboundProxy { 619 type host-port; 620 description "SIP Outbound Proxy"; 621 } 622 } 624 container call-specs { 625 leaf earlyMedia { 626 type boolean; 627 description "Flag indicating whether the service provider is expected 628 to deliver early media."; 629 } 631 leaf signalingForking { 632 type boolean; 633 description "Flag indicating whether the service provider is capable 634 of forking incoming calls "; 635 } 637 leaf supportedMethods { 638 type string; 639 description "Leaf/Leaf List indicating the different SIP methods 640 support by the service provider."; 641 } 642 } 644 container media { 645 container mediaTypeAudio { 646 leaf-list mediaFormat { 647 type string; 648 description "Leaf List indicating the audio media formats supported."; 649 } 651 } 653 container fax { 654 leaf-list protocol { 655 type enumeration { 656 enum "pass-through"; 657 enum "t38"; 658 } 659 max-elements 2; 660 description "Leaf List indicating the different fax protocols 661 supported by the service provider."; 662 } 663 } 665 container rtp { 666 leaf RTPTrigger { 667 type boolean; 668 description "Flag indicating whether the service provider expects to 669 receive the first media packet."; 670 } 672 leaf symmetricRTP { 673 type boolean; 674 description "Flag indicating whether the service provider expects 675 symmetric RTP defined in [@RFC4961]"; 676 } 677 } 679 container rtcp { 680 leaf symmetricRTCP { 681 type boolean; 682 description " Flag indicating whether the service provider expects 683 symmetric RTP defined in [@RFC4961]."; 684 } 686 leaf RTCPfeedback { 687 type boolean; 688 description "Flag Indicating support for RTP profile extension for 689 RTCP-based feedback, as defined in [@RFC4585]"; 690 } 691 } 692 } 694 container dtmf { 695 leaf payloadNumber { 696 type int8 { 697 range "96..127"; 698 } 699 description "Leaf that indicates the payload number(s) supported by 700 the service provider for DTMF relay via Named-Telephony-Events"; 701 } 703 leaf iteration { 704 type boolean; 705 description "Flag identifying whether the service provider supports 706 NTE DTMF relay using the procedures of [@RFC2833] or [@RFC4733] ."; 707 } 708 } 710 container security { 711 container signaling { 712 leaf type { 713 type string { 714 pattern "TLS"; 715 } 716 description "Type of signaling security supported."; 717 } 719 leaf version { 720 type string { 721 pattern "([1-9]\.[0-9])(;[1-9]\.[0-9])?|(NULL)"; 722 } 723 description "Indicates TLS version for SIP signaling"; 724 } 725 } 727 container mediaSecurity { 728 leaf keyManagement { 729 type string { 730 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)"; 731 } 732 description "Leaf that identifies the key management methods 733 supported by the service provider for SRTP."; 734 } 735 } 736 } 738 leaf extensions { 739 type string; 740 description "Lists the various SIP extensions supported by SP"; 741 } 742 } 743 } 745 9.3. Node Definitions 747 This sub-sections provides the definition and encoding rules of the 748 various nodes of the YANG module defined in section 9.2 750 o *capability-set*: This node serves as a container for all the 751 other nodes in the YANG module; the capability-set node is akin to 752 the root element of an XML schema. 754 o *variant*: This node identifies the version number of the 755 capability set document. This draft defines the parameters for 756 variant 1.0; future specifications might define a richer parameter 757 set, in which case the variant can be changed to 2.0, 3.0 and so 758 on. Future extensions to the capability set document MUST also 759 ensure that the corresponding YANG module is defined. 761 o *transport-info*: The transport-info node is a container that 762 encapsulates transport characteristics of SIP sessions between 763 enterprise and service provider networks. 765 o *transport*: A leaf node that enumerates the different Transport 766 Layer protocols supported by the SIP service provider. Valid 767 transport layer protocols include: UDP, TCP, TLS or a combination 768 of them (with the exception of TLS and UDP). 770 o *registrar*: A leaf-list that specifies the transport address of 771 one or more registrar servers in the service provider network. 772 The transport address of the registrar can be provided using a 773 combination of a valid IP address and port number, or a subdomain 774 of the SIP service provider network, or the fully qualified domain 775 name (FQDN) of the SIP service provider network. If the transport 776 address of a registrar is specified using either a subdomain or a 777 fully qualified domain name, the DNS element needs to be populated 778 with one or more valid DNS server IP addresses. 780 o *callControl*: A leaf-list that specifies the transport address of 781 the call server(s) in the service provider network. The 782 enterprise network MUST use an applicable transport protocol in 783 conjunction with the call control server(s) transport address when 784 transmitting call setup requests. The transport address of a call 785 server(s) within the service provider network can be specified 786 using a combination of a valid IP address and port number, or a 787 subdomain of the SIP service provider network, or a fully 788 qualified domain name of the SIP service provider network. If the 789 transport address of a call control server(s) is specified using 790 either a subdomain or a fully qualified domain name, the DNS 791 element MUST be populated with one or more valid DNS server IP 792 addresses. The transport address specified in this element can 793 also serve as the target for non-call requests such as SIP 794 OPTIONS. 796 o *dns*: A leaf list that encodes the IP address of one or more DNS 797 servers hosted by the SIP service provider. If the enterprise 798 network is unaware of the IP address, port number, and transport 799 protocol of servers within the service provider network (for 800 example, the registrar and call control server), it MUST use DNS 801 NAPTR and SRV. Alternatively, if the enterprise network has the 802 fully qualified domain name of the SIP service provider network, 803 it MUST use DNS to resolve the said FQDN to an IP address. The 804 dns element encodes the IP address of one or more DNS servers 805 hosted in the service provider network. If however, either the 806 registrar or callControl elements or both are populated with a 807 valid IP address and port pair, the dns element MUST be set to the 808 quadruple octet of 0.0.0.0. 810 o *outboundProxy*: A leaf list that specifies the transport address 811 of one or more outbound proxies. The transport address can be 812 specified by using a combination of an IP address and a port 813 number, a subdomain of the SIP service provider network, or a 814 fully qualified domain name and port number of the SIP service 815 provider network. If the outbound-proxy sub-element is populated 816 with a valid transport address, it represents the default 817 destination for all outbound SIP requests and therefore, the 818 registrar and callControl elements MUST be populated with the 819 quadruple octet of 0.0.0.0. 821 o *call-specs*: A container that encapsulates information about call 822 specifications, restrictions and additional handling criteria for 823 SIP calls between the enterprise and service provider network. 825 o *earlyMedia*: A leaf that specifies whether the service provider 826 network is expected to deliver in-band announcements/tones before 827 call connect. The P-Early-Media header field can be used to 828 indicate pre-connect delivery of tones and announcements on a per- 829 call basis. However, given that signalling and media could 830 traverse a large number of intermediaries with varying 831 capabilities (in terms of handling of the P-Early-Media header 832 field) within the enterprise, such devices can be appropriately 833 configured for media cut through if it is known before-hand that 834 early media is expected for some or all of the outbound calls. 835 This element is a Boolean type, where a value of 1/true signifies 836 that the service provider is capable of early media. A value of 837 0/false signifies that the service provider is not expected to 838 generate early media. 840 o *signalingForking*: A leaf that specifies whether outbound call 841 requests from the enterprise might be forked on the service 842 provider network leading to multiple early dialogs. This 843 information would be useful to the enterprise network in 844 appropriately handling multiple early dialogs reliably and in 845 enforcing local policy. This element is a Boolen type, where a 846 value of 1/true signifies that the service provider network can 847 potentially fork outbound call requests from the enterprise. A 848 value of 0/false indicates that the service provider will not fork 849 outbound call requests. 851 o *supportedMethods*: A leaf node that specifies the various SIP 852 methods supported by the SIP service provider. The list of 853 supported methods help to appropriately configuration various 854 devices within the enterprise network. For example, if the 855 service provider enumerates support for the OPTIONS method, the 856 enterprise network could periodically send OPTIONS requests as a 857 keep-alive mechanism. 859 o *media*: A container that is used to collectively encapsulate the 860 characteristics of UDP-based audio streams. A future extension to 861 this draft may extend the media container to describe other media 862 types. The media container is also used to encapsulate basic 863 information about Real-Time Transport Protocol (RTP) and Real-Time 864 Transport Control Protocol (RTCP) from the perspective of the 865 service provider network. 867 o *mediaTypeAudio*: A container for the mediaFormat leaf-list. This 868 container collectively encapsulates the various audio media 869 formats supported by the SIP service provider. 871 o *mediaFormat*: A leaf-list encoding the various audio media 872 formats supported by the SIP service provider. The relative 873 ordering of different media format leaf nodes from left to right 874 indicates preference from the perspective of the service provider. 875 Each mediaFormat node begins with the encoding name of the media 876 format, which is the same encoding name as used in the "RTP/AVP" 877 and "RTP/SAVP" profiles. The encoding name is followed by 878 required and optional parameters for the given media format as 879 specified when the media format is registered [RFC4855]. Given 880 that the parameters of media formats can vary from one 881 communication session to another, for example, across two separate 882 communication sessions, the packetization time (ptime) used for 883 the PCMU media format might vary from 10 to 30 ms, the parameters 884 included in the format element MUST be the ones that are expected 885 to be invariant from the perspective of the service provider. 886 Providing information about supported media formats and their 887 respective parameters, allows enterprise networks to configure the 888 media plane characteristics of various devices such as endpoints 889 and middleboxes. The encoding name, one or more required 890 parameters, one or more optional parameters are all separated by a 891 semicolon. The formatting of a given media format parameter, MUST 892 follow the formatting rules as specified for that media format. 894 o *fax*: A container that encapsulates the fax protocol(s) supported 895 by the SIP service provider. The fax container encloses a leaf- 896 list (named protocol) that enumerates whether the service provider 897 supports t38 relay, protocol-based fax passthrough or both. The 898 relative ordering of leaf nodes within the leaf lists indicates 899 preference. 901 o *rtp*: A container that encapsulates generic characteristics of 902 RTP sessions between the enterprise and service provider network. 903 This node is a container for the "RTPTrigger" and "SymmetricRTP" 904 leaf nodes. 906 o *RTPTrigger*: A leaf node indicating whether the SIP service 907 provider network always expects the enterprise network to send the 908 first RTP packet for an established communication session. This 909 information is useful in scenarios such as "hairpinned" calls, in 910 which the caller and callee are on the service provider network 911 and because of sub-optimal media routing, an enterprise device 912 such as an SBC is retained in the media path. Based on the 913 encoding of this node, it is possible to configure enterprise 914 devices such as SBCs to start streaming media (possibly filled 915 with silence payloads) toward the address:port tuples provided by 916 caller and callee. This node is a Boolean type. A value of 1/ 917 true indicates that the service provider expects the enterprise 918 network to send the first RTP packet, whereas a value of 0/false 919 indicates that the service provider network does not require the 920 enterprise network to send the first media packet. While the 921 practise of preserving the enterprise network in a hairpinned call 922 flow is fairly common, it is RECOMMENDED that SIP service 923 providers avoid this practise. In the context of a hairpinned 924 call, the enterprise device retained in the call flow can easily 925 eavesdrop on the conversation between the offnet parties. 927 o *symmetricRTP*: A leaf node indicating whether the SIP service 928 provider expects the enterprise network to use symmetric RTP as 929 defined in [RFC4961]. Uncovering this expectation is useful in 930 scenarios where "latching" [RFC3762] is implemented in the service 931 provider network. This node is a Boolean type, a value of 1/true 932 indicates that the service provider expects the enterprise network 933 to use symmetric RTP, whereas a value of 0/false indicates that 934 the enterprise network can use asymmetric RTP. 936 o *rtcp*: A container that encapsulates generic characteristics of 937 RTCP sessions between the enterprise and service provider network. 938 This node is a container for the "RTCPFeedback" and 939 "SymmetricRTCP" leaf nodes. 941 o *RTCPFeedback*: A leaf node that indicates whether the SIP service 942 provider supports the RTP profile extension for RTCP-based 943 feedback [RFC4585]. Media sessions spanning enterprise and 944 service provider networks, are rarely made to flow directly 945 between the caller and callee, rather, it is often the case that 946 media traffic flows through network intermediaries such as SBCs. 947 As a result, RTCP traffic from the service provider network is 948 intercepted by these intermediaries, which in turn can either pass 949 across RTCP traffic unmodified or modify RTCP traffic before it is 950 forwarded to the endpoint in the enterprise network. Modification 951 of RTCP traffic would be required, for example, if the 952 intermediary has performed media payload transformation operations 953 such as transcoding or transrating. In a similar vein, for the 954 RTCP-based feedback mechanism as defined in [RFC4585] to be truly 955 effective, intermediaries MUST ensure that feedback messages are 956 passed reliably and with the correct formatting to enterprise 957 endpoints. This might require additional configuration and 958 considerations that need to be dealt with at the time of 959 provisioning the intermediary device. This node is a Boolean 960 type, a value of 1/true indicates that the service provider 961 supports the RTP profile extension for RTP-based feedback and a 962 value of 0/false indicates that the service provider does not 963 support the RTP profile extension for RTP-based feedback. 965 o *symmetricRTCP*: A leaf node indicating whether the SIP service 966 provider expects the enterprise network to use symmetric RTCP as 967 defined in [RFC4961]. This node is a Boolean type, a value of 1 968 indicates that the service provider expects symmetric RTCP 969 reports, whereas a value of 0 indicates that the enterprise can 970 use asymmetric RTCP. 972 o *dtmf*: A container that describes the various aspects of DTMF 973 relay via RTP Named Telephony Events. The dtmf container allows 974 SIP service providers to specify two facets of DTMF relay via 975 Named Telephony Events: 977 1. The payload type number using the payloadNumber leaf node. 979 2. Support for [RFC2833] or [RFC4733] using the iteration leaf node. 981 In the context of named telephony events, senders and receivers may 982 negotiate asymmetric payload type numbers. For example, the sender 983 might advertise payload type number 97 and the receiver might 984 advertise payload type number 101. In such instances, it is either 985 required for middleboxes to interwork payload type numbers or allow 986 the endpoints to send and receive asymmetric payload numbers. The 987 behaviour of middleboxes in this context is largely dependent on 988 endpoint capabilities or on service provider constraints. Therefore, 989 the payloadNumber leaf node can be used to determine middlebox 990 configuration before-hand. 992 [RFC4733]iterates over [RFC2833] by introducing certain changes in 993 the way NTE events are transmitted. SIP service providers can 994 indicate support for [RFC4733] by setting the iteration flag to 1 or 995 indicating support for [RFC2833] by setting the iteration flag to 0. 997 o *security*: A container that encapsulates characteristics about 998 encrypting signalling streams between the enterprise and SIP 999 service provider networks. 1001 o *signaling*: A container that encapsulates the type of security 1002 protocol for the SIP communication between the enterprise SBC and 1003 the service provider. 1005 o *type*: A leaf node that specifies the protocol used for 1006 protecting SIP signalling messages between the enterprise and 1007 service provider network. The value of the type leaf node is only 1008 defined for Transport Layer Security (TLS). Accordingly, if TLS 1009 is allowed for SIP sessions between the enterprise and service 1010 provider network, the type leaf node is set to the string "tls". 1012 o *version*: A leaf node that specifies the version(s) of TLS 1013 supported in decimal format. If multiple versions of TLS are 1014 supported, they MUST be separated by semi-colons. If the service 1015 provide does not support TLS for protecting SIP sessions, the 1016 signalling element is set to the string "NULL". 1018 o *mediaSecurity*: A container that describes the various 1019 characteristics of securing media streams between enterprise and 1020 service provider networks. 1022 o *keyManagement*: A leaf node that specifies the key management 1023 method used by the service provider. Possible values of this node 1024 include: "SDES" and "DTLS-SRTP". A value of "SDES" signifies that 1025 the SIP service provider uses the methods defined in [RFC4568] for 1026 the purpose of key management. A value of "DTLS-SRTP" signifies 1027 that the SIP service provider uses the methods defined in 1028 [RFC5764] for the purpose of key management. If the value of this 1029 leaf node is set to "DTLS-SRTP", the various versions of DTLS 1030 supported by the SIP service provider MUST be encoded as per the 1031 formatting rules of Section 9.2. If the service provider does not 1032 support media security, the keyManagement node MUST be set to 1033 "NULL". 1035 o *extensions*: A leaf node that is a semicolon separated list of 1036 all possible SIP option tags supported by the service provider 1037 network. These extensions MUST be referenced using name 1038 registered under IANA. If the service provider network does not 1039 support any extensions to baseline SIP, the extensions node MUST 1040 be set to "NULL". 1042 9.4. Extending the Capability Set 1044 There are situations in which equipment manufactures or service 1045 providers would benefit from extending the YANG module defined in 1046 this draft. For example, service providers could extend the YANG 1047 module to include information that further simplifies direct IP 1048 peering. Such information could include: trunk group identifiers, 1049 direct-inward-dial (DID) number ranges allocated to the enterprise, 1050 customer/enterprise account numbers, service provider support 1051 numbers, among others. 1053 Extension of the module can be achieved by importing the module 1054 defined in this draft. An example is provided below: 1056 Consider a new YANG module "vendorA" specified for VendorA's 1057 enterprise SBC. The "vendorA-config" YANG module is configured as 1058 follows: 1060 module vendorA-config { 1061 namespace "urn:ietf:params:xml:ns:yang:vendorA-config"; 1062 prefix "vendorA"; 1064 description 1065 "Data model for configuring VendorA Enterprise SBC"; 1067 revision 2020-05-06 { 1068 description "Initial revision of VendorA Enterprise SBC configuration data model"; 1069 } 1071 import ietf-peering { 1072 prefix "peering"; 1073 } 1075 augment "/peering:peering-info" { 1076 container vendorAConfig { 1077 leaf vendorAConfigParam1 { 1078 type int32; 1079 description "vendorA configuration parameter 1 (SBC Device ID)"; 1080 } 1082 leaf vendorAConfigParam2 { 1083 type string; 1084 description "vendorA configuration parameter 2 (SBC Device name)"; 1085 } 1086 description "Container for vendorA SBC configuration"; 1087 } 1088 } 1089 } 1091 In the example above, a custom module named "vendorA-config" uses the 1092 "augment" statement as defined in Section 4.2.8 of [RFC7950] to 1093 extend the module defined in this draft. 1095 10. Example Capability Set Document Encoding 1097 This section provides examples of how capability set documents that 1098 leverage the YANG module defined in this document can be encoded over 1099 JSON or XML. 1101 10.1. XML Capability Set Document 1103 1106 1.0 1107 1108 TCP;TLS;UDP 1109 registrar1.voip.example.com:5060 1110 registrar2.voip.example.com:5060 1111 voip.example.com 1112 callServer1.voip.example.com:5060 1113 192.168.12.25:5065 1114 8.8.8.8 1115 208.67.222.222 1116 0.0.0.0 1117 1118 1119 true 1120 false 1121 INVITE;OPTIONS;BYE;CANCEL;ACK;PRACK;SUBSCRIBE;NOTIFY;REGISTER 1122 1123 1124 1125 PCMU;rate=8000;ptime=20 1126 G729;rate=8000;annexb=yes 1127 G722;rate=8000;bitrate=56k,64k 1128 1129 1130 pass-through 1131 t38 1132 1133 1134 true 1135 true 1136 1137 1138 true 1139 true 1140 1141 1142 1143 101 1144 0 1145 1146 1147 1148 TLS 1149 1.0;1.2 1150 1151 1152 SDES;DTLS-SRTP,version=1.2 1153 1154 1155 timer;rel100;gin;path 1157 1159 11. Example Exchange 1161 This section depicts an example of the configuration flow that 1162 ultimately results in the enterprise edge element obtaining the 1163 capability set document from the SIP service provider. 1165 Assuming the enterprise edge element has been pre-configured with the 1166 request target for the capability set document or has dynamically 1167 found the request target, the edge element generates a HTTPS GET 1168 request. This request can be challenged by the service provider to 1169 authenticate the enterprise. 1171 GET //capdoc?trunkid=trunkent1456 HTTP/1.1 1172 Host: capserver.ssp1.com 1173 Accept:application/peering-info+xml 1175 The capability set document is obtained in the body of the response 1176 and is encoded in XML. 1178 HTTP/1.1 200 OK 1179 Content-Type: application/peering-info+xml 1180 Content-Length: nnn 1182 1183 ... 1184 1186 12. Security Considerations 1188 [TBD] 1190 13. Acknowledgments 1192 [TBD] 1194 14. References 1196 14.1. Normative References 1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1199 Requirement Levels", BCP 14, RFC 2119, 1200 DOI 10.17487/RFC2119, March 1997, 1201 . 1203 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1204 the Network Configuration Protocol (NETCONF)", RFC 6020, 1205 DOI 10.17487/RFC6020, October 2010, 1206 . 1208 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1209 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1210 . 1212 14.2. Informative References 1214 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 1215 Digits, Telephony Tones and Telephony Signals", RFC 2833, 1216 DOI 10.17487/RFC2833, May 2000, 1217 . 1219 [RFC3762] Levin, O., "Telephone Number Mapping (ENUM) Service 1220 Registration for H.323", RFC 3762, DOI 10.17487/RFC3762, 1221 April 2004, . 1223 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1224 Description Protocol (SDP) Security Descriptions for Media 1225 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 1226 . 1228 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1229 "Extended RTP Profile for Real-time Transport Control 1230 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1231 DOI 10.17487/RFC4585, July 2006, 1232 . 1234 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1235 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1236 DOI 10.17487/RFC4733, December 2006, 1237 . 1239 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1240 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1241 . 1243 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1244 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 1245 . 1247 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1248 Security (DTLS) Extension to Establish Keys for the Secure 1249 Real-time Transport Protocol (SRTP)", RFC 5764, 1250 DOI 10.17487/RFC5764, May 2010, 1251 . 1253 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1254 and A. Bierman, Ed., "Network Configuration Protocol 1255 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1256 . 1258 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1259 DOI 10.17487/RFC6665, July 2012, 1260 . 1262 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1263 Protocol (HTTP/1.1): Message Syntax and Routing", 1264 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1265 . 1267 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1268 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1269 DOI 10.17487/RFC7231, June 2014, 1270 . 1272 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1273 Protocol (HTTP/1.1): Authentication", RFC 7235, 1274 DOI 10.17487/RFC7235, June 2014, 1275 . 1277 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1278 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1279 . 1281 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1282 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1283 . 1285 Authors' Addresses 1287 Kaustubh Inamdar 1288 Cisco Systems 1290 Email: kinamdar@cisco.com 1291 Sreekanth Narayanan 1292 Cisco Systems 1294 Email: sreenara@cisco.com 1296 Cullen Jennings 1297 Cisco Systems 1299 Email: fluffy@iii.ca