idnits 2.17.1 draft-rosenberg-dispatch-ript-inbound-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2020) is 1534 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 February 7, 2020 5 Expires: August 10, 2020 7 RealTime Internet Peering for Single User Endpoints 8 draft-rosenberg-dispatch-ript-inbound-00 10 Abstract 12 The Real-Time Internet Peering for Telephony (RIPT) protocol defines 13 a technique for establishing, terminating and otherwise managing 14 calls between entities in differing administrative domains. While it 15 can be used for single user devices like an IP phone, it requires the 16 IP phone to have TLS certificates and be publically reachable with a 17 DNS record. This specification remedies this by extending RIPP to 18 enable clients to receive inbound calls. It also provides basic 19 single-user features such as forking, call push and pull, third-party 20 call controls, and call appearances. It describes techniques for 21 resiliency of calls, especially for mobile clients with spotty 22 network connectivity. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 10, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Differences with SIP Outbound . . . . . . . . . . . . . . . . 3 60 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 61 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Inbound Call Forking . . . . . . . . . . . . . . . . . . 6 63 4.2. Answer and Stop Ringing Other Devices . . . . . . . . . . 6 64 4.3. Remote in Use . . . . . . . . . . . . . . . . . . . . . . 7 65 4.4. Call Pull . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.5. Call Push . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.6. Select Device . . . . . . . . . . . . . . . . . . . . . . 8 68 4.7. Third Party Call Control - Place Outbound . . . . . . . . 8 69 4.8. Third Party Call Control Answer or Decline Inbound . . . 9 70 4.9. Third Party Call Control Hangup . . . . . . . . . . . . 9 71 4.10. Third Party Call Control Move Call . . . . . . . . . . . 9 72 4.11. Resiliency Miss Incoming call . . . . . . . . . . . . . . 10 73 4.12. Resiliency MidCall Network Change . . . . . . . . . . . . 10 74 4.13. Resiliency MidCall Wireless Fade and Recover . . . . . . 10 75 4.14. Resiliency MidCall Wireless Fade and Move . . . . . . . . 11 76 4.15. Resiliency MidCall Wireless Fade and Peer Hangup . . . . 11 77 4.16. Resiliency MidCall Wireless Fade and Server Drop . . . . 11 78 5. Normative Protocol Specification . . . . . . . . . . . . . . 12 79 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 The Real-Time Internet Peering Protocol (RIPT) defines a technique 95 for establishing, terminating and otherwise managing calls between 96 entities. It is an application ontop of HTTP/3, and as such has the 97 notion of a client that opens connections and makes requests to a 98 server. In the core RIPT specification, clients can only place 99 outbound calls. Inbound calls are supported by requiring an entity 100 to also run a server. 102 While this requirement is appropriate for use cases like SIP 103 trunking, carrier to carrier peering, or other arrangements involving 104 a large number of calls, it is a poor match for single user devices. 105 A single user device is one in which an actual end user would log in 106 and use that device for making and receiving calls. Exampes include 107 desktop softphones, browser based webRTC appications, IP hardphones, 108 and video conferencing endpoints. These devices are often behind a 109 NAT, dont have DNS names, and don't have TLS certificates, all of 110 which are pre-requisiites to run a server. 112 Furthermore, an end user may often be logged into multiple such 113 devices, possibly from multiple locations. This introduces 114 additional requirements. Inbound calls need to be forked to all 115 devices, and ring on all of them. A user must be able to answer on 116 one, and stop ringing on the others. SIP [RFC3261] natively 117 supported these capabilities. However, it lacked other ones which 118 are clearly needed - native support for mobile-based apps which 119 utilize push notifications is one significant example. 121 SIP's lack of call state in servers as a built-in feature of the 122 protocol has also meant it couldn't readily support other features 123 truly needed for a system where a user can be logged into multiple 124 devices. These include the ability for one device to see the state 125 of the call, and know on which other device the call is being 126 handled. Another important feature includes the ability to - from 127 any device - end the call, move it to a different device, or on the 128 device the user is sitting on. It also includes basic third party 129 call controls - the ability to initiate or answer a call from one 130 client, but have the media delivered to another. 132 To remedy these challenges this specification provides an extension 133 to RIPT to facilitate single-user devices. 135 2. Differences with SIP Outbound 137 This specification covers a similar problem space as SIP Outboud 138 [RFC5626], however it works much differently. 140 Firstly, delivery of an inbound call to an IP phone in a timely 141 fashion clearly requires the IP phone to be able to have some kind of 142 persistent connection over which it can receive incoming call 143 indications. In SIP Outbound, the specification itself provided this 144 capability. This specification, however, does not. Rather, it 145 assumes that it merely exists, and is provided through some non- 146 standardied means, which we refer to as a "push channel". 148 For mobile devices, the push channel is provided by the mobile OS. 149 For browser applications, it might be provided by a websocket 150 connection that the application is using to receive a variety of 151 events, including those having nothing to do with calling. 153 The push channel is also used to provide an indication of feature 154 invocations to the client when those features are invoked elsewhere 155 (ie., third party call control). The specific feature names and 156 other UI elements are out of scope for this spceification as well. 157 Rather, this specification only shows how, once a client knows it 158 needs perform a call manipulation, it can use RIPT to do it. 160 The second significant difference compared to SIP Outbound is that 161 RIPT does not use the push channel to push actual protocol messages; 162 rather it uses it as a "shoulder tap" to let the client know about a 163 new event, and provide it a URI with which it can get more 164 information or take action. 166 3. Overview of Operation 168 To signal usage of this specification, the server includes a new 169 element, "inbound", in its TG description. The format of this 170 element is identical to what it would look like to receive calls on a 171 TG that would have been hosted by the single-user device, had it been 172 able to do so. For example, the following TG describes a single user 173 TG which can handle both outbound and inbound calls: 175 { 176 "outbound": { 177 "origins" : (encoded passport) 178 "destinations" : "*" 179 }, 180 "inbound": { 181 "destinations" : "+14085551002", 182 } 183 } 185 The client will follow RIPT procedures for handler registration. 186 This is analagous to the SIP REGISTER operation. For server to 187 server peering arrangements, the handler represents a particular 188 collection of capabilities on an SBC or IP PBX. When used by single- 189 user devices, it represents each individual device. Consequently, if 190 a user has four IP phones, there would be four handlers created on 191 the server. As specified in RIPT each client needs to remember its 192 handler URI persistently in order to modify it or delete it later on. 194 If an incoming call arrives for the client, the server creates the 195 call, including the call URI, and the push channel is used to inform 196 the client of a new call, and provide it with the call URI. The 197 client performs a GET against this URI to obtain the information 198 about the call. As defined in the core RIPT specification, this will 199 provide the client with the calling and caller party identifiers, 200 call direction (here, inbound), and the client directive. The client 201 can then alert the user, and in parallel establish the signaling and 202 media byways. The client can send the proceeding, alerting, 203 answered, or declined events to the server to adjust the state of the 204 call. Once answered, the call is active and processing proceeds 205 identically to the case where it had placed an outbound call. 207 Multi-device handling follows from the fact that the server will 208 broadcast all call events to all open GET requests to /events on the 209 call. As such, if there are multiple IP phones, each of which 210 receives a push notification of the new call, all of them will 211 perform a GET on the call URI, establish signaling and media byways, 212 and then alert the user. Once the user answers on one device, the 213 call state changes to answered and this event is sent to the other 214 devices, which can cease ringing. Furthermore, the other devices can 215 follow the state of the call by maintaining a GET to /events, even 216 though they are not sending or receiving media. 218 Since other devices can track the state of the call, they can render 219 it while the call is ongoing - providing basic 'shared call 220 appearance' functionality. 222 The movement of calls between different devices is learned through a 223 new event defined here, the "handler changed" event, which is sent by 224 the server. Its payload is the URI of the new handler. 226 The core RIPT specification also provides a simple way for one device 227 to take a call from another - by using a client-side migration. The 228 device which wishes to take the call would POST to the call URI, 229 changing the handler to itself. It would get a new, modified 230 directive, and then connect its media byways to begin sending and 231 receiving media. 233 These basic primitives can be used in concert with application- 234 specific (and non-standardized) user interface and push channel 235 contents to accomplish many different functions. 237 4. Example Use Cases 239 This section outlines example use cases that are enabled by this 240 specification. It is not normative in nature. It merely describes 241 how the new API features defined by this specification can be used by 242 clients to deal with these cases. 244 4.1. Inbound Call Forking 246 Consider two devices - A and B. A single user, Alice, logs into both 247 devices. These devices query the provider, and through the 248 techniques described in RIPT, get the TG for the service provided to 249 Alice and register their respective handlers. Furthermore, assume 250 that device A only supports G.711 and Opus, while device B supports 251 both Opus, G.711, and G.729. 253 When a new call arrives for Alice, the server would create a call 254 URI, and use the push channel to inform both devices that a new call 255 has arrived. The push notification would inform the IP Phones of the 256 call URI. Both phones perform a GET against the call URI, which 257 returns the caller and called numbers, call direction, and current 258 state - which is proceeding. Since the clients see that this call 259 has not yet been answered, both of them render UI and begin alerting. 260 Both will also open signaling byways to the call URI and PUT 261 "proceeding" and then "alerting" events. The server will in turn, 262 echo the "alerting" events back to all clients which are receiving 263 events on the byway, since the state of the call has changed to 264 "alerting". 266 This achieves the basic forking operation. 268 4.2. Answer and Stop Ringing Other Devices 270 Consider now that user Alice answers on device A. This will cause 271 device A to send an "answered" event to the server. In parallel, it 272 will perform a POST to the call URI and provide its handler URI in 273 the body. The response includes the directive for the call. This 274 allows the server to know that device A doesnt support G.729, and 275 thus it directs device A to send with G.711. Furthemore, the server 276 would send the "answered" event to all other clients which have an 277 open signaling byway, which in this case is phone B. It will receive 278 the "answered" event and thus cease ringing. 280 Note that - had IP phone B receive the original push notification 281 late, if it should query the call URI after the call has been 282 answered, it would see that the state is answered and thus not ring. 283 Because the server maintais state, it is resilient to intermittent 284 client connectivity. 286 4.3. Remote in Use 288 Consider further now what happens with device B. The call is being 289 handled on device A. However, device B maintains its signaling 290 byway. As a result, it will see the the call remains live. If that 291 call should end, the client would receive the "ended" event from the 292 server, and therefore be able to show that the call is no longer 293 active. 295 Additionally, if the service provider offers advanced telephony 296 features such as "hold" or "transfer", those state changes could be 297 delivered to device B via the push-channel. Similarly, the client 298 could query - using web APIs beyond the scope of this specification - 299 to learn about states like "on-hold". (OPEN ISSUE: this does seem a 300 bit wonky that RIPP is used for the basic call state, but a separate 301 web API is needed if the state is something like "on-hold".) 303 4.4. Call Pull 305 Consider now that IP phone B wishes to take over the call. This is 306 called "call pull". 308 To do that, it performs a client migration. It POSTS to the call URI 309 its own handler. The server sees that this new handler supports 310 G.729, so it returns a directive to the client telling it to send 311 with G.729. Device A would receive a notification on the signaling 312 byway that the handler has changed to device B, and thus it knows 313 that a migration has happened and it should close its media byway. 314 (NOTE: need to consider race conditions). 316 4.5. Call Push 318 In the push case, the user on device A wishes to move the call to 319 device B. The user is in front of device A, and not device B. To 320 perform the move, it uses its UI, obtains the list of devices which 321 are available from the server, and asks the server to move the call 322 to device B. The means by which this happens are not standardized 323 here, and assume the existence of a browser function in the client 324 which can render the UI for features such as this. 326 When the server wants to move the call to device B, it sends it a 327 push on the push channel and tells it to take the call, along with 328 the call URI. Device B then performs the client migration, 329 identically to the pull case above. 331 4.6. Select Device 333 As part of the call push operation, the user on device A will need to 334 obtain the list of devices to which it can push the call. This 335 specification assumes that this is provided through non-standardized 336 means, by virtue of the phone having a browser which allows it to see 337 the set of devices and select one. 339 4.7. Third Party Call Control - Place Outbound 341 In a similar way, this specification allows a device to be controlled 342 by third party call control. A user would visit a web page, enter in 343 a number to call, and click the "call" button. This capability does 344 not require standardization. The RIPT server would create an 345 outbound call object, and then perform a push notification to both 346 devices with the call URI. Both devices would query the call URI, 347 and see that there is a new call happening, in the outbound 348 direction, with the state of proceeding. The call state would also 349 indicate the caller (here, user Alice herself) and the called party - 350 the number dialed by Alice. 352 Both phones could alert Alice to the outbound call in progress. When 353 Alice selets the device on which to proceed, this would cause that 354 device to perform a POST to the call URI to set itself as the 355 handler, and then establish media and signaling byways. This would 356 also trigger the server to actually place the call towards the 357 destination. 359 This technique for third party call control is superior to the one 360 described in [RFC3725]. Firstly, the calling and called party 361 numbers are properly represented and will render correctly on the 362 devices. This is because we're not actually placing a call towards 363 ALice's phone - we're informing Alice of an outbound call placed from 364 another location. Secondly, the technique allows the phone to render 365 proper UI - that this is not an inbound call, that it is an outbound 366 call to be taken. Call progress can also be properly rendered, 367 including locally generated ringback. 369 In this use case, the outbound call was picked up by Alice by 370 'forking' the outbound call notification to all of her devices. The 371 service provider could, alternatively, allow Alice to choose a 372 specific device for placing the outbound call. In that case, the 373 server would send an indication to just that device, over the push 374 channel, telling it to connect to the call URI. 376 4.8. Third Party Call Control Answer or Decline Inbound 378 Another third party call control use case is that of an inbound call 379 which rings user devices, and a user would like to accept the call 380 from a webpage or other client, distinct from the device on which the 381 call is to actually be answered. 383 This capability is not possible with the mechanism defined in 384 [RFC3725]. 386 This is possible with RIPT. The webpage would render the incoming 387 call notification to the user (again, no standardization is needed 388 for this, it is all just a browser application). The user would see 389 information on the incoming caller, select the device on which to 390 answer, and then hit an answer button. The server would then send a 391 push notification to the selceted device, with an instruction to 392 answer the call. The IP phone would then perform the POST operation 393 to the call URI, including its handler in the body, and accept the 394 call with the "answered" event. 396 4.9. Third Party Call Control Hangup 398 To hangup the call, once again Alice is in front of her browser, and 399 is able to see the call in the browser UI, and see that the call is 400 being handled by device A. Alice clicks the 'hangup' button on her 401 browser. The server changes the state of the call by sending an 402 "ended" event to all devices which have a signaling byway open 403 (which, in this case, would be both devices A and B). Device A would 404 cease rendering media and disconnect its signaling and media byways 405 for the call. Device B, which had remote-in-use, would remove the 406 remote-in-use indication from the UI. 408 TODO: should add meta-data to the ended event, indicating who ended 409 the event, to drive better UI and also deal with call drops 411 4.10. Third Party Call Control Move Call 413 In this use case, Alice is once again at her PC on her browser. She 414 is on a call which is rendering media on device A, and wishes to move 415 the call to device B. Using the browser UI, she instructs the server 416 to do so. The server would send a push notification to device B, 417 asking it to take the call. Device B would then POST its handler to 418 the call URI, open the media byways, and take the call, identically 419 to the pull use case above. 421 4.11. Resiliency Miss Incoming call 423 Consider now user Alice that has a mobile app with a RIPT client in 424 it. Alice was driving in her car. At the very moment the server 425 sends a push notification, Alice's device loses network coverage and 426 the push notification is lost. 428 When Alice exits the tunnel a few moments later, the application gets 429 notified that network connectivity has ben restored (note: i dont 430 believe this is actually provided in mobile OS today, it would 431 require a change perhaps to enable it). The application can then 432 perform a query to the server to get its current calls, using 433 techniques outside of the scope of this spceification. Once it 434 learns the call URI, it can query the call state and then render the 435 call as alerting. 437 4.12. Resiliency MidCall Network Change 439 Consider a case where user Alice is on her mobile device, and on a 440 call. While she is on the call, she moves from her cellular network 441 into her home, and her device switches to WiFi. 443 When this happens, the VoIP application on the mobile device receives 444 a notification from the OS that there has been a network change. 445 Note that - since RIPT doesnt use IP addresses at all - there is no 446 need to 're-REGISTER', or in fact to 're-INVITE'. The client just 447 continues doing what it was doing - performing GETs on /media to 448 receive media packets, and PUTs on /media to send them. In fact, the 449 client need not even explicitly listen for network change events. It 450 just continues sending and receiving media as before. 452 The change in IP will cause the signaling byways to end. The client 453 just re-establises them and continues where it was. RIPT requires a 454 client and server to buffer a small amount of media for cases where 455 the media byways are temporarily disconnected. In cases where there 456 is no network connectivity during the transition, the buffered 457 packets are sent in a burst. In this way, there is no loss of media 458 through the transition. 460 4.13. Resiliency MidCall Wireless Fade and Recover 462 Consider a similar case, where user Alice is on her mobile device, 463 and on a call. While she is on the call, she moves into a tunnel, 464 and network connectivity is lost for a few seconds. 466 The PUT and GET requests against the server for the media byway will 467 fail, and the signaling byway will possibly timeout or return an 468 error. The IP phone just buffers the media content being spoken by 469 the user. Similarly, the server will be buffering the media it 470 receives. When the connection is restored, the media byways will be 471 re-established, and the server will quickly push the buffered media 472 to the client and vice-a-versa. This allows the call to continue, 473 with no loss of media, within the depths of the jitter buffer. 475 4.14. Resiliency MidCall Wireless Fade and Move 477 In a similar use case, Alice is on her mobile phone in a call and 478 goes to her house. She is one of those unfortunate few who have no 479 cell signal in her house, nor does she have WiFi on her cell phone. 480 Poor Alice. 482 When Alice enters her home, the network connectivity on her mobile 483 phone is lost. However, her PC is up and running, so she logs into 484 her service provider's portal from the browser. This shows the call 485 in progress. Alice can hit the "move" button, which will cause the 486 browser to take the call, identically to the technqiues described 487 above. 489 4.15. Resiliency MidCall Wireless Fade and Peer Hangup 491 In this case, Alice is once again on her mobile device and enters an 492 area where there is no coverage for a long distance. As such, her 493 device is unable to send and receive media for many seconds. The 494 server is able to detect this, and can inform the remote user that 495 Alice has lost network connectivity (open question: should this be 496 done via ripp or through proprietary means?). The remote user gives 497 up and some point and hangs up the call. Alice's server ends the 498 call. 500 When Alice's phone finally regains network connectivity, it connects 501 to the call URI and gets a 404. This tells the device that the call 502 no longer exists, and so Alice's phone indicates to Alice that the 503 call has been ended (todo: should we keep the call state around in 504 the 'ended' state for an hour or so, so that Alice's device can query 505 it later and learn that it was ended by the remote party through an 506 explicit hangup event, and also learn when) 508 4.16. Resiliency MidCall Wireless Fade and Server Drop 510 In this final use case, Alice enters an area where there is no 511 coverage for an extended period of time. The server quickly detects 512 that she is not connected (it ceases receiving media). After a 513 period of time, the server decices to end the call. It changes the 514 call state to ended, which is passed to the remote party. 516 When Alice's phone recovers and connects to the call, it gets a 404, 517 informing her that the call has ended. 519 5. Normative Protocol Specification 521 A server that supports inbound calls on its TG MUST include the 522 "inbound" element in its TG description. This MUST include the 523 allowed caller IDs in the "origins" element, and the allowed 524 destinations in the "destinations". 526 The server MUST allow the client to send a "proceeding", "alerting", 527 "answered", "declined", "failed", "noanswer" and "end" events, and 528 take the associated actions on the call. 530 A client that answers a call MUST perform a POST operation to the 531 call URI, and in the body of the request, it MUST include its handler 532 URI, and no other information. The server MUST respond with a 533 directive. If the directive works for the client, the client MUST 534 generate an 'answered' event to answer the call. The client MUST NOT 535 POST its handler to the call URI until the user indicates that this 536 device should accept the call. 538 It MUST initiate signaling and media byways for the call, render 539 incoming media and generate outgoing media for the call. 541 6. Syntax 543 This specification outlines the syntax for the new events and TG 544 description. 546 7. IANA Considerations 548 No values are assigned in this document, no registries are created, 549 and there is no action assigned to the IANA by this document. 551 8. Security Considerations 553 TODO 555 9. Acknowledgements 557 Thanks to Cullen Jennings for his input on this document. 559 10. References 560 10.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, 564 DOI 10.17487/RFC2119, March 1997, 565 . 567 10.2. Informative References 569 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 570 A., Peterson, J., Sparks, R., Handley, M., and E. 571 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 572 DOI 10.17487/RFC3261, June 2002, 573 . 575 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 576 Camarillo, "Best Current Practices for Third Party Call 577 Control (3pcc) in the Session Initiation Protocol (SIP)", 578 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 579 . 581 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 582 "Managing Client-Initiated Connections in the Session 583 Initiation Protocol (SIP)", RFC 5626, 584 DOI 10.17487/RFC5626, October 2009, 585 . 587 Author's Address 589 Jonathan Rosenberg 590 Five9 592 Email: jdrosen@jdrosen.net