idnits 2.17.1 draft-rosenbergjennings-dispatch-ripp-03.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 24 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 1022: '... provider MUST generate an authoriza...' RFC 2119 keyword, line 1024: '...he RIPP provider MUST mint a new URI i...' RFC 2119 keyword, line 1025: '...trunk. This URI MUST contain a path c...' RFC 2119 keyword, line 1026: '... MUST NOT contain any URI parameters...' RFC 2119 keyword, line 1027: '... and HTTP/3 MUST be supported for th...' (98 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1753 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 -- Obsolete informational reference (is this intentional?): RFC 2833 (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Rosenberg 3 Internet-Draft Five9 4 Intended status: Standards Track C. Jennings 5 Expires: January 9, 2020 Cisco Systems 6 A. Minessale 7 Signalwire/Freeswitch 8 J. Livingood 9 Comcast 10 J. Uberti 11 Google 12 July 8, 2019 14 Real Time Internet Peering Protocol 15 draft-rosenbergjennings-dispatch-ripp-03 17 Abstract 19 This document specifies the Realtime Internet Peering Protocol 20 (RIPP). RIPP is used to provide telephony peering between a trunking 21 provider (such as a telco), and a trunking consumer (such as an 22 enterprise, cloud PBX provider, cloud contact center provider, and so 23 on). RIPP is an alternative to SIP, SDP and RTP for this use case, 24 and is designed as a web application using HTTP/3. Using HTTP/3 25 allows trunking consumers to more easily build their applications on 26 top of cloud platforms, such as AWS, Azure and Google Cloud, all of 27 which are heavily focused on HTTP based services. RIPP also 28 addresses many of the challenges of traditional SIP-based trunking. 29 Most notably, it mandates secure caller ID via STIR, and provides 30 automated trunk provisioning as a mandatory protocol component. RIPP 31 supports both direct and "BYO" trunk configurations. Since it runs 32 over HTTP/3, it works through NATs and firewalls with the same ease 33 as HTTP does, and easily supports load balancing with elastic cluster 34 expansion and contraction, including auto-scaling - all because it is 35 nothing more than an HTTP application. RIPP also provides built in 36 mechanisms for migrations of calls between RIPP client and server 37 instances, enabling failover with call preservation. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 9, 2020. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 76 1.3. Solution . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.4. Why Now? . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Solution Requirements . . . . . . . . . . . . . . . . . . . . 6 79 3. Design Approaches . . . . . . . . . . . . . . . . . . . . . . 7 80 3.1. HBH, not E2E . . . . . . . . . . . . . . . . . . . . . . 7 81 3.2. Client-Server, not Agent-to-Agent . . . . . . . . . . . . 8 82 3.3. Signaling and Media Together . . . . . . . . . . . . . . 8 83 3.4. URIs not IPs . . . . . . . . . . . . . . . . . . . . . . 9 84 3.5. OAuth not MTLS or private IP . . . . . . . . . . . . . . 9 85 3.6. TLS not SRTP or SIPS . . . . . . . . . . . . . . . . . . 10 86 3.7. Authenticated CallerID . . . . . . . . . . . . . . . . . 10 87 3.8. Calls Separate from Connections . . . . . . . . . . . . . 11 88 3.9. Path Validation, not ICE . . . . . . . . . . . . . . . . 11 89 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 11 90 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 6. Overview of Operation . . . . . . . . . . . . . . . . . . . . 15 92 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 7.1. Inbound Call . . . . . . . . . . . . . . . . . . . . . . 20 94 7.2. Outbound Call . . . . . . . . . . . . . . . . . . . . . . 21 95 7.3. End of call . . . . . . . . . . . . . . . . . . . . . . . 21 96 8. Detailed Behaviours . . . . . . . . . . . . . . . . . . . . . 22 97 8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 22 98 8.2. RIPP Trunk Provisioning . . . . . . . . . . . . . . . . . 22 99 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 24 100 8.4. Initiating Calls . . . . . . . . . . . . . . . . . . . . 26 101 8.5. Establishing the Signaling Byways . . . . . . . . . . . . 28 102 8.6. The Media Sequence . . . . . . . . . . . . . . . . . . . 28 103 8.7. Opening Media Byways . . . . . . . . . . . . . . . . . . 29 104 8.8. Sending and Receiving Media . . . . . . . . . . . . . . . 30 105 8.9. Terminating and Re-establishing Connections and Byways . 31 106 8.10. Signaling - Events . . . . . . . . . . . . . . . . . . . 31 107 8.11. Call Termination . . . . . . . . . . . . . . . . . . . . 33 108 8.12. GET Transactions . . . . . . . . . . . . . . . . . . . . 34 109 8.13. Graceful Call Migration: Server . . . . . . . . . . . . . 34 110 8.14. Graceful Call Migration: Client . . . . . . . . . . . . . 34 111 8.15. Ungraceful Call Migration . . . . . . . . . . . . . . . . 34 112 9. SIP Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 35 113 9.1. RIPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 36 114 9.2. SIP to RIPP . . . . . . . . . . . . . . . . . . . . . . . 36 115 10. RAML API . . . . . . . . . . . . . . . . . . . . . . . . . . 36 116 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 117 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 118 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 119 14. Informative References . . . . . . . . . . . . . . . . . . . 39 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 122 1. Introduction 124 1.1. Background 126 Cloud computing platforms, such as those provided by Amazon, Azure, 127 and Google, have now become mainstream for the development of 128 software applications. These platforms are targeted at enabling web 129 applications, and as such many of their features are based on the 130 usage of HTTP. 132 One example are HTTP load balancers. Cloud computing platforms 133 provide highly scalable, geographically distributed, redundant load 134 balancers. These load balancers can monitor the state of downstream 135 servers and can uniformly distribute load amongst them. The load 136 balancers can compensate for failure of individual nodes and send new 137 traffic to other nodes. 139 Autoscaling is another example. The cloud computing platforms can 140 automatically add new instances of a server backend, or remove them, 141 and automatically configure the load balancers to include them in the 142 pool of available servers. 144 Yet another example is Kubernetes, which allows web-based 145 applications to be deployed into containers (typically Docker), with 146 load balancing, scaling, and HTTP request routing. 148 Another example are HTTP tracing tools, which facilitate the tracing 149 of requests through distributed microservices. These tools can 150 autogenerate sequence diagrams and facilitate in troubleshooting. 152 Yet another example are API gateways (such as APIGee and Kong), which 153 provide authentication and authorization, provisioning of 154 applications, rate limiting, analytics, sandboxing for testing, 155 embedded documentation, and so on. 157 And yet another example are denial-of-service prevention techniques, 158 typically done using BGP peering and re-routing. Though in principle 159 these techniques can work for VoIP, they are deployed in conjunction 160 with the load balancers which represent the entry point into these 161 cloud provider networks. Consequently, the protections these cloud 162 providers offer do not extend to applications which merely use these 163 platforms for virtual machines. 165 A more recent technology are service meshes, such as Istio, which 166 utilize sidecar HTTP proxies to facilitate inter-service 167 communications. These systems come with robust control planes which 168 enable additional routing features, such as canary deploys, 169 percentage based routing, and so on. 171 1.2. Problem Statement 173 Unfortunately, there are many applications being deployed into these 174 cloud platforms which require interconnection with the public 175 switched telephone network (PSTN). Examples of such applications 176 include cloud PBXs, cloud contact centers, cloud meetings 177 applications, and so on. Furthermore, commerce websites would like 178 to allow customers to call into the telephone network for customer 179 support. 181 In order for these applications to connect to the PSTN, they 182 typically deploy Session Initiation Protocol (SIP) [RFC3261] based 183 servers - SBCs, SIP proxies, and softswitches, to provide this 184 interconnection. Unfortunately, SIP based applications cannot make 185 use of the many capabilities these cloud platforms afford to HTTP 186 based applications. These SIP servers are usually deployed on bare 187 metal or VMs at best. Application developers must build their own 188 load balancing, HA, failover, clustering, security, and scaling 189 technologies, rather than using the capabilities of these platforms. 191 This has creating a barrier to entry, particularly for applications 192 such as websites which are not expert in VoIP technologies. 193 Furthermore, it has meant that VoIP applications have been unable to 194 take advantage of the many technology improvements that have come to 195 networking and protocol design since the publication of RFC 3261 in 196 2002. 198 In addition, SIP trunking has suffered from complex provisioning 199 operations, oftentimes requiring the exchange of static IPs and 200 ports. These operations are almost never self-service and 201 consequently, SIP trunk turn ups can take weeks. Finally, perhaps 202 the biggest challenge with SIP trunking has been its abuse for 203 injecting robocalls. 205 1.3. Solution 207 The goal of RIPP is to enable one administrative domain to send and 208 receive voice calls with another domain. In this regard, RIPP 209 replaces the usage of SIP, SDP offer/answer [RFC3264] and RTP 210 [RFC3550] for this particular use case. RIPP does not actually 211 deprecate or replace SIP itself, as it covers only a small subset of 212 the broader functionality that SIP provides. It is designed to be 213 the minimum protocol required to interconnect voice between a 214 trunking provider and a domain wishing to access trunking services. 216 In order to make use of new HTTP based technologies as described 217 above, RIPP uses HTTP/3 [I-D.ietf-quic-http], but is not an extension 218 to it. The goal is to ride the coattails of advancement in HTTP 219 based technologies without requiring them to do anything special for 220 the benefit of VoIP. This means that RIPP inherits the benefits of 221 classic HTTP deployments - easy load balancing, easy expansion and 222 contraction of clusters (including auto-scaling), standard techniques 223 for encryption, authentication, and denial-of-service prevention, and 224 so on. 226 RIPP also includes a built-in mechanism for provisioning, as a 227 mandatory component of the specification. This enables RIPP trunks 228 to be self-provisioned through web portals, and instantly turned on 229 in production. This will help accelerate the adoption of 230 telecommunications services across the web. 232 1.4. Why Now? 234 The idea of re-converging HTTP and SIP is certainly not new, and 235 indeed has been discussed in the hallways of IETF for many years. 236 However, several significant limitations made this previously 237 infeasible: 239 1. HTTP utilized TCP, which meant that it created head-of-line 240 blocking which would delay lost packets rather than just discard 241 them. This will often provide intolerable latency for VoIP. 243 2. HTTP was request response, allowing the client to send requests 244 and receive a response. There as no way for a server to 245 asynchronously send information to the client in an easy fashion. 247 HTTP2 [RFC7540] addressed the second of these with the introduction 248 of pushes and long running requests. However, its usage of TCP was 249 still a problem. This has finally been addressed with the arrival of 250 QUIC [I-D.ietf-quic-transport] and HTTP/3. QUIC is based on UDP, and 251 it introduces the concept of a stream that can be set up with zero 252 RTT. These streams are carried over UDP, and though are still 253 reliable, there is no head of line blocking across streams. This 254 change has made it possible for HTTP to support VoIP applications. 256 2. Solution Requirements 258 The protocol defined here is based on the following requirements: 260 REQ1: The solution shall not require extensions or modifications to 261 HTTP/3. 263 REQ2: The solution shall work with both L4 and L7 HTTP load balancers 265 REQ3: The solution shall work in ways that are compatible with best 266 practices for load balancers and proxies supporting HTTP/3, and not 267 require any special changes to these load balancers in order to 268 function. 270 REQ4: The solution should hide the number of servers behind the load 271 balancer, allow the addition or removal of servers from the cluster 272 at will, and not expose any of this information to the peer 274 REQ5: The solution shall enable the usage of autoscaling technologies 275 used in cloud platforms, without any special consideration for RIPP - 276 its just a web app 278 REQ6: The solution shall provide call preservation in the face of 279 failures of the server or client. It is acceptable for a brief blip 280 of media due to transient packet loss, but thats it 282 REQ7: The solution shall support built-in migration, allowing a 283 server to quickly shed load in order to be restarted or upgraded, 284 without any impact to calls in progress 286 REQ8: The solution will be easy to interoperate with SIP 287 REQ9: The solution shall be incrementally deployable - specifically 288 it must be designed for easy implementation by SBCs and easy 289 deployment by PSTN termination and origination providers who do not 290 utilize cloud platforms 292 REQ10: The solution shall require authentication and encryption, with 293 no opportunity to disable them. Furthermore, it will require secure 294 callerID, with no provision for insecure callerID 296 REQ11: The solution shall provide low latency for media 298 REQ12: The solution shall support only audio, but be extensible to 299 video or other media in the future 301 REQ13: The solution must support secure caller ID out of the gate and 302 not inherit any of the insecure techniques used with SIP 304 REQ14: The solution shall include mandatory-to-implement provisioning 305 operations 307 3. Design Approaches 309 To meet the requirements stated above, RIPP makes several fundamental 310 changes compared to SIP. These changes, and their motivations, are 311 described in the sections below. 313 3.1. HBH, not E2E 315 SIP was designed as an end-to-end protocol. As such, it explicitly 316 incorporates features which presume the existence of a network of 317 elements - proxies and registrars in particular. SIP provides many 318 features to facilitate this - Via headers, record-routing, and so on. 320 HTTP on the other hand - is strictly a hop-by-hop technology. Though 321 it does support the notion of proxies (ala the CONNECT method for 322 reverse proxies), the protocol is fundamentally designed to be 323 between a client and an authoritative server. What happens beyond 324 that authoritative server is beyond the scope of HTTP, and can (and 325 often does) include additional HTTP transactions. 327 Consequently, in order to reside within HTTP, RIPP follows the same 328 pattern and only concerns itself with HBH behaviours. Like HTTP, a 329 RIPP server can of course act as a RIPP client and further connect 330 calls to downstream elements. However, such behavior requires no 331 additional specification and is therefore not discussed by RIPP. 333 3.2. Client-Server, not Agent-to-Agent 335 SIP is based fundamentally on the User Agent, and describes the 336 communications between a pair of user agents. Either user agent can 337 initiate requests towards the other. SIP defines the traditional 338 role of client and server as bound to a specific transaction. 340 HTTP does not operate this way. In HTTP, one entity is a client, and 341 the other is a server. There is no way for the server to send 342 messages asynchronously towards the client. HTTP/3 does enable two 343 distinct techniques that facilitate server messaging towards the 344 client. But to use them, RIPP must abide by HTTP/3 rules, and that 345 means distinct roles for clients and servers. Clients must always 346 initiate connections and send requests, not servers. 348 To handle this RIPP, specifies that the domain associated with the 349 caller implements the RIPP client, and the domain receiving the calls 350 is the RIPP server. For any particular call, the roles of client and 351 server do not change. To facilitate calls in either direction, a 352 domain can implement both RIPP client and RIPP server roles. 353 However, there is no relationship between the two directions. 355 3.3. Signaling and Media Together 357 One of the most fundamental design properties of SIP was the 358 separation of signalling and media. This was fundamental to the 359 success of SIP, since it enabled high quality, low latency media 360 between endpoints inside of an enterprise or consumer domain. 362 This design technique is quite hard to translate to HTTP, especially 363 when considering load balancing and scaling techniques. HTTP load 364 balancing is effective because it treats each request/response pair 365 as an independent action which can route to any number of backends. 366 In essence, the request/response transaction is atomic, and 367 consequentially RIPP needs to operate this way as well. 369 Though SIP envisioned that signalling and media separation would also 370 apply to inter-domain calls, in practice this has not happened. 371 Inter-domain interconnect - used primarily for interconnection with 372 the PSTN - is done traditionally with SBCs which terminate and re- 373 originate media. Since this specification is targeted solely at 374 these peering use cases, RIPP fundamentally combines signalling and 375 media together on the same connection. To ensure low latency, it 376 uses multiple independent request/response transactions - each 377 running in parallel over unique QUIC streams - to transmit media. 379 3.4. URIs not IPs 381 SIP is full of IP addresses and ports. They are contained in Via 382 headers, in Route and Record-Route headers. In SDP. In Contact 383 headers. The usage of IPs is one of the main reasons why SIP is so 384 difficult to deploy into cloud platforms. These platforms are based 385 on the behavior of HTTP which has been baed on TCP connections and 386 therefore done most of its routing at the connection layer, and not 387 the IP layer. 389 Furthermore, modern cloud platforms are full of NATs and private IP 390 space, making them inhospitable to SIP based applications which still 391 struggle with NAT traversal. 393 HTTP of course does not suffer from this. In general, "addressing", 394 to the degree it exists at all, is done with HTTP URIs. RIPP follows 395 this pattern. RIPP - as a web application that uses HTTP/3 - does 396 not use or convey any IP addresses or ports. Furthermore, the client 397 never provides addressing to the server - all traffic is sent in the 398 reverse direction over the connection. 400 3.5. OAuth not MTLS or private IP 402 When used in peering arrangements today, authentication for the SIP 403 connections is typically done using mutual TLS. It is also often the 404 case that security is done at the IP layer, and sometimes even via 405 dedicated MPLS connections which require pre-provisioning. 406 Unfortunately, these techniques are quite incompatible with how 407 modern cloud platforms work. 409 HTTP - due to its client-server nature, uses asymmetric techniques 410 for authentication. Most notably, certificate based authentication 411 is done by the client to verify that it is speaking to the server it 412 thinks it should be speaking to. For the server to identify the 413 client, modern platforms make use of OAuth2.0. Though OAuth is not 414 actually an authentication protocol, the use of OAuth has allowed 415 authentication to be done out of band via separate identity servers 416 which produce OAuth tokens which can then be used for authentication 417 of the client. 419 Consequently, RIPP follows this same approach. For each call, one 420 domain acts as the client, and the other, as the server. When acting 421 as a server, the domain authenticates itself with TLS and verifies 422 the client with OAuth tokens. For calls in the reverse direction, 423 the roles are reversed. 425 To make it possible to easily pass calls in both directions, RIPP 426 allows one domain to act as the customer of another, the trunking 427 provider. The customer domain authenticates with the provider and 428 obtains an OAuth token using traditional techniques. RIPP then 429 allows the customer domain to automatically create a bearer token for 430 inbound calls and pass it to the provider. 432 3.6. TLS not SRTP or SIPS 434 SIP has provided encryption of both signalling and media, through the 435 usage of SIP over TLS and SIPS, and SRTP, respectively. 436 Unfortunately, these have not been widely deployed. The E2E nature 437 of SRTP has made keying an ongoing challenge, with multiple 438 technologies developed over the years. SIP itself has seen greater 439 uptake of TLS transport, but this remains uncommon largely due to the 440 commonality of private IP peering as an alternative. 442 Because of the HBH nature of RIPP, security is done fundamentally at 443 the connection level - identically to HTTP. Since media is also 444 carrier over the HTTP connection, both signalling and media are 445 covered by the connection security provided by HTTP/3. 447 Because of the mandatory usage of TLS1.3 with HTTP/3, and the 448 expected widespread deployment of HTTP/3, running VoIP on top of 449 HTTP/3 will bring built-in encryption of media and signalling between 450 peering domains, which is a notable improvement over the current 451 deployment situation. It is also necessary in order to utilize 452 HTTP/3. 454 Because of this, RIPP does not support SRTP. If a client receives a 455 SIP call with SRTP, it must terminate the SRTP and decrypt media 456 before sending it over RIPP. This matches existing practice in many 457 cases. 459 3.7. Authenticated CallerID 461 Robocalling is seeing a dramatic rise in volume, and efforts to 462 combat it continue. One of the causes of this problem is the ease of 463 which SIP enables one domain to initiate calls to another domain 464 without authenticated caller ID. 466 With RIPP, we remedy this by requiring the client and servers to 467 implement STIR. Since RIPP is meant for peering between providers 468 (and not client-to-server connections), STIR is applicable. RIPP 469 clients must either insert a signed passport, or pass one through if 470 it exists. Similarly, RIPP servers must act as verifying parties and 471 reject any calls that omit a passport. 473 o CJ - Need to check we have all the things needed in an Passport. 475 3.8. Calls Separate from Connections 477 In SIP, there is a fuzzy relationship between calls and connections. 478 In some cases, connection failures cause call terminations, and vice 479 a versa. 481 HTTP, on the other hand, very clearly separates the state of the 482 resource being manipulated, with the state of the HTTP connection 483 used to manipulate it. This design principle is inherited by RIPP. 484 Consequently, call state on both client and server exist 485 independently from the connections which manipulate them. This 486 allows for greater availability my enabling connections for the same 487 call to move between machines in the case of failures. 489 3.9. Path Validation, not ICE 491 HTTP/3 is designed to work through NAT as a client-server protocol. 492 It has built in techniques for dealing with NAT re-bindings, IP 493 address changes due to a client moving between networks (e.g., wifi 494 to cellular data). It has built in path validation that ensures that 495 HTTP cannot be used for amplification attacks. 497 SIP has, over the years, solved these problems to some degree, but 498 not efficiently nor completely. To work with HTTP, RIPP must utilize 499 the HTTP approaches for these problems. Consequently, RIPP does not 500 utilize ICE and has no specific considerations for NAT traversal, as 501 these are handled by HTTP/3 itself. 503 4. Reference Architecture 505 The RIPP reference architecture is shown in Figure 1. 507 Trunk Provider Trunk Consumer 509 Calls 510 +-------------+ From +-------------+ 511 | | A to B | | 512 | | | | 513 | Client | +--------> | Server | 514 | | | | 515 | | | | 516 +-------------+ +-------------+ 518 Calls 519 +-------------+ From +-------------+ 520 | | B to A | | 521 | | | | 522 | Server | <--------+ | Client | 523 | | | | 524 | | | | 525 +-------------+ +-------------+ 527 RIPP is used between a RIPP trunk provider and a RIPP trunk consumer. 528 Both entities implement the RIPP client and RIPP server roles; the 529 latter to receive calls, and the former to send them. 531 RIPP is also designed such that all communications between the a RIPP 532 client and the RIPP server can easily sit behind a typical HTTP load 533 balancer, as shown below: 535 +------------+ 536 | | 537 | RIPP | 538 >| Server | 539 / | | 540 / | | 541 / +------------+ 542 / 543 / 544 / 545 / 546 +---------+ / 547 | | / 548 +------------+ | | / +------------+ 549 | | | | / | | 550 | RIPP | | HTTP |/ | RIPP | 551 | Client |---->| LB | ----------->| Server | 552 | | | |\ | | 553 | | | | \ | | 554 +------------+ | | \ +------------+ 555 +---------+ \ 556 \ 557 \ 558 \ 559 \ 560 \ +------------+ 561 \ | | 562 \ | RIPP | 563 > | Server | 564 | | 565 | | 566 +------------+ 568 Since both the trunk provider and trunk consumer implement the client 569 and server roles, both entities will typically have a load balancer - 570 perhaps a server component, or a cloud-based service, used to receive 571 incoming calls. This is not required, of course. It is worth 572 restating that this load balancer is NOT specific to RIPP - it is any 573 off-the-shelf HTTP load balancer which supports HTTP/3. No specific 574 support for RIPP is required. RIPP is just a usage of HTTP. 576 Because RIPP clients and servers are nothing more than HTTP/3 577 applications, the behavior or RIPP is specified entirely by 578 describing how various RIPP procedures map to the core HTTP/3 579 primitives available to applications - opening connections, closing 580 connections, sending requests and responses, receiving requests and 581 responses, and setting header fields and bodies. That's it. 583 5. Terminology 585 This specification follows the terminology of HTTP/3 - specifically: 587 RIPP Client: The entity that initiates a call, by acting as an HTTP 588 client. 590 RIPP Server: The entity that receives a call, by acting as an HTTP 591 server. 593 RIPP Connection: An HTTP connection between a RIPP client and RIPP 594 server. 596 RIPP Endpoint: Either a RIPP client or RIPP server. 598 RIPP Peer: An endpoint. When discussing a particular endpoint, 599 "peer" refers to the endpoint that is remote to the primary subject 600 of discussion. 602 This specification defines the following additional terms: 604 RIPP Trunk: A container for calls between a trunking provider and 605 trunking consumer. A RIPP trunk is identified by a pair of URI - the 606 RIPP Trunk Provider URI (hosted by the trunking provider) and the 607 RIPP Trunk Consumer URI (hosted by the trunking consumer). RIPP 608 trunks act as a unit of policy and capabilities, including rules such 609 as rate limits, allowed phone numbers, and so on. 611 Call: A VoIP session established by a RIPP client for the purposes of 612 exchanging audio and signalling information. A call is always 613 associated with a RIPP trunk. 615 Trunking Consumer: An administrative entity that utilizes trunking 616 services from the trunking provider. The relationship between the 617 trunking consumer and trunking provider is static and does not vary 618 from call to call. (e.g., Verizon would be the trunking provider to 619 an enterprise consumer, and the enterprise would be the trunking 620 consumer of Verizon. A trunking consumer implements a RIPP client to 621 initiate calls to the trunking provider, and a RIPP server to receive 622 them. 624 Trunking Provider: The administrative entity that provides telephony 625 trunking services to the trunking consumer. The relationship between 626 the trunking consumer and trunking provider is static and does not 627 vary from call to call. (e.g., Verizon would be the trunking provider 628 to an enterprise, and the enterprise would be the trunking customer 629 of Verizon. The trunking provider implements a RIPP server to 630 receive calls from the trunking consumer, and a RIPP client to send 631 calls to the trunking consumer 633 Trunking Customer: The administrative entity which purchases trunking 634 services from the trunking provider. The trunking customer may be 635 the same as the trunking consumer - such as an enterprise purchasing 636 and then consuming trunking services from a telco. Or, it can be 637 different - such as an enterprise purchasing trunking services from a 638 telco, and then authorizing a cloud PBX or cloud contact center 639 provider to consume those trunking services on their behalf. 641 RIPP Trunk Provider URI: An HTTP URI hosted by the trunking provider, 642 which represents the RIPP trunk from its perspective. 644 RIPP Trunk Consumer URI: An HTTP URI hosted by the trunking consumer, 645 which represents the RIPP trunk from its perspective. 647 Byway: A bidirectional byte stream between a RIPP provider and 648 consumer. A Byway passes its data through a long-running HTTP 649 request and a long-running HTTP response. Byways are used for 650 signalling and media. 652 6. Overview of Operation 654 RIPP begins with a configuration phase. This configuration phase 655 occurs when an OAuth2.0 client application (such as a softswitch, 656 cloud PBX, cloud contact center, etc) wishes to enable trunking 657 customers to provision RIPP trunks against a trunking provider. The 658 trunking provider acts as the resource provider in OAuth2.0 parlance. 659 Consequently, The configuration phase is identical to the way in 660 which client applications register with resource providers in 661 OAuth2.0, the details of which are beyond the scope of this 662 specification, but expected to follow existing best practices used by 663 web applications. 665 The next step is provisioning. Once a trunking customer has obtained 666 access to services from a trunking provider (by purchasing them , for 667 example), the trunking customer can perform provisioning. 668 Provisioning is the process by which a trunking customer connects a 669 RIPP trunk from a trunking provider to trunking consumer. 670 Provisioning is accomplished using 671 OAuth2.0 code authorization techniques. In the case of RIPP, the 672 OAuth resource owner is the trunking customer. The OAuth client is 673 the RIPP implementation within the trunking consumer. The resource 674 server is the RIPP implementation in the trunking provider. 676 To provision a RIPP trunk, the trunking customer will visit a web 677 page hosted by the trunking consumer, and typically click on a button 678 labeled with their trunking provider. This will begin the OAuth 2 679 authorization code flow. The trunking customer will authenticate 680 with the trunking provider. The trunking provider authorizes the 681 access, generates an authorization code, and generates a RIPP trunk 682 provider URI. The provider URI is included in a new OAuth parameter 683 defined by this specification, and is returned as a parameter in the 684 authorization response. The trunking consumer trades the 685 authorization code for a refresh and access token, and stores the 686 provider URI. Finally, the trunking consumer mints a bearer token 687 associated with the new RIPP trunk, and also mints a RIPP trunk 688 consumer URI for receiving calls from the provider on this trunk. 689 Both of these are passed to the trunking provider via a POST 690 operation to /consumerTrunk on the RIPP trunk provider URI. 692 The usage of the OAuth2.0 flows enables the trunking consumer and 693 trunking customer to be the same (i.e., a cloud PBX provider 694 purchases services from a telco), or different (i.e., an enterprise 695 customer has purchased trunking services from a telco, and wishes to 696 provision them into a cloud contact center that acts as the trunking 697 consumer). The latter is often referred to informally as "BYOSIP" in 698 traditional SIP trunking and is explicitly supported by RIPP using 699 OAuth2.0. 701 Once provisioned, both sides obtain capability declarations for the 702 RIPP trunk by performing a GET to /capAdv of its peers trunk URI. 703 The capabilities declaration is a simple document, whose syntax is 704 described in Section Section 10. It conveys the receive capabilities 705 of the entity sending it, and includes parameters like maximum 706 bitrate for audio. This process is optional, and each parameter has 707 a default. Either side can update its capabilities for the RIPP 708 trunk at any time, and trigger a fresh GET via an HTTP push. 709 Capability declarations occur outside of a call, are optional, and 710 convey static receive capabilities which are a fixed property of the 711 RIPP trunk. Consequently, capability declaration is significantly 712 different from SDP offer/answer. 714 Either the trunking consumer or provider can initiate calls by 715 posting to the /calls on RIPP trunk URI of its peer. The request 716 contains the target phone number in the request URI and an Identity 717 header field in the HTTP Request. The Identity header field is 718 identical in syntax and semantics to the SIP Identity header field 719 defined in [RFC8224], just carried in HTTP instead of SIP. This 720 request returns a globally unique call URI in the Location header 721 field of a 201 response sent by the server. Typically the response 722 will also include a session cookie, bound to the call, to facilitate 723 sticky session routing in HTTP proxies. This allows all further 724 signalling and media to reach the same RIPP server that handled the 725 initial request, while facilitating failover should that server go 726 down. 728 Once a call has been created, a pair of long-lived HTTP transactions 729 is initiated from the client to the server for purposes of 730 signalling. One is a GET, retrieving call events from its peer. THe 731 other is a PUT, sending call events to its peer. Each of these 732 produces a unidirectional data stream, one in the forwards direction, 733 one in the reverse. These are called byways. HTTP/3 ensures zero 734 RTT for setup of these byways. 736 Signaling commands are encoded into the signalling byway using 737 streaming JSON in both directions. Each JSON object encodes an event 738 and its parameters. Events are defined for alerting, connected, 739 ended, migrate, keepalive, and transfer-and-takeback. 741 The media byways carry a simple binary encoding in both directions. 742 Even though data can flow in both directions, a media byway is 743 unidirectional in terms of media transmission. A forward media byway 744 carries media from the client to the server, and a reverse byway 745 carries media from the server to the client. To eliminate HOL 746 blocking for media, a media packet is sent on a media byway when it 747 is first established. After the first packet, the client cannot be 748 sure a subsequent packet will be delayed due to the ordering 749 guarantees provided by HTTP/3 within a stream. To combat this, both 750 sides acknowledge the receipt of each packet using an ACK message 751 sent over the media byways, in the opposite direction of the media. 752 Consequently, in a forward media byway, ACK messages are carried from 753 server to client, and in a reverse media byway, they are carried from 754 client to server. Once a media packet is acknowledged, the media 755 byway can be used once again without fear of HOL blocking. Because 756 each media packet is acknowledged independently, each side can 757 compute statistics on packet losses and delays. Consequently, the 758 equivalent of RTCP sender and receiver reports are not needed. 760 RIPP defines some basic requirements for congestion control at the 761 client side. Specifically, clients drop media packets if there are 762 too many media byways in the blocked state. 764 RIPP provides a simple technique for allowing a call to seamlessly 765 migrate from one client instance to another on a different host, or 766 from one server instance to another on a different host. For a 767 client, it need only end the byways in use for the call and re- 768 initiate from a different instance. Similarly, a server can request 769 migration, and this triggers the client to perform this same action. 770 The call state persists independently of the state of the HTTP 771 connection or the byways embedded in HTTP transactions, so that a 772 reconnect can continue where things left off. 774 Finally, RIPP trunks can be destroyed by a trunking consumer by 775 issuing a DELETE against the RIPP trunk provider URI. 777 7. Example 779 This section describes a typical example where one company, Acme, is 780 using a cloud calling service - Webex - and gets PSTN trunking from 781 the provider Comcast. 783 The sequence diagram for the outbound call flow is here: 785 +-----------+ +-----------+ 786 | consumer | | provider | 787 +-----------+ +-----------+ 788 | | 789 | PUT /trunks/123/consumerTrunk | 790 |---------------------------------------------------------->| 791 | --------------------------------\ | 792 |-| consumer trunk is /trunks/abc | | 793 | |-------------------------------| | 794 | | 795 | GET /trunks/abc/capAdv | 796 |<----------------------------------------------------------| 797 | | 798 | 200 OK w. consumer caps | 799 |---------------------------------------------------------->| 800 | | 801 | GET /trunks/123/capAdv | 802 |---------------------------------------------------------->| 803 | | 804 | 200 OK w. provider caps | 805 |<----------------------------------------------------------| 806 | | 807 | POST /trunks/123/calls&target=14085551212@e164.arpa | 808 |---------------------------------------------------------->| 809 | | 810 | 202 Created | 811 |<----------------------------------------------------------| 812 | ----------------------\ | 813 |-| Location: /call/xyz | | 814 | |---------------------| | 815 | | 816 | GET /call/xyz/event | 817 |---------------------------------------------------------->| 818 | ----------------------\ | 819 |-| signaling byway s2c | | 820 | |---------------------| | 821 | | 822 | 200 OK | 823 |<----------------------------------------------------------| 824 | | 825 | POST /call/xyz/media-forward | 826 |---------------------------------------------------------->| 827 | ------------------\ | 828 |-| media byway c2s | | 829 | |-----------------| | 830 | | 831 | 200 OK | 832 |<----------------------------------------------------------| 833 | | 834 | POST /call/xyz/media-reverse | 835 |---------------------------------------------------------->| 836 | ------------------\ | 837 |-| media byway s2c | | 838 | |-----------------| | 839 | | 840 | 200 OK | 841 |<----------------------------------------------------------| 842 | ----------------------\ | 843 | | ringing eg. SIP 180 |-| 844 | |---------------------| | 845 | | 846 | ringing event | 847 |<----------------------------------------------------------| 848 | -----------------------\ | 849 | | accepted eg. SIP 200 |-| 850 | |----------------------| | 851 | | 852 | accepted | 853 |<----------------------------------------------------------| 854 | ------------------\ | 855 |-| caller hangs up | | 856 | |-----------------| | 857 | | 858 | PUT /call/xyz/event | 859 |---------------------------------------------------------->| 860 | ------------\ | 861 |-| end event | | 862 | |-----------| | 863 | | 864 | 200 OK | 865 |<----------------------------------------------------------| 866 | | 868 The first stage is for Webex to set up their service to be able to 869 work as an OAuth Resource Server, working with Comcast as the 870 Authorization Server, and to obtain the baseURI that Comcast uses for 871 RIPP authorization. Assume that this is "https://ripp.comcast.com". 872 The next stage is the admin from ACME logs on to their Webex account 873 and selects Comcast as the RIPP provider. This will cause the OAUTH 874 dance and the admin will end up having approved Webex to use Acme's 875 account at Comcast for RIPP. Webex will have received an OAuth 876 access and refresh token from Comcast and be passed the new Provider 877 Trunk URI. At this point, provisioning is complete and calls can 878 start. Assume the provider trunk URI returned is 879 "https://ripp.comcast.com/trunks/123". 881 Webex will start by setting up for incoming calls at 882 "https://ripp.webex/trunks/abc" with an opaque security token of 883 "secret1234". This is done by making a HTTP PUT to 884 https://ripp.comcast.com/trunks/123/consumerTrunk with a JSON body 885 of: 887 { 888 "consumerTrunkURI":"https://ripp.webex/trunks/abc " , 889 "consumerToken":"secret1234" 890 } 892 The Comcast server will then find out the advertised capability of 893 the Webex trunk by doing a GET to https://ripp.webex/trunks/abc/ 894 capAdv and using the secret1234 as an authorization token. Webex 895 supports the default values but also support G.729 as an additional 896 codec. It returns a JSON body of: 898 { "audio/g729": true } 900 Similarly, the Webex server will find out the advertised capability 901 of the trunk by doing a GET to https:://ripp.comcast.com/trunks/123/ 902 capAdv, using its OAuth token. In this case, the response is empty, 903 indicating that the capabilities are all default. 905 At this point we are ready for inbound or outbound calls. 907 7.1. Inbound Call 909 A PSTN calls arrives at Comcast that is routed to the this trunk via 910 a Comcast SBC that will convert it from SIP to RIPP. The SBC knows 911 which codecs the trunk supports (G.729, Opus and G.711) and can 912 immediately send the SIP answer in a 183. It can then can make an 913 HTTP post to the consumer trunk URI to set up the incoming call. 914 This is does by doing a POST to "https://ripp.webex/trunks/acme123/ 915 calls&target=14085551212@e164.arpa" using the authorization token 916 "secret1234". This will return a new call URI for this call of 917 https://ripp.webex/call/xyz. 919 At this point the SBC can make a long poll GET and PUT to 920 "https://ripp.webex/call/xyz/events" to receive and send signaling 921 events for this call. The SBC will also open a number of media 922 byways by making POST requests to "https://ripp.webex/call/xyz/media- 923 forward" and "https://ripp.webex/call/xyz/media-reverse" to send and 924 receive media. 926 For each of the media-forward byways, the Comcast SBC will send a 927 BywayPreamble that tells the other side meta data about what will be 928 sent on this byway. For the media-reverse byways, the Webex server 929 will send the BywayPreamble. The BywayPreamble contains the name of 930 the codec, the base sequence number, frameTime, and baseTime. After 931 this BywayPreamble, media frames can be sent that contain a seqOffset 932 number, media length, and then the media data. The receiver compute 933 the time sequence number for the frame by adding the baseSeqNum for 934 the byway to the seqOffset for the frame. The timestamp for the 935 media is computed using the baseTime for the byway plus the packeTime 936 multiplied by the seqNum. 938 The data from the https://ripp.webex/call/xyz/events request will be 939 an infinite JSON array of Events. When the Webex server answers the 940 call, the event returned would look like: 942 { "name":"accepted" } 944 7.2. Outbound Call 946 For Webex to make it outbound call, it is the same as the inbound 947 call other than the provider trunk URI is used. The Webex server 948 would act as a client and do a HTTP POST to 949 "https://ripp.comcast.com/trunks/123/ 950 calls&target=14085551212@e164.arpa" to create a call URI of 951 "http\s://ripp.comcast.com/call/c789". From that point the flow is 952 roughly the same as inbound with the client and server roles 953 reversed. 955 7.3. End of call 957 If the call is ended on the server side, server sends a terminated 958 event with the ended flag set to true then waits a small time for 959 client to close the connection then closes the connection. 961 If the call is ended on the client side, the client sends a 962 terminated event with the ended flag set to true and then closes the 963 connection. In either case the even looks like: 965 { "name":"terminated", "ended": true } 967 8. Detailed Behaviours 969 This section provides an overview of the operation of RIPP. 971 8.1. Configuration 973 RIPP configuration happens when a trunking consumer wishes to be able 974 to provision, on demand, new RIPP trunks with a trunking provider. 976 One example use case is that of an enterprise, which has deployed an 977 IP PBX of some sort within its data centers. Once deployed, the 978 enterprise needs to enable the PBX to place and receive calls towards 979 the PSTN. The enterprise contracts with a RIPP trunking provider. 980 All of this happens as a precursor to configuration. At the end of 981 the contracting process, the enterprise administrator will visit the 982 configuration web page, and be able to register their enterprise PBX. 983 This process will typically return a client-ID, client-secret, and 984 authorization endpoint URL. The administrator manually enters these 985 into the configuration of their PBX. [[OPEN ISSUE: OpenID connect?]] 987 As another example use case, a cloud contact center, cloud PBX 988 provider, or any other saas application which wishes to obtain 989 trunking services, can contract with a RIPP trunking provider. In a 990 similar process to the enterprise case above, the administrator 991 obtains a clientID, client-secret, and authorization endpoint URL 992 which are configured into their service. 994 In the final use case, an enterprise administrator has purchased 995 trunking services from a RIPP trunking provider. They separately 996 have purchased cloud PBX, cloud contact center, or another saas 997 service which requires connectivity to a RIPP trunk. In this case, 998 the cloud PBX, cloud contact center, or other saas service acts as 999 the RIPP trunk consumer. The RIPP trunk consumer would configure 1000 itself as a client with a variety of RIPP trunking providers, and for 1001 each, obtain the clientID, client-secret and authorization URL. This 1002 will allow the customers of the RIPP trunking consumer to provision 1003 RIPP trunks automatically, and point them to the RIPP trunking 1004 consumer. 1006 8.2. RIPP Trunk Provisioning 1008 Once a RIPP consumer has been configured as an OAuth client 1009 application with a RIPP provider, a RIPP customer can provision a 1010 RIPP trunk on-demand using a web form. RIPP consumers will typically 1011 provide a self-service web form for such provisioning, since self- 1012 service and instant provisioning are key goals of RIPP. 1014 The RIPP customer visits this web form, and selects their provider. 1015 The RIPP consumer would then initiate an OAuth2.0 authorization code 1016 flow. This utilizes the clientID, client-secret and authorization 1017 endpoint URL configured previously. The RIPP customer will 1018 authenticate to the RIPP provider, and authorize creation of a new 1019 RIPP trunk. 1021 Once the RIPP customer authorizes creation of a RIPP trunk, the RIPP 1022 provider MUST generate an authorization code and follow the 1023 procedures defined in [RFC6749] for the authorization code grant 1024 flow. Furthermore, the RIPP provider MUST mint a new URI identifying 1025 this new RIPP trunk. This URI MUST contain a path component, and 1026 MUST NOT contain any URI parameters. This URI MUST be an HTTPS URI, 1027 and HTTP/3 MUST be supported for this URI. The path component MUST 1028 be a globally unique identifier for this trunk, and not depend on the 1029 authority component as part of the namespace for purposes of 1030 uniqueness. 1032 As an example, the following is a valid RIPP trunk URI: 1034 1036 This URI MUST be returned in the OAuth2.0 parameter "ripp-trunk", and 1037 MUST be base64 encoded. 1039 The RIPP consumer MUST follow the procedures defined in [RFC6749] for 1040 an OAuth client, trade in its authorization code for both a refresh 1041 and access token. The RIPP provider MUST issue both refresh and 1042 access tokens. It is expected that the refresh token will last a 1043 long time, in order to avoid the resource owner needing to manually 1044 re-authorize. The trunk consumer MUST be prepared for its access and 1045 refresh tokens to be invalidated at any time. The RIPP consumer MUST 1046 extract the "ripp-trunk" OAuth parameter from the authorization 1047 response, decode, and persist it. 1049 Once the RIPP consumer has obtained an access token, it MUST initiate 1050 an HTTPS PUT request towards /consumerTrunk on the provider trunk 1051 URI. This request MUST contain an Authorization header field 1052 utilizing the access token just obtained. It MUST include a RIPP 1053 provisioning object in the body. This object is specified in 1054 Section Section 10. 1056 The RIPP provisioning object MUST contain a RIPP trunk consumer URI 1057 and a RIPP bearer token. The RIPP consumer MUST mint an HTTPS URI 1058 for the RIPP Trunk consumer URI. This URI MUST support HTTP/3, and 1059 MUST implement the behaviours associated with capabilities and new 1060 call operations as defined below. This URI MUST have a path 1061 component, MUST NOT contain any URI parameters, and MUST have a path 1062 segment which is globally unique. 1064 In addition, the RIPP consumer MUST mint a bearer token to be used by 1065 the RIPP provider when performing operations against the RIPP Trunk 1066 Client URI. The bearer token MAY be constructed in any way desired 1067 by the RIPP consumer. The token and URI SHOULD remain valid for at 1068 least one day, however, a security problem could cuase them to be 1069 invalidated. The RIPP consumer MUST refresh the provisioning against 1070 the RIPP trunk at least one hour in advance of the expiration, in 1071 order to ensure no calls are delayed. 1073 At this point, the RIPP trunk is provisioned. Both the RIPP provider 1074 and RIPP consumer have a RIPP trunk URI and an Authorization token to 1075 be used for placing calls in each direction. 1077 8.3. Capabilities 1079 Once provisioned, each side obtains receive capabilities about the 1080 trunk from its peer. To do that, each client performs an HTTP GET to 1081 /capAdv on its peer's RIPP trunk URI. The response body MUST be a 1082 RIPP capabilities object as defined in Section Section 10. 1084 Once established, either side MAY update the capabilities by sending 1085 an HTTP push to trigger its peer to fetch a fresh capability 1086 document. Due to race conditions, it is possible that the client may 1087 receive calls compliant to the old capabilities document for a brief 1088 interval. It MUST be prepared for this. 1090 When the trunk resource is destroyed, its associated capabilities are 1091 also destroyed. 1093 The RIPP capabilities document is a list of name-value pairs, which 1094 specify a capability. Every capability has a default, so that if no 1095 document is posted, or it is posted but a specific capability is not 1096 included, the capability for the peer is understood. Capabilities 1097 are receive only, and specify what the entity is willing to receive. 1098 Capabilities are bound to the RIPP trunk, and are destroyed when the 1099 RIPP trunk is destroyed. 1101 This specification defines the following capability set. This set is 1102 extensible through an IANA registry. 1104 o max-bitrate: The maximum bitrate for receiving voice. This is 1105 specified in bits per second. It MUST be greater than or equal to 1107 1. Its default is 64000. 1109 o max-samplerate: The maximum sample rate for audio. This is 1110 specified in Hz. It MUST be greater than or equal to 8000. Its 1111 default is 8000. 1113 o max-samplesize: The maximum sample size for audio. This is 1114 specified in bits. It MUST be greater than or equal to 8. The 1115 default is 16. 1117 o force-cbr: Indicates whether the entity requires CBR media only. 1118 It MUST be either "true" or "false". The default is "false". If 1119 "true", the sender MUST send constant rate audio. 1121 o two-channel: Indicates whether the entity supports receiving two 1122 audio channels or not. Two channel audio is specifically used for 1123 RIPP trunks meant to convey listen-only media for the purposes of 1124 recording, similar to SIPREC [RFC7866]. It MUST be either "true" 1125 or "false". The default is "false". 1127 o tnt: Indicates whether the entity supports the takeback-and- 1128 transfer command. Telcos supporting this feature on a trunk would 1129 set it to "true". The value MUST be "true" or "false". The 1130 default is "false". 1132 In addition, codecs can be listed as capabilities. This is done by 1133 using the media type and subtype, separated by a "/", as the 1134 capability name. Media type and subtype values are taken from the 1135 IANA registry for RTP payload format media types, as defined in 1136 [RFC4855]. The value of the capability is "true" if the codec is 1137 supported, "false" if it is not. The default is "false" for all 1138 codecs except for "audio/PCMU", "audio/opus", "audio/telephone-event" 1139 and "audio/CN", for which the default is "true". Because codec 1140 capabilities are receive-only, it is possible, and totally 1141 acceptable, for there to be different audio codecs used in each 1142 direction. 1144 In general, an entity MUST declare a capability for any 1145 characteristic of a call which may result in the call being rejected. 1146 This requirement facilitates prevention of call failures, along with 1147 clear indications of why calls have failed when they do. For 1148 example, if a RIPP trunk provider provisions a trunk without support 1149 for G.729, but the consumer configures their to utilize this codec, 1150 this will be known as a misconfiguration immediately. This enables 1151 validation of trunk configurations in an automated fashion, without 1152 placing test calls or calling customer support. 1154 8.4. Initiating Calls 1156 HTTP connections are completely independent of RIPP trunks or calls. 1157 As such, RIPP clients SHOULD reuse existing HTTP connections for any 1158 request targeted at the same authority to which an existing HTTP 1159 connection is open. RIPP clients SHOULD also utilize 0-RTT HTTP 1160 procedures in order to speed up call setup times. 1162 To initiate a new call, a RIPP client creates an HTTPS POST request 1163 to /calls endpoint on the RIPP trunk URI of its peer. For a trunking 1164 consumer, this is the RIPP trunk URI provisioned during the OAuth2.0 1165 flow. For the trunking provider, it is the RIPP trunk consumer URI 1166 learned through the provisioning POST operation. This MUST be an 1167 HTTP/3 transaction. The client MUST validate that the TLS 1168 certificate that is returned matches the authority component of the 1169 RIPP trunk URI. 1171 This request MUST contain the token that the client has obtained out- 1172 of-band. For the RIPP trunk consumer, this is the OAuth token. For 1173 the RIPP trunk provider, it is the bearer token learned through the 1174 provisioning POST operation. 1176 The client MUST also add the "target" URI parameter. This parameter 1177 MUST be of the form user@domain. If the target is a phone number on 1178 the PSTN, this must take the form @e164.arpa, where is a valid E.164 1179 number. RIPP also supports private trunks, in which case the it MUST 1180 take the form @, where the number is a non-E164 number scoped to be 1181 valid within the domain. This form MUST NOT be used for E.164 1182 numbers. Finally, RIPP can be used to place call to application 1183 services - such as a recorder - in which case the parameter would 1184 take the form of an RFC822 email address. 1186 The client MUST add an HTTP Identity header field. This header field 1187 is defined in Section Section 11 as a new HTTP header field. Its 1188 contents MUST be a valid Identity header field as defined by 1189 [RFC8224]. This ensures that all calls utilize secure caller ID. A 1190 RIPP client MUST NOT place the caller ID in any place except for the 1191 Identity header field in this request. Specifically, a "From", 1192 "Contact", or "P-Asserted-ID" header field MUST NOT ever appear. 1194 o CJ - I would prefer to add this another way without using a 1195 header. 1197 The server MUST validate the OAuth token, MUST act as the verifying 1198 party to verify the Identity header field, and then authorize the 1199 creation of a new call, and then either accept or reject the request. 1200 If accepted, it indicates that the server is willing to create this 1201 call. The server MUST return a 201 Created response, and MUST 1202 include a Location header field containing an HTTPS URI which 1203 identifies the call that has been created. The URI identifying the 1204 call MUST include a path segment which contains a type 4 UUID, 1205 ensuring that call identifiers are globally unique. 1207 The server MAY include HTTP session cookies in the 201 response. The 1208 client MUST support receipt of cookies [RFC6265]. It MUST be 1209 prepared to receive up to 10 cookies per call. The client MUST 1210 destroy all cookies associated with a call, when the call has ended. 1211 Cookies MUST NOT be larger the 5K. 1213 The usage of an HTTP URI to identify the call itself, combined with 1214 session cookies, gives the terminating RIPP domain a great deal of 1215 flexibility in how it manages state for the call. In traditional 1216 softswitch designs, call and media state is held in-memory in the 1217 server and not placed into databases. In such a design, a RIPP 1218 server can use the session cookie in combination with sticky session 1219 routing in the load balancers to ensure that subsequent requests for 1220 the same call go to the same call server. Alternatively, if the 1221 server is not using any kind of HTTP load balancer at all, it can use 1222 a specific hostname in the URI to route all requests for this call to 1223 a specific instance of the server. This technique is particularly 1224 useful for telcos who have not deployed HTTP infrastructure, but do 1225 have SBCs that sit behind a single virtual IP address. The root URI 1226 can use a domain whose A record maps to this IP. Once a call has 1227 landed on a particular SBC, the call URI can indicate the specific IP 1228 of the SBC. 1230 For example, the RIPP trunk URI for such a telco operator might be: 1232 1234 which always resolves to 1.2.3.4, the VIP shared amongst the SBC 1235 farm. Consequently, a request to this RIPP trunk would hit a 1236 specific SBC behind the VIP. This SBC would then create the call and 1237 return a call URL which points to its actual IP, using DNS 1239 1241 However, the HTTP URI for the call MUST NOT contain an IP address; it 1242 MUST utilize a valid host or domain name. This is to ensure that TLS 1243 certificate validation functions properly without manual 1244 configuration of certificates (a practice which is required still for 1245 SIP based peering). 1247 Neither the request, nor the response, contain bodies. 1249 8.5. Establishing the Signaling Byways 1251 To perform signalling for this call, the client MUST initiate an HTTP 1252 GET and PUT request towards the call URI that it just obtained, 1253 targeted at the /event endpoint. 1255 The signaling is accomplished by a long running HTTP transaction, 1256 with a stream of JSON in the PUT request, and a stream of JSON in the 1257 GET response. 1259 The body begins with an open curly bracket, and after that is a 1260 series of JSON objects, each starting with a curly bracket, and 1261 ending with a curly bracket. Consequently, each side MUST 1262 immediately send their respective open brackets after the HTTP header 1263 fields. We utilize streaming JSON in order to facilitate usage of 1264 tools like CURL for signalling operations. 1266 8.6. The Media Sequence 1268 In RIPP, media is represented as a continuous sequence of RIPP media 1269 frames embedded in a media byway. Each ripp media frame encodes a 1270 variable length sequence number offset, followed by a variable length 1271 length field, followed by a codec frame equal to that length. The 1272 media byway itself, when created, includes properties that are shared 1273 across all media frames within that byway. These parameters include 1274 the sequence number base, the timestamp base, the codec type, and the 1275 frame size in milliseconds for the codec. 1277 This is a significantly different design than RTP, which conveys many 1278 repeated parameters (such as the payload type and timestamp) in every 1279 packet. Instead, RIPP extracts information that will be shared 1280 across many packets and associates it with the byway itself. This 1281 means the media frames only contain the information which varies - 1282 the sequence number and length. [[OPEN ISSUE: we could maybe even 1283 eliminate the sequence number by computing it from offset in the 1284 stream. Worried about sync problems though?]] 1286 Consequently, each media frame has the following properties: 1288 o The sequence number, which is equal to the sequence number base 1289 associated with the media byway, PLUS the value of the sequence 1290 number offset 1292 o The timestamp, which is equal to the timestamp base from the 1293 byway, PLUS the sequence number offset TIMES the frame size in 1294 milliseconds. Note that this requires that frame size must remain 1295 fixed for all media frames in a byway. 1297 o The codec type, which is a fixed property of the byway. There are 1298 no payload type numbers in RIPP. 1300 RIPP does not support gaps in the media sequence due to silence. 1301 Something must be transmitted for each time interval. If a RIPP 1302 implementation wishes to change codecs, it MUST utilize a different 1303 byway for that codec. 1305 8.7. Opening Media Byways 1307 The client bears the responsibility for opening media byways - both 1308 forward and reverse. Consequently, the server is strongly dependent 1309 on the client opening reverse byways; it cannot send media unless 1310 they've been opened. 1312 A client MUST open a new forward byway whenever it has a media frame 1313 to send, all existing forward byways (if any) are in the blocked 1314 state, and the client has not yet opened 20 byways. 1316 Furthermore, the client MUST keep a minimum of 10 reverse byways open 1317 at all times. This ensures the server can send media. The client 1318 MUST open these byways immediately, in parallel. 1320 The use of multiple media byways in either direction is essential to 1321 low latency operation of RIPP. This is because, as describe below, 1322 media frames are sprayed across these byways in order to ensure that 1323 there is never head-of-line blocking. This is possible because, in 1324 HTTP/3, each transaction is carried over a separate QUIC stream, and 1325 QUIC streams run on top of UDP. Furthermore, a QUIC stream does not 1326 require a handshake to be established - creation of new QUIC streams 1327 is a 0-RTT process. 1329 The requests to create these transactions MUST include Cookie headers 1330 for any applicable session cookies. 1332 To open a forward media byway, the client MUST initiate a POST 1333 request to the /media-forward endpoint on the call URI, and MUST 1334 include a RIPP-Media header field in the request headers. Similarly, 1335 to open a reverse media byway, the client MUST initiate a POST 1336 request to the /media-reverse endpoint of the call URI. It MUST NOT 1337 include a RIPP-Media header field in the request headers. The server 1338 MUST include the RIPP-Media header in the response headers. The 1339 RIPP-Media header contains the properties for the byway - the 1340 sequence number base, the timestamp base, and the name of the codec. 1342 RIPP supports multiple audio channels, meant for SIPREC use cases. 1343 Each channel MUST be on a separate byway. When multi-channel audio 1344 is being used, the client MUST include the multi-channel parameter 1345 and MUST include the channel number, starting at 1. 1347 All RIPP implementations MUST support G.711 and Opus audio codecs. 1348 All implementations MUST support [RFC2833] for DTMF, and MUST support 1349 [RFC3389] for comfort noise, for both sending and receiving. 1351 The sequence number space is unique for each direction, channel, and 1352 call (as identified by the call URI). Each side MUST start the 1353 sequence number at zero, and MUST increment it by one for each 1354 subsequent media frame. The sequence number base is represented as a 1355 string corresponding to a 32 bit unsigned integer, and the sequence 1356 number offset in the media frame is variable length, representing an 1357 unsigned integer. Consequently, the sequence number space for a 1358 media stream within a call has a total space of 32 bits. With a 1359 minimum frame size of 10ms, RIPP can support call durations as long 1360 as 11,930 hours. Rollover of the sequence number is not permitted, 1361 the client or server MUST end the call before rollover. This means 1362 that the combination of call URI, direction (client to server, or 1363 server to client), channel number, and sequence number represent a 1364 unique identifier for media packets. 1366 8.8. Sending and Receiving Media 1368 The approach for media is media striping. 1370 To avoid HOL blocking, we cannot send a second media packet on a 1371 byway until we are sure the prior media packet was received. This is 1372 why the client opens multiple media byways. 1374 When either the client or server sends a media frame on a byway, it 1375 immediately marks the byway as blocked. At that point, it SHOULD NOT 1376 send another media frame on that byway. The client or server notes 1377 the sequence number and channel number for that media frame. Once it 1378 receives an acknowledgement for that corresponding media frame, it 1379 marks the byway as UNBLOCKED. A client or server MAY send a media 1380 frame on any unblocked byway. 1382 The sequence number for the media frame is computed based on the 1383 rules described above. 1385 Per the logic described above, the client will open additional byways 1386 once the number of blocked byways goes above a threshold. If a the 1387 number of blocked byways in either direction hits 75% of the total 1388 for that direction, this is a signal that congestion has occurred. 1389 In such a case, the client or server MUST either drop packets at the 1390 application layer, or buffer them for later transmission. [[TODO: 1392 can we play with QUIC priorities to prioritize newer media frames 1393 over older?]] 1395 When a client or server receives a media frame, it MUST send an 1396 acknowledge message. This message MUST be sent on the same byway on 1397 which the media was received. This acknowledgement message MUST 1398 contain the full sequence number and channel number for the media 1399 packet that was received. It MUST also contain the timestamp, 1400 represented as wallclock time, at which the media packet was 1401 received. 1403 If the server has marked 75% of the reverse media byways as blocked, 1404 it MUST send a signaling event instructing the client to open another 1405 reverse media byway. Once this command is received, the client MUST 1406 open a new reverse byway, unless the total number of byways has 1407 reached 20. 1409 A client MAY terminate media byways gracefully if they have not sent 1410 or received packets on that byway for 5 or more seconds. This is to 1411 clean up unused byways. 1413 There is no need for sender or receiver reports. The equivalent 1414 information is knowable from the application layer acknowledgements. 1416 8.9. Terminating and Re-establishing Connections and Byways 1418 The state of the connection, the QUIC streams, and byways, is 1419 separate from the state of the call. The client MAY terminate an 1420 HTTP connection or byway at any time, and re-establish it. 1421 Similarly, the server or client may end the a byway at any time. 1423 If a byway ends or the connection breaks or is migrated, the client 1424 MUST re-initiate the byways immediately, or risk loss of media and 1425 signalling events. However, to deal with the fact that re- 1426 establishment takes time, both client and server MUST buffer their 1427 signalling and media streams for at least 5 seconds, and then once 1428 the connections and byways are re-established, it sends all buffered 1429 data immediately. 1431 Note that it is the sole responsibility of the client to make sure 1432 byways are re-established if they fail unexpectedly. 1434 8.10. Signaling - Events 1436 Signaling is performed by having the client and server exchange 1437 events. Each event is a JSON object embedded in the signalling 1438 stream, which conveys the event as perceived by the client or server. 1439 Each event has a sequence number, which starts at zero for a call, 1440 and increases by one for each event. The sequence number space is 1441 unique in each direction. The event also contains a direction field, 1442 which indicates whether the event was sent from client to server, or 1443 server to client. It also contains a timestamp field, which 1444 indicates the time of the event as perceived by the sender. This 1445 timestamp is not updated when retransmissions happen; the timestamp 1446 exists at the RIPP application layer and RIPP cannot directly observe 1447 HTTP retransmits. 1449 It also contains a call field, which contains the URI of the call in 1450 question. 1452 Finally, there is an event type field, which conveys the type of 1453 event. This is followed by additional fields which are specific to 1454 the event type. 1456 This structure means that each event carried in the signalling is 1457 totally self-describing, irregardless of the enclosing connection and 1458 stream. This greatly facilitates logging, debugging, 1459 retransmissions, retries, and other race conditions which may deliver 1460 the same event multiple times, or deliver an event to a server which 1461 is not aware of the call. 1463 Events are also defined so that the resulting state is uniquely 1464 defined by the event itself. This ensures that knowing the most 1465 recent event is sufficient to determine the state of the call. 1467 This specification defines the following events: 1469 alerting: Passed from server to client, indicating that the recipient 1470 is alerting. 1472 accepted: Passed from server to client, indicating that the call was 1473 accepted. 1475 rejected: Passed from server to client, indicating that the call was 1476 rejected by the user. 1478 failed: Passed from server to client, indicating that the call was 1479 rejected by server or downstream servers, not by the user, but due to 1480 some kind of error condition. This event contains a response code 1481 and reason phrase, which are identical to the response codes and 1482 reason phrases in SIP. 1484 noanswer: Passed from server to client, indicating that the call was 1485 delivered to the receiving user but was not answered, and the server 1486 or a downstream server timed out the call. 1488 end: initiated by either client or server, it indicates that the call 1489 is to be terminated. Note that this does NOT delete the HTTP 1490 resource, it merely changes its state to call end. Furthermore, a 1491 call cannot be ended with a DELETE against the call URI; DELETE is 1492 not permitted and MUST be rejected by the server. The call end event 1493 SHOULD contain a reason, using the Reason codes defined for SIP. 1495 o CJ - Not keen on SIP reason codes - they did not conatin enough 1496 info for all the Q950 stuff and were not particually extensible. 1497 I think it would be better to define a set here with clear mapping 1498 to SIP and SIP +Q950 reasons. 1500 migrate: sent from server to client, it instructs the client to 1501 terminate the connections and re-establish them to a new URI which 1502 replaces the URI for the call. The event contains the new URI to 1503 use. This new URI MUST utilize the same path components, and MUST 1504 have a different authority component. 1506 open-reverse: sent from server to client, it instructs the client to 1507 open an additional set of reverse media byways. 1509 o CJ - would it work to have this all far simplier and just have the 1510 trunk cap advertisemtn say how many to open up ? 1512 tnt: send from consumer to provider, it invokes a takeback-and- 1513 transfer operation. It includes the phone number to which the call 1514 should be transferred. The provide will then transfer the call to 1515 the target number. This event is meant to invoke the feature as it 1516 has been implemented by the provider. RIPP does not define 1517 additional behaviors. 1519 8.11. Call Termination 1521 Signaling allows an application layer call end to be sent. This will 1522 also cause each side to terminate the the outstanding transactions 1523 using end flags per HTTP/3 specs. However, the opposite is not true 1524 - ending of the transactions or connection does not impact the call 1525 state. 1527 A server MUST maintain a timer, with a value equal to one second, for 1528 which it will hold the call in its current state without any active 1529 signalling byway. If the server does not receive a signalling byway 1530 before the expiration of this timer, it MUST consider the call as 1531 ended. Once the call has ended, the call resource SHOULD be 1532 destroyed. 1534 If the server receives a signalling or media byway for a call that is 1535 TERMINATED, it MUST reject the transaction with an 404 response code, 1536 since the resource no longer exists. 1538 8.12. GET Transactions 1540 A client MAY initiate a GET request against the call URI at any time. 1541 This returns the current state of the resource. This request returns 1542 the most recent event, either sent by the server or received by the 1543 server. 1545 o CJ - lets call this previosEvent as the event part waits till the 1546 next event on a long poll. Be good to say something about how 1547 this is used as it is not clear to me it is needed. 1549 8.13. Graceful Call Migration: Server 1551 To facilitate operational maintenance, the protocol has built in 1552 support for allowing a server instance to drain all active calls to 1553 another server instance. 1555 The server can issue a migrate event over the signalling byway, which 1556 includes a new call URI that the peer should use. Once received, the 1557 client closes all transactions to the current call URI. It then 1558 establishes new signalling, media and media control byways to the URI 1559 it just received. All media that the client wishes to transmit, but 1560 was unable to do so during the migration, is buffered and then sent 1561 in a burst once the media byways are re-established. This ensures 1562 there is no packet loss (though there will be jitter) during the 1563 migration period. 1565 We don't use QUIC layer connection migration, as that is triggered by 1566 network changes and not likely to be exposed to applications. 1568 8.14. Graceful Call Migration: Client 1570 Clients can move a call from one client instance to another easily. 1571 No commands are required. The client simply ends the in-progress 1572 transactions for signalling and media, and then reinitiates them to 1573 the existing call URI from whatever server is to take over. Note 1574 that the client MUST do this within 1s or the server will end the 1575 call. 1577 8.15. Ungraceful Call Migration 1579 Since all media packets are acknowledged at the application layer, it 1580 is possible for endpoints to very quickly detect remote failures, 1581 network failures, and other related problems. 1583 Failure detection falls entirely at the hands of the client. A 1584 failure situation is detected when any one of the following happens: 1586 1. The QUIC connection closes unexpectedly 1588 2. Any outstanding signalling or media byway is reset by the peer 1590 3. No media packets are received from the peer for 1s 1592 4. No acknowledgements are received for packets that have been sent 1593 in the last 1s 1595 If the client detects such a failure, it MUST abort all ongoing 1596 transactions to the server, terminate the QUIC connection, and then 1597 establish a new connection using 0-RTT, and re-establish signalling 1598 and media transactions. If this retry fails, the client MUST 1599 consider the call terminated. It SHOULD NOT a further attempt to re- 1600 establish the call. 1602 o CJ - Note there is no way to know if it can use 0-RTT or not, all 1603 depends on cached state so the best it can do is hope it might 1604 work. 1606 9. SIP Gateway 1608 RIPP is designed to be easy to gateway from SIP. The expectation is 1609 that RIPP will be implemented in SBCs and softswitches. A SIP to 1610 RIPP gateway has to be call-stateful, acting as a B2BUA, in order to 1611 gateway to RIPP. Furthermore, a SIP to RIPP gateway has to act as a 1612 media termination point in SIP. It has to perform any SRTP 1613 decryption and encryption, and it must de-packetize RTP packets to 1614 extract their timestamps, sequence numbers, and codec types. 1616 SIP to RIPP gateways are not transparent. SIP header fields which 1617 are unknown or do not map to RIPP functionality as described here, 1618 MUST be discarded. 1620 Any configuration and provisioning for RIPP happens ahead of receipt 1621 or transmission of SIP calls. Consequently, the logic described here 1622 applies at the point that a gateway receives a SIP INVITE on the SIP 1623 side, or receives a POST to the RIPP trunk URI on the RIPP side. 1625 This specification does define some normative procedures for the 1626 gateway function in order to maximize interoperability. 1628 9.1. RIPP to SIP 1630 9.2. SIP to RIPP 1632 10. RAML API 1634 #%RAML 1.0 1635 --- 1636 title: RIPP 1637 baseUri: http://ripp.example.net/{version} 1638 version: v1 1639 protocols: [ HTTPS ] 1640 securedBy: [ oauth_2_0 ] 1641 securitySchemes: 1642 oauth_2_0: !include securitySchemes/oauth_2_0.raml 1644 types: 1645 InboundEndpoint: 1646 type: object 1647 properties: 1648 consumerTrunkURI: string 1649 consumerToken: string 1650 Event: 1651 type: object 1652 properties: 1653 name: 1654 enum: [ alerting, accepted, rejected, failed, tnt, migrate, end,open-reverse ] 1655 direction: 1656 enum: [c2s, s2c] 1657 sequence number: 1658 type: number 1659 timestamp: 1660 type: number 1661 ended: 1662 type: boolean 1663 timeStamp: 1664 type: datetime 1665 tntDestination: 1666 type: string 1667 note: only in events with name tnt 1668 migrateToURl: 1669 type: string 1670 note: only in events with name migrate 1671 Advertisement: 1672 type object 1673 properties: 1674 max-bitrate: number 1675 max-samplerate: number 1676 max-channels: number 1677 non-e164: boolean 1678 force-cbr: boolean 1679 tnt: boolean 1680 Frame: 1681 seqNumOffset: number 1682 dataLen: number 1683 data: string 1684 FrameAck: 1685 seqNum: number 1686 BywayPreamble: 1687 baseSeqNum: number 1688 baseTime: number 1689 frameTime: number 1690 codec: 1691 enum: [ opus, g711, dtmf, cn, ack ] 1692 BywayMedia: 1693 mediaFrames: array 1695 /trunks: 1696 /{trunkID}: 1697 /consumerTrunk: 1698 put: 1699 description: Set the URI and security token for consumer trunk URI 1700 securedBy: [oauth_2_0] 1701 /capAdv: 1702 get: 1703 description: Get the Capability Advertisement for this trunk 1704 securedBy: [oauth_2_0] 1705 responses: 1706 200: 1707 body: 1708 application/json: 1709 type: Advertisement 1710 /calls: 1711 post: 1712 queryParameters: 1713 target: 1714 securedBy: [oauth_2_0] 1715 description: Create a new call. Returns a Call URI 1716 responses: 1717 202: 1719 /call: 1720 /{callID}: 1722 /prevEvent: 1723 get: 1724 description: Retreive the previous event from server 1725 responses: 1726 200: 1727 body: 1728 application/json: 1729 type: Event 1730 /event: 1731 get: 1732 description: Wait for next event then retreive the most recent event from server 1733 responses: 1734 200: 1735 body: 1736 application/json: 1737 type: Event 1738 put: 1739 description: Tell server about recent event 1740 body: 1741 application/json: 1742 type: Event 1743 responses: 1744 200: 1745 /media-forward: 1746 post: 1747 description: Starts an infinite flow of media frames from client to server 1748 body: 1749 application/octet-stream: 1750 type: BywayFlow 1751 responses: 1752 200: 1753 application/octet-stream: 1754 type: BywayFlow 1755 /media-reverse: 1756 post: 1757 description: Starts an infinite flow of media frames from server to client 1758 body: 1759 application/octet-stream: 1760 type: BywayFlow 1761 responses: 1762 200: 1763 application/octet-stream: 1764 type: BywayFlow 1766 11. IANA Considerations 1768 12. Security Considerations 1770 13. Acknowledgements 1772 14. Informative References 1774 [I-D.ietf-quic-http] 1775 Bishop, M., "Hypertext Transfer Protocol Version 3 1776 (HTTP/3)", draft-ietf-quic-http-20 (work in progress), 1777 April 2019. 1779 [I-D.ietf-quic-transport] 1780 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1781 and Secure Transport", draft-ietf-quic-transport-20 (work 1782 in progress), April 2019. 1784 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 1785 Digits, Telephony Tones and Telephony Signals", RFC 2833, 1786 DOI 10.17487/RFC2833, May 2000, 1787 . 1789 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1790 A., Peterson, J., Sparks, R., Handley, M., and E. 1791 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1792 DOI 10.17487/RFC3261, June 2002, 1793 . 1795 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1796 with Session Description Protocol (SDP)", RFC 3264, 1797 DOI 10.17487/RFC3264, June 2002, 1798 . 1800 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 1801 Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, 1802 September 2002, . 1804 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1805 Jacobson, "RTP: A Transport Protocol for Real-Time 1806 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1807 July 2003, . 1809 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1810 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1811 . 1813 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1814 DOI 10.17487/RFC6265, April 2011, 1815 . 1817 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1818 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1819 . 1821 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1822 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1823 DOI 10.17487/RFC7540, May 2015, 1824 . 1826 [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. 1827 Hutton, "Session Recording Protocol", RFC 7866, 1828 DOI 10.17487/RFC7866, May 2016, 1829 . 1831 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1832 "Authenticated Identity Management in the Session 1833 Initiation Protocol (SIP)", RFC 8224, 1834 DOI 10.17487/RFC8224, February 2018, 1835 . 1837 Authors' Addresses 1839 Jonathan Rosenberg 1840 Five9 1842 Email: jdrosen@jdrosen.net 1844 Cullen Jennings 1845 Cisco Systems 1847 Email: fluffy@iii.ca 1849 Anthony Minessale 1850 Signalwire/Freeswitch 1852 Email: anthm@signalwire.com 1854 Jason Livingood 1855 Comcast 1857 Email: jason_livingood@comcast.com 1858 Justin Uberti 1859 Google 1861 Email: justin@uberti.name