idnits 2.17.1 draft-ietf-sip-outbound-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC3327, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2009) is 5428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1901, but not defined ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-09 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 3261,3327 R. Mahy, Ed. 5 (if approved) Unaffiliated 6 Intended status: Standards Track June 9, 2009 7 Expires: December 11, 2009 9 Managing Client Initiated Connections in the Session Initiation Protocol 10 (SIP) 11 draft-ietf-sip-outbound-20 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on December 11, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 The Session Initiation Protocol (SIP) allows proxy servers to 60 initiate TCP connections or to send asynchronous UDP datagrams to 61 User Agents in order to deliver requests. However, in a large number 62 of real deployments, many practical considerations, such as the 63 existence of firewalls and Network Address Translators (NATs) or the 64 use of TLS with server-provided certificates, prevent servers from 65 connecting to User Agents in this way. This specification defines 66 behaviors for User Agents, registrars and proxy servers that allow 67 requests to be delivered on existing connections established by the 68 User Agent. It also defines keep alive behaviors needed to keep NAT 69 bindings open and specifies the usage of multiple connections from 70 the User Agent to its Registrar. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 76 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 7 79 3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 7 80 3.3. Multiple Connections from a User Agent . . . . . . . . . . 9 81 3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.5. Keep alive Technique . . . . . . . . . . . . . . . . . . . 12 83 3.5.1. CRLF Keep alive Technique . . . . . . . . . . . . . . 13 84 3.5.2. STUN Keep alive Technique . . . . . . . . . . . . . . 13 85 4. User Agent Procedures . . . . . . . . . . . . . . . . . . . . 13 86 4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13 87 4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 88 4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 15 89 4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 17 90 4.2.3. Third Party Registrations . . . . . . . . . . . . . . 17 91 4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 17 92 4.4. Keep alives and Detecting Flow Failure . . . . . . . . . . 18 93 4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 20 94 4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 21 95 4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 22 96 5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 23 97 5.1. Processing Register Requests . . . . . . . . . . . . . . . 23 98 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 23 99 5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 24 100 5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 24 101 5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 25 102 5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . . 25 103 6. Registrar Procedures . . . . . . . . . . . . . . . . . . . . . 25 104 7. Authoritative Proxy Procedures: Forwarding Requests . . . . . 27 105 8. STUN Keep alive Processing . . . . . . . . . . . . . . . . . . 28 106 8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . . 30 107 9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 30 108 9.1. Subscription to configuration package . . . . . . . . . . 30 109 9.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 32 110 9.3. Incoming call and proxy crash . . . . . . . . . . . . . . 35 111 9.4. Re-registration . . . . . . . . . . . . . . . . . . . . . 38 112 9.5. Outgoing call . . . . . . . . . . . . . . . . . . . . . . 38 113 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 115 11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 40 116 11.2. 'reg-id' Contact Header Field Parameter . . . . . . . . . 40 117 11.3. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 41 118 11.4. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 41 119 11.5. 430 (Flow Failed) Response Code . . . . . . . . . . . . . 41 120 11.6. 439 (First Hop Lacks Outbound Support) Response Code . . . 42 121 11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 42 122 12. Security Considerations . . . . . . . . . . . . . . . . . . . 43 123 13. Operational Notes on Transports . . . . . . . . . . . . . . . 44 124 14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 45 125 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 126 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 127 16.1. Normative References . . . . . . . . . . . . . . . . . . . 46 128 16.2. Informational References . . . . . . . . . . . . . . . . . 47 129 Appendix A. Default Flow Registration Backoff Times . . . . . . . 48 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 132 1. Introduction 134 There are many environments for SIP [RFC3261] deployments in which 135 the User Agent (UA) can form a connection to a Registrar or Proxy but 136 in which connections in the reverse direction to the UA are not 137 possible. This can happen for several reasons, but the most likely 138 is a NAT or a firewall in between the SIP UA and the proxy. Many 139 such devices will only allow outgoing connections. This 140 specification allows a SIP User Agent behind such a firewall or NAT 141 to receive inbound traffic associated with registrations or dialogs 142 that it initiates. 144 Most IP phones and personal computers get their network 145 configurations dynamically via a protocol such as Dynamic Host 146 Configuration Protocol (DHCP) [RFC2131]. These systems typically do 147 not have a useful name in the Domain Name System (DNS) [RFC1035], and 148 they almost never have a long-term, stable DNS name that is 149 appropriate for use in the subjectAltName of a certificate, as 150 required by [RFC3261]. However, these systems can still act as a 151 Transport Layer Security (TLS) [RFC5246] client and form outbound 152 connections to a proxy or registrar which authenticates with a server 153 certificate. The server can authenticate the UA using a shared 154 secret in a digest challenge (as defined in Section 22 of RFC 3261) 155 over that TLS connection. This specification allows a SIP User Agent 156 who has to initiate the TLS connection to receive inbound traffic 157 associated with registrations or dialogs that it initiates. 159 The key idea of this specification is that when a UA sends a REGISTER 160 request or a dialog-forming request, the proxy can later use this 161 same network "flow"--whether this is a bidirectional stream of UDP 162 datagrams, a TCP connection, or an analogous concept in another 163 transport protocol--to forward any incoming requests that need to go 164 to this UA in the context of the registration or dialog. 166 For a UA to receive incoming requests, the UA has to connect to a 167 server. Since the server can't connect to the UA, the UA has to make 168 sure that a flow is always active. This requires the UA to detect 169 when a flow fails. Since such detection takes time and leaves a 170 window of opportunity for missed incoming requests, this mechanism 171 allows the UA to register over multiple flows at the same time. This 172 specification also defines two keep alive schemes. The keep alive 173 mechanism is used to keep NAT bindings fresh, and to allow the UA to 174 detect when a flow has failed. 176 2. Conventions and Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2.1. Definitions 184 Authoritative Proxy: A proxy that handles non-REGISTER requests for 185 a specific Address-of-Record (AOR), performs the logical Location 186 Server lookup described in [RFC3261], and forwards those requests 187 to specific Contact URIs. (In [RFC3261], the role which is 188 authoritative for REGISTER requests for a specific AOR is a 189 Registration Server.) 190 Edge Proxy: An Edge Proxy is any proxy that is located topologically 191 between the registering User Agent and the Authoritative Proxy. 192 The "first" edge proxy refers to the first edge proxy encountered 193 when a UA sends a request. 194 Flow: A Flow is a network transport layer association between two 195 hosts that is represented by the network address and port number 196 of both ends and by the transport protocol. For TCP, a flow is 197 equivalent to a TCP connection. For UDP a flow is a bidirectional 198 stream of datagrams between a single pair of IP addresses and 199 ports of both peers. With TCP, a flow often has a one to one 200 correspondence with a single file descriptor in the operating 201 system. 202 Flow Token: An identifier which uniquely identifies a flow which can 203 be included in a SIP URI (Uniform Resource Identifier [RFC3986]). 204 reg-id: This refers to the value of a new header field parameter 205 value for the Contact header field. When a UA registers multiple 206 times, each for a different flow, each concurrent registration 207 gets a unique reg-id value. 208 instance-id: This specification uses the word instance-id to refer 209 to the value of the "sip.instance" media feature tag in the 210 Contact header field. This is a Uniform Resource Name (URN) that 211 uniquely identifies this specific UA instance. 212 ob Parameter: The 'ob' parameter is a SIP URI parameter which has 213 different meaning depending on context. In a Path header field 214 value it is used by the first edge proxy to indicate that a flow 215 token was added to the URI. In a Contact or Route header field 216 value it indicates that the UA would like other requests in the 217 same dialog routed over the same flow. 218 outbound-proxy-set: A set of SIP URIs (Uniform Resource Identifiers) 219 that represents each of the outbound proxies (often Edge Proxies) 220 with which the UA will attempt to maintain a direct flow. The 221 first URI in the set is often referred to as the primary outbound 222 proxy and the second as the secondary outbound proxy. There is no 223 difference between any of the URIs in this set, nor does the 224 primary/secondary terminology imply that one is preferred over the 225 other. 227 3. Overview 229 The mechanisms defined in this document are useful in several 230 scenarios discussed below, including the simple co-located registrar 231 and proxy, a User Agent desiring multiple connections to a resource 232 (for redundancy, for example), and a system that uses Edge Proxies. 234 This entire section is non-normative. 236 3.1. Summary of Mechanism 238 Each UA has a unique instance-id that stays the same for this UA even 239 if the UA reboots or is power cycled. Each UA can register multiple 240 times over different flows for the same SIP Address of Record (AOR) 241 to achieve high reliability. Each registration includes the 242 instance-id for the UA and a reg-id label that is different for each 243 flow. The registrar can use the instance-id to recognize that two 244 different registrations both correspond to the same UA. The 245 registrar can use the reg-id label to recognize whether a UA is 246 creating a new flow or refreshing or replacing an old one, possibly 247 after a reboot or a network failure. 249 When a proxy goes to route a message to a UA for which it has a 250 binding, it can use any one of the flows on which a successful 251 registration has been completed. A failure to deliver a request on a 252 particular flow can be tried again on an alternate flow. Proxies can 253 determine which flows go to the same UA by comparing the instance-id. 254 Proxies can tell that a flow replaces a previously abandoned flow by 255 looking at the reg-id. 257 When sending a dialog-forming request, a UA can also ask its first 258 edge proxy to route subsequent requests in that dialog over the same 259 flow. This is necessary whether the UA has registered or not. 261 UAs use a simple periodic message as a keep alive mechanism to keep 262 their flow to the proxy or registrar alive. For connection oriented 263 transports such as TCP this is based on carriage-return and line-feed 264 sequences (CRLF), while for transports that are not connection 265 oriented this is accomplished by using a SIP-specific usage profile 266 of STUN (Session Traversal Utilities for NAT) [RFC5389]. 268 3.2. Single Registrar and UA 270 In the topology shown below, a single server is acting as both a 271 registrar and proxy. 273 +-----------+ 274 | Registrar | 275 | Proxy | 276 +-----+-----+ 277 | 278 | 279 +----+--+ 280 | User | 281 | Agent | 282 +-------+ 284 User Agents which form only a single flow continue to register 285 normally but include the instance-id as described in Section 4.1. 286 The UA also includes a reg-id Contact header field which is used to 287 allow the registrar to detect and avoid keeping invalid contacts when 288 a UA reboots or reconnects after its old connection has failed for 289 some reason. 291 For clarity, here is an example. Bob's UA creates a new TCP flow to 292 the registrar and sends the following REGISTER request. 294 REGISTER sip:example.com SIP/2.0 295 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036 296 Max-Forwards: 70 297 From: Bob ;tag=d879h76 298 To: Bob 299 Call-ID: 8921348ju72je840.204 300 CSeq: 1 REGISTER 301 Supported: path, outbound 302 Contact: ; reg-id=1; 303 ;+sip.instance="" 304 Content-Length: 0 306 The registrar challenges this registration to authenticate Bob. When 307 the registrar adds an entry for this contact under the AOR for Bob, 308 the registrar also keeps track of the connection over which it 309 received this registration. 311 The registrar saves the instance-id 312 ("urn:uuid:00000000-0000-1000-8000-000A95A0E128") and reg-id ("1") 313 along with the rest of the Contact header field. If the instance-id 314 and reg-id are the same as a previous registration for the same AOR, 315 the registrar replaces the old Contact URI and flow information. 316 This allows a UA that has rebooted to replace its previous 317 registration for each flow with minimal impact on overall system 318 load. 320 When Alice sends a request to Bob, his authoritative proxy selects 321 the target set. The proxy forwards the request to elements in the 322 target set based on the proxy's policy. The proxy looks at the 323 target set and uses the instance-id to understand if two targets both 324 end up routing to the same UA. When the proxy goes to forward a 325 request to a given target, it looks and finds the flows over which it 326 received the registration. The proxy then forwards the request over 327 an existing flow, instead of resolving the Contact URI using the 328 procedures in [RFC3263] and trying to form a new flow to that 329 contact. 331 As described in the next section, if the proxy has multiple flows 332 that all go to this UA, the proxy can choose any one of the 333 registration bindings for this AOR that has the same instance-id as 334 the selected UA. 336 3.3. Multiple Connections from a User Agent 338 There are various ways to deploy SIP to build a reliable and scalable 339 system. This section discusses one such design that is possible with 340 the mechanisms in this specification. Other designs are also 341 possible. 343 In the example system below, the logical outbound proxy/registrar for 344 the domain is running on two hosts that share the appropriate state 345 and can both provide registrar and outbound proxy functionality for 346 the domain. The UA will form connections to two of the physical 347 hosts that can perform the authoritative proxy/registrar function for 348 the domain. Reliability is achieved by having the UA form two TCP 349 connections to the domain. 351 +-------------------+ 352 | Domain | 353 | Logical Proxy/Reg | 354 | | 355 |+-----+ +-----+| 356 ||Host1| |Host2|| 357 |+-----+ +-----+| 358 +---\------------/--+ 359 \ / 360 \ / 361 \ / 362 \ / 363 +------+ 364 | User | 365 | Agent| 366 +------+ 368 The UA is configured with multiple outbound proxy registration URIs. 370 These URIs are configured into the UA through whatever the normal 371 mechanism is to configure the proxy address and AOR in the UA. If 372 the AOR is alice@example.com, the outbound-proxy-set might look 373 something like "sip:primary.example.com" and "sip: 374 secondary.example.com". Note that each URI in the outbound-proxy-set 375 could resolve to several different physical hosts. The 376 administrative domain that created these URIs should ensure that the 377 two URIs resolve to separate hosts. These URIs are handled according 378 to normal SIP processing rules, so mechanisms like DNS SRV [RFC2782] 379 can be used to do load balancing across a proxy farm. The approach 380 in this document does not prevent future extensions, such as the SIP 381 UA configuration framework [I-D.ietf-sipping-config-framework], from 382 adding other ways for a User Agent to discover its outbound-proxy- 383 set. 385 The domain also needs to ensure that a request for the UA sent to 386 host1 or host2 is then sent across the appropriate flow to the UA. 387 The domain might choose to use the Path header approach (as described 388 in the next section) to store this internal routing information on 389 host1 or host2. 391 When a single server fails, all the UAs that have a flow through it 392 will detect a flow failure and try to reconnect. This can cause 393 large loads on the server. When large numbers of hosts reconnect 394 nearly simultaneously, this is referred to as the avalanche restart 395 problem, and is further discussed in Section 4.5. The multiple flows 396 to many servers help reduce the load caused by the avalanche restart. 397 If a UA has multiple flows, and one of the servers fails, the UA 398 delays a recommended amount of time before trying to form a new 399 connection to replace the flow to the server that failed. By 400 spreading out the time used for all the UAs to reconnect to a server, 401 the load on the server farm is reduced. 403 Scalability is achieved by using DNS SRV [RFC2782] to load balance 404 the primary connection across a set of machines that can service the 405 primary connection, and also using DNS SRV to load balance across a 406 separate set of machines that can service the secondary connection. 407 The deployment here requires that DNS is configured with one entry 408 that resolves to all the primary hosts and another entry that 409 resolves to all the secondary hosts. While this introduces 410 additional DNS configuration, the approach works and requires no 411 additional SIP extensions to [RFC3263]. 413 Another motivation for maintaining multiple flows between the UA and 414 its registrar is related to multihomed UAs. Such UAs can benefit 415 from multiple connections from different interfaces to protect 416 against the failure of an individual access link. 418 3.4. Edge Proxies 420 Some SIP deployments use edge proxies such that the UA sends the 421 REGISTER to an Edge Proxy that then forwards the REGISTER to the 422 Registrar. There could be a NAT or firewall between the UA and the 423 Edge Proxy. 425 +---------+ 426 |Registrar| 427 |Proxy | 428 +---------+ 429 / \ 430 / \ 431 / \ 432 +-----+ +-----+ 433 |Edge1| |Edge2| 434 +-----+ +-----+ 435 \ / 436 \ / 437 ----------------------------NAT/FW 438 \ / 439 \ / 440 +------+ 441 |User | 442 |Agent | 443 +------+ 445 The Edge Proxy includes a Path header [RFC3327] so that when the 446 proxy/registrar later forwards a request to this UA, the request is 447 routed through the Edge Proxy. 449 These systems can use effectively the same mechanism as described in 450 the previous sections but need to use the Path header. When the Edge 451 Proxy receives a registration, it needs to create an identifier value 452 that is unique to this flow (and not a subsequent flow with the same 453 addresses) and put this identifier in the Path header URI. This 454 identifier has two purposes. First, it allows the Edge Proxy to map 455 future requests back to the correct flow. Second, because the 456 identifier will only be returned if the user authenticates with the 457 registrar successfully, it allows the Edge Proxy to indirectly check 458 the user's authentication information via the registrar. The 459 identifier is placed in the user portion of a loose route in the Path 460 header. If the registration succeeds, the Edge Proxy needs to map 461 future requests that are routed to the identifier value from the Path 462 header, to the associated flow. 464 The term Edge Proxy is often used to refer to deployments where the 465 Edge Proxy is in the same administrative domain as the Registrar. 467 However, in this specification we use the term to refer to any proxy 468 between the UA and the Registrar. For example the Edge Proxy may be 469 inside an enterprise that requires its use and the registrar could be 470 from a service provider with no relationship to the enterprise. 471 Regardless if they are in the same administrative domain, this 472 specification requires that Registrars and Edge proxies support the 473 Path header mechanism in [RFC3327]. 475 3.5. Keep alive Technique 477 This document describes two keep alive mechanisms: a CRLF keep alive 478 and a STUN keep alive. Each of these mechanisms uses a client-to- 479 server "ping" keep alive and a corresponding server-to-client "pong" 480 message. This ping-pong sequence allows the client, and optionally 481 the server, to tell if its flow is still active and useful for SIP 482 traffic. The server responds to pings by sending pongs. If the 483 client does not receive a pong in response to its ping (allowing for 484 retransmission for STUN as described in Section 4.4.2), it declares 485 the flow dead and opens a new flow in its place. 487 This document also suggests timer values for these client keep alive 488 mechanisms. These timer values were chosen to keep most NAT and 489 firewall bindings open, to detect unresponsive servers within 2 490 minutes, and to mitigate against the avalanche restart problem. 491 However, the client may choose different timer values to suit its 492 needs, for example to optimize battery life. In some environments, 493 the server can also keep track of the time since a ping was received 494 over a flow to guess the likelihood that the flow is still useful for 495 delivering SIP messages. 497 When the UA detects that a flow has failed or that the flow 498 definition has changed, the UA needs to re-register and will use the 499 back-off mechanism described in Section 4.5 to provide congestion 500 relief when a large number of agents simultaneously reboot. 502 A keep alive mechanism needs to keep NAT bindings refreshed; for 503 connections, it also needs to detect failure of a connection; and for 504 connectionless transports, it needs to detect flow failures including 505 changes to the NAT public mapping. For connection oriented 506 transports such as TCP [RFC0793] and SCTP [RFC4960], this 507 specification describes a keep alive approach based on sending CRLFs. 508 For connectionless transport, such as UDP [RFC0768], this 509 specification describes using STUN [RFC5389] over the same flow as 510 the SIP traffic to perform the keep alive. 512 UAs and Proxies are also free to use native transport keep alives, 513 however the application may not be able to set these timers on a per- 514 connection basis, and the server certainly cannot make any assumption 515 about what values are used. Use of native transport keep alives is 516 outside the scope of this document. 518 3.5.1. CRLF Keep alive Technique 520 This approach can only be used with connection-oriented transports 521 such as TCP or SCTP. The client periodically sends a double-CRLF 522 (the "ping") then waits to receive a single CRLF (the "pong"). If 523 the client does not receive a "pong" within an appropriate amount of 524 time, it considers the flow failed. 526 Note: Sending a CRLF over a connection-oriented transport is 527 backwards compatible (because of requirements in Section 7.5 of 528 [RFC3261]), but only implementations which support this 529 specification will respond to a "ping" with a "pong". 531 3.5.2. STUN Keep alive Technique 533 This approach can only be used for connection-less transports, such 534 as UDP. 536 For connection-less transports, a flow definition could change 537 because a NAT device in the network path reboots and the resulting 538 public IP address or port mapping for the UA changes. To detect 539 this, STUN requests are sent over the same flow that is being used 540 for the SIP traffic. The proxy or registrar acts as a limited 541 Session Traversal Utilities for NAT (STUN) [RFC5389] server on the 542 SIP signaling port. 544 Note: The STUN mechanism is very robust and allows the detection 545 of a changed IP address and port. Many other options were 546 considered, but the SIP Working Group selected the STUN-based 547 approach. Approaches using SIP requests were abandoned because 548 many believed that good performance and full backwards 549 compatibility using this method were mutually exclusive. 551 4. User Agent Procedures 553 4.1. Instance ID Creation 555 Each UA MUST have an Instance Identifier Uniform Resource Name (URN) 556 [RFC2141] that uniquely identifies the device. Usage of a URN 557 provides a persistent and unique name for the UA instance. It also 558 provides an easy way to guarantee uniqueness within the AOR. This 559 URN MUST be persistent across power cycles of the device. The 560 Instance ID MUST NOT change as the device moves from one network to 561 another. 563 A UA SHOULD create a UUID URN [RFC4122] as its instance-id. The UUID 564 URN allows for non-centralized computation of a URN based on time, 565 unique names (such as a MAC address), or a random number generator. 567 Note: A device like a soft-phone, when first installed, can 568 generate a UUID [RFC4122] and then save this in persistent storage 569 for all future use. For a device such as a hard phone, which will 570 only ever have a single SIP UA present, the UUID can include the 571 MAC address and be generated at any time because it is guaranteed 572 that no other UUID is being generated at the same time on that 573 physical device. This means the value of the time component of 574 the UUID can be arbitrarily selected to be any time less than the 575 time when the device was manufactured. A time of 0 (as shown in 576 the example in Section 3.2) is perfectly legal as long as the 577 device knows no other UUIDs were generated at this time on this 578 device. 580 If a URN scheme other than UUID is used, the UA MUST only use URNs 581 for which an IETF RFC defines how the specific URN needs to be 582 constructed and used in the sip.instance Contact parameter for 583 outbound behavior. 585 To convey its instance-id in both requests and responses, the UA 586 includes a "sip.instance" media feature tag as a UA characteristic 587 [RFC3840]. This media feature tag is encoded in the Contact header 588 field as the "+sip.instance" Contact header field parameter. One 589 case where a UA could prefer to omit the sip.instance media feature 590 tag is when it is making an anonymous request or some other privacy 591 concern requires that the UA not reveal its identity. 593 Note: [RFC3840] defines equality rules for callee capabilities 594 parameters, and according to that specification, the 595 "sip.instance" media feature tag will be compared by case- 596 sensitive string comparison. This means that the URN will be 597 encapsulated by angle brackets ("<" and ">") when it is placed 598 within the quoted string value of the +sip.instance Contact header 599 field parameter. The case-sensitive matching rules apply only to 600 the generic usages defined in the callee capabilities [RFC3840] 601 and the caller preferences [RFC3841] specifications. When the 602 instance ID is used in this specification, it is "extracted" from 603 the value in the "sip.instance" media feature tag. Thus, equality 604 comparisons are performed using the rules for URN equality that 605 are specific to the scheme in the URN. If the element performing 606 the comparisons does not understand the URN scheme, it performs 607 the comparisons using the lexical equality rules defined in 608 [RFC2141]. Lexical equality could result in two URNs being 609 considered unequal when they are actually equal. In this specific 610 usage of URNs, the only element which provides the URN is the SIP 611 UA instance identified by that URN. As a result, the UA instance 612 has to provide lexically equivalent URNs in each registration it 613 generates. This is likely to be normal behavior in any case; 614 clients are not likely to modify the value of the instance ID so 615 that it remains functionally equivalent yet lexicographically 616 different from previous registrations. 618 4.2. Registrations 620 4.2.1. Initial Registrations 622 At configuration time, UAs obtain one or more SIP URIs representing 623 the default outbound-proxy-set. This specification assumes the set 624 is determined via any of a number of configuration mechanisms, and 625 future specifications can define additional mechanisms such as using 626 DNS to discover this set. How the UA is configured is outside the 627 scope of this specification. However, a UA MUST support sets with at 628 least two outbound proxy URIs and SHOULD support sets with up to four 629 URIs. 631 For each outbound proxy URI in the set, the UAC SHOULD send a 632 REGISTER request using this URI as the default outbound proxy. 633 (Alternatively, the UA could limit the number of flows formed to 634 conserve battery power, for example). If the set has more than one 635 URI, the UAC MUST send a REGISTER request to at least two of the 636 default outbound proxies from the set. UAs that support this 637 specification MUST include the outbound option tag in a Supported 638 header field in a REGISTER request. Each of these REGISTER requests 639 will use a unique Call-ID. Forming the route set for the request is 640 outside the scope of this document, but typically results in sending 641 the REGISTER such that the topmost Route header field contains a 642 loose route to the outbound proxy URI. 644 REGISTER requests, other than those described in Section 4.2.3, MUST 645 include an instance-id media feature tag as specified in Section 4.1. 647 For registration requests in accordance to this specification, the UA 648 MUST include reg-id parameter in the Contact header field that is 649 distinct from other reg-id parameters used from the same 650 +sip.instance and AOR. Each one of these registrations will form a 651 new flow from the UA to the proxy. The sequence of reg-id values 652 does not have to be sequential but MUST be exactly the same sequence 653 of reg-id values each time the UA instance power cycles or reboots so 654 that the reg-id values will collide with the previously used reg-id 655 values. This is so the registrar can replace the older 656 registrations. 658 Note: The UAC can situationally decide whether to request 659 outbound behavior by including or omitting the reg-id Contact 660 header field parameter. For example, imagine the outbound-proxy- 661 set contains two proxies in different domains, EP1 and EP2. If an 662 outbound-style registration succeeded for a flow through EP1, the 663 UA might decide to include 'outbound' in its Require header field 664 when registering with EP2, in order to insure consistency. 665 Similarly, if the registration through EP1 did not support 666 outbound, the UA might not register with EP2 at all. 668 The UAC MUST support the Path header [RFC3327] mechanism, and 669 indicate its support by including the 'path' option-tag in a 670 Supported header field value in its REGISTER requests. Other than 671 optionally examining the Path vector in the response, this is all 672 that is required of the UAC to support Path. 674 The UAC examines successful registration responses for the presence 675 of an outbound option-tag in a Require header field value. Presence 676 of this option-tag indicates that the registrar is compliant with 677 this specification, and that any edge proxies which needed to 678 participate are also compliant. If the registrar did not support 679 outbound, the UA has potentially registered an un-routable contact. 680 It is the responsibility of the UA to remove any inappropriate 681 Contacts. 683 If outbound registration succeeded, as indicated by the presence of 684 the outbound option-tag in the Require header field of a successful 685 registration response, the UA begins sending keep alives as described 686 in Section 4.4. 688 Note: The UA needs to honor 503 (Service Unavailable) responses 689 to registrations as described in [RFC3261] and [RFC3263]. In 690 particular, implementors should note that when receiving a 503 691 (Service Unavailable) response with a Retry-After header field, 692 the UA is expected to wait the indicated amount of time and retry 693 the registration. A Retry-After header field value of 0 is valid 694 and indicates the UA is expected to retry the REGISTER request 695 immediately. Implementations need to ensure that when retrying 696 the REGISTER request, they revisit the DNS resolution results such 697 that the UA can select an alternate host from the one chosen the 698 previous time the URI was resolved. 700 If the registering UA receives a 439 (First Hop Lacks Outbound 701 Support) response to a REGISTER request, it MAY re-attempt 702 registration without using the outbound mechanism (subject to local 703 policy at the client). If the client has one or more alternate 704 outbound proxies available, it MAY re-attempt registration through 705 such outbound proxies. See Section 11.6 for more information on the 706 439 response code. 708 4.2.2. Subsequent REGISTER requests 710 Registrations for refreshing a binding and for removing a binding use 711 the same instance-id and reg-id values as the corresponding initial 712 registration where the binding was added. Registrations which merely 713 refresh an existing binding are sent over the same flow as the 714 original registration where the binding was added. 716 If a re-registration is rejected with a recoverable error response, 717 for example by a 503 (Service Unavailable) containing a Retry-After 718 header, the UAC SHOULD NOT tear down the corresponding flow if the 719 flow uses a connection-oriented transport such as TCP. As long as 720 "pongs" are received in response to "pings", the flow SHOULD be kept 721 active until a non-recoverable error response is received. This 722 prevents unnecessary closing and opening of connections. 724 4.2.3. Third Party Registrations 726 In an initial registration or re-registration, a UA MUST NOT include 727 a reg-id header parameter in the Contact header field if the 728 registering UA is not the same instance as the UA referred to by the 729 target Contact header field. (This practice is occasionally used to 730 install forwarding policy into registrars.) 732 A UAC also MUST NOT include an instance-id feature tag or reg-id 733 Contact header field parameter in a request to un-register all 734 Contacts (a single Contact header field value with the value of "*"). 736 4.3. Sending Non-REGISTER Requests 738 When a UAC is about to send a request, it first performs normal 739 processing to select the next hop URI. The UA can use a variety of 740 techniques to compute the route set and accordingly the next hop URI. 741 Discussion of these techniques is outside the scope of this document. 742 UAs that support this specification SHOULD include the outbound 743 option tag in a Supported header field in a request that is not a 744 REGISTER request. 746 The UAC performs normal DNS resolution on the next hop URI (as 747 described in [RFC3263]) to find a protocol, IP address, and port. 748 For protocols that don't use TLS, if the UAC has an existing flow to 749 this IP address, and port with the correct protocol, then the UAC 750 MUST use the existing connection. For TLS protocols, there MUST also 751 be a match between the host production in the next hop and one of the 752 URIs contained in the subjectAltName in the peer certificate. If the 753 UAC cannot use one of the existing flows, then it SHOULD form a new 754 flow by sending a datagram or opening a new connection to the next 755 hop, as appropriate for the transport protocol. 757 Typically, a UAC using the procedures of this document and sending a 758 dialog-forming request will want all subsequent requests in the 759 dialog to arrive over the same flow. If the UAC is using a GRUU 760 [I-D.ietf-sip-gruu] that was instantiated using a Contact header 761 field value that included an "ob" parameter, the UAC sends the 762 request over the flow used for registration and subsequent requests 763 will arrive over that same flow. If the UAC is not using such a 764 GRUU, then the UAC adds an "ob" parameter to its Contact header field 765 value. This will cause all subsequent requests in the dialog to 766 arrive over the flow instantiated by the dialog-forming request. 767 This case is typical when the request is sent prior to registration, 768 such as in the the initial subcription dialog for the configuration 769 framework [I-D.ietf-sipping-config-framework]. 771 Note: If the UAC wants a UDP flow to work through NATs or 772 firewalls it still needs to put the 'rport' parameter [RFC3581] in 773 its Via header field value, and send from the port it is prepared 774 to receive on. More general information about NAT traversal in 775 SIP is described in [I-D.ietf-sipping-nat-scenarios]. 777 4.4. Keep alives and Detecting Flow Failure 779 Keep alives are used for refreshing NAT/firewall bindings and 780 detecting flow failure. Flows can fail for many reasons including 781 NATs rebooting and Edge Proxies crashing. 783 As described in Section 4.2, a UA that registers will begin sending 784 keep alives after an appropriate registration response. A UA that 785 does not register (for example, a PSTN gateway behind a firewall) can 786 also send keep alives under certain circumstances. 788 Under specific circumstances, a UAC might be allowed to send STUN 789 keep alives even if the procedures in Section 4.2 were not completed, 790 provided that there is an explicit indication that the target first 791 hop SIP node supports STUN keep alives. This applies for example to 792 a non-registering UA or to a case where the UA registration 793 succeeded, but the response did not include the outbound option-tag 794 in the Require header field. 796 Note: A UA can "always" send a double CRLF (a "ping") over 797 connection-oriented transports as this is already allowed by 798 Section 7.5/[RFC3261], However a UA that did not register using 799 outbound registration cannot expect a CRLF in response (a "pong") 800 unless the UA has an explicit indication that CRLF keep alives are 801 supported as described in this section. Likewise, a UA that did 802 not successfully register with outbound procedures needs explicit 803 indication that the target first hop SIP node supports STUN keep 804 alives before it can send any STUN messages. 806 A configuration option indicating keep alive support for a specific 807 target is considered an explicit indication. If these conditions are 808 satisfied, the UA sends its keep alives according to the same 809 guidelines described in the rest of this section as UAs which 810 register. 812 The UA needs to detect when a specific flow fails. The UA actively 813 tries to detect failure by periodically sending keep alive messages 814 using one of the techniques described in Section 4.4.1 or 815 Section 4.4.2. If a flow with a registration has failed, the UA 816 follows the procedures in Section 4.2 to form a new flow to replace 817 the failed one. 819 When a successful registration response contains the Flow-Timer 820 header field, the value of this header field is the number of seconds 821 the server is prepared to wait without seeing keep alives before it 822 could consider the corresponding flow dead. Note that the server 823 would wait for an amount of time larger than the Flow-Timer in order 824 to have a grace period to account for transport delay. The UA MUST 825 send keep alives at least as often as this number of seconds. If the 826 UA uses the server recommended keep alive frequency it SHOULD send 827 its keep alives so that the interval between each keep alive is 828 randomly distributed between 80% and 100% of the server provided 829 time. For example, if the server suggests 120 seconds, the UA would 830 send each keep alive with a different frequency between 95 and 120 831 seconds. 833 If no Flow-Timer header field was present in a register response for 834 this flow, the UA can send keep alives at its discretion. The 835 sections below provide RECOMMENDED default values for these keep 836 alives. 838 The client needs to perform normal [RFC3263] SIP DNS resolution on 839 the URI from the outbound-proxy-set to pick a transport. Once a 840 transport is selected, the UA selects the keep alive approach that is 841 recommended for that transport. 843 Section Section 4.4.1 describes a keep alive mechanism for connection 844 oriented transports such as TCP or SCTP. Section Section 4.4.2 845 describes a keep alive mechanism for connection-less transports such 846 as UDP. Support for other transports such as DCCP [RFC4340] is for 847 further study. 849 4.4.1. Keep alive with CRLF 851 This approach MUST only be used with connection oriented transports 852 such as TCP or SCTP; it MUST NOT be used with connection-less 853 transports such as UDP. 855 A User Agent that forms flows, checks if the configured URI to which 856 the UA is connecting resolves to a connection-oriented transport (ex: 857 TCP and TLS over TCP). 859 For this mechanism, the client "ping" is a double-CRLF sequence, and 860 the server "pong" is a single CRLF, as defined in the ABNF below: 862 CRLF = CR LF 863 double-CRLF = CR LF CR LF 864 CR = 0x0d 865 LF = 0x0a 867 The ping and pong need to be sent between SIP messages and cannot be 868 sent in the middle of a SIP message. If sending over TLS, the CRLFs 869 are sent inside the TLS protected channel. If sending over a SigComp 870 [RFC3320] compressed data stream, the CRLF keep alives are sent 871 inside the compressed stream. The double CRLF is considered a single 872 SigComp message. The specific mechanism for representing these 873 characters is an implementation specific matter to be handled by the 874 SigComp compressor at the sending end. 876 If a pong is not received within 10 seconds after sending a ping (or 877 immediately after processing any incoming message being received when 878 that 10 seconds expires), then the client MUST treat the flow as 879 failed. Clients MUST support this CRLF keep alive. 881 Note: This value of 10 second timeout was selected to be long 882 enough that it allows plenty of time for a server to send a 883 response even if the server is temporarily busy with an 884 administrative activity. At the same time, it was selected to be 885 small enough that a UA registered to two redundant servers with 886 unremarkable hardware uptime could still easily provide very high 887 levels of overall reliability. Although some Internet protocols 888 are designed for round trip times over 10 seconds, SIP for real 889 time communications is not really usable in these type of 890 environments as users often abandon calls before waiting much more 891 than a few seconds. 893 When a Flow-Timer header field is not provided in the most recent 894 success registration response, the proper selection of keep alive 895 frequency is primarily a trade-off between battery usage and 896 availability. The UA MUST select a random number between a fixed or 897 configurable upper bound and a lower bound, where the lower bound is 898 20% less then the upper bound. The fixed upper bound or the default 899 configurable upper bound SHOULD be 120 seconds (95 seconds lower 900 bound) where battery power is not a concern and 840 seconds (672 901 seconds lower bound) where battery power is a concern. The random 902 number will be different for each keep alive ping. 904 Note on selection of time values: the 120 seconds upper bound was 905 chosen based on the idea that for a good user experience, failures 906 normally will be detected in this amount of time and a new 907 connection set up. The 14 minute upper-bound for battery-powered 908 devices was selected based on NATs with TCP timeouts as low as 15 909 minutes. Operators that wish to change the relationship between 910 load on servers and the expected time that a user might not 911 receive inbound communications will probably adjust this time. 912 The 95 seconds lower bound was chosen so that the jitter 913 introduced will result in a relatively even load on the servers 914 after 30 minutes. 916 4.4.2. Keep alive with STUN 918 This approach MUST only be used with connection-less transports, such 919 as UDP; it MUST NOT be used for connection oriented transports such 920 as TCP and SCTP. 922 A User Agent that forms flows, checks if the configured URI to which 923 the UA is connecting resolves to use the UDP transport. The UA can 924 periodically perform keep alive checks by sending STUN [RFC5389] 925 Binding Requests over the flow as described in Section 8. Clients 926 MUST support STUN based keep alives. 928 When a Flow-Timer header field is not included in a successful 929 registration response, the time between each keep alive request 930 SHOULD be a random number between 24 and 29 seconds. 932 Note on selection of time values: the upper bound of 29 seconds 933 was selected, as many NATs have UDP timeouts as low as 30 seconds. 934 The 24 second lower bound was selected so that after 10 minutes 935 the jitter introduced by different timers will make the keep alive 936 requests unsynchronized to evenly spread the load on the servers. 937 Note that the short NAT timeouts with UDP have a negative impact 938 on battery life. 940 If a STUN Binding Error Response is received, or if no Binding 941 Response is received after 7 retransmissions (16 times the STUN "RTO" 942 timer--RTO is an estimate of round-trip time), the UA considers the 943 flow failed. If the XOR-MAPPED-ADDRESS in the STUN Binding Response 944 changes, the UA MUST treat this event as a failure on the flow. 946 4.5. Flow Recovery 948 When a flow used for registration (through a particular URI in the 949 outbound-proxy-set) fails, the UA needs to form a new flow to replace 950 the old flow and replace any registrations that were previously sent 951 over this flow. Each new registration MUST have the same reg-id 952 value as the registration it replaces. This is done in much the same 953 way as forming a brand new flow as described in Section 4.2; however, 954 if there is a failure in forming this flow, the UA needs to wait a 955 certain amount of time before retrying to form a flow to this 956 particular next hop. 958 The amount of time to wait depends if the previous attempt at 959 establishing a flow was successful. For the purposes of this 960 section, a flow is considered successful if outbound registration 961 succeeded, and if keep alives are in use on this flow, at least one 962 subsequent keep alive response was received. 964 The number of seconds to wait is computed in the following way. If 965 all of the flows to every URI in the outbound proxy set have failed, 966 the base-time is set to a lower value (with a default of 30 seconds); 967 otherwise, in the case where at least one of the flows has not 968 failed, the base-time is set to a higher value (with a default of 90 969 seconds). The upper-bound wait time (W) is computed by taking two 970 raised to the power of the number of consecutive registration 971 failures for that URI, and multiplying this by the base time, up to a 972 configurable maximum time (with a default of 1800 seconds). 974 W = min( max-time, (base-time * (2 ^ consecutive-failures))) 976 These times MAY be configurable in the UA. The three times are: 977 o max-time with a default of 1800 seconds 978 o base-time (if all failed) with a default of 30 seconds 979 o base-time (if all have not failed) with a default of 90 seconds 981 For example, if the base time is 30 seconds, and there were three 982 failures, then the upper-bound wait time is min(1800,30*(2^3)) or 240 983 seconds. The actual amount of time the UA waits before retrying 984 registration (the retry delay time) is computed by selecting a 985 uniform random time between 50 and 100 percent of the upper-bound 986 wait time. The UA MUST wait for at least the value of the retry 987 delay time before trying another registration to form a new flow for 988 that URI (a 503 response to an earlier failed registration attempt 989 with a Retry-After header field value may cause the UA to wait 990 longer).. 992 To be explicitly clear on the boundary conditions: when the UA boots 993 it immediately tries to register. If this fails and no registration 994 on other flows succeed, the first retry happens somewhere between 30 995 and 60 seconds after the failure of the first registration request. 996 If the number of consecutive-failures is large enough that the 997 maximum of 1800 seconds is reached, the UA will keep trying 998 indefinitely with a random time of 15 to 30 minutes between each 999 attempt. 1001 5. Edge Proxy Procedures 1003 5.1. Processing Register Requests 1005 When an Edge Proxy receives a registration request with a reg-id 1006 header field parameter in the Contact header field, it needs to 1007 determine if it (the edge proxy) will have to be visited for any 1008 subsequent requests sent to the user agent identified in the Contact 1009 header field, or not. If the edge proxy is the first hop, as 1010 indicated by the Via header field, it MUST insert its URI in a Path 1011 header field value as described in [RFC3327]. If it is not the first 1012 hop, it might still decide to add itself to the Path header based on 1013 local policy. In addition, if the Edge Proxy is the first SIP node 1014 after the UAC, the edge proxy either MUST store a "flow token" 1015 (containing information about the flow from the previous hop) in its 1016 Path URI or reject the request. The flow token MUST be an identifier 1017 that is unique to this network flow. The flow token MAY be placed in 1018 the userpart of the URI. In addition, the first node MUST include an 1019 'ob' URI parameter in its Path header field value. If the Edge Proxy 1020 is not the first SIP node after the UAC it MUST NOT place an ob URI 1021 parameter in a Path header field value. The Edge Proxy can determine 1022 if it is the first hop by examining the Via header field. 1024 5.2. Generating Flow Tokens 1026 A trivial but impractical way to satisfy the flow token requirement 1027 in Section 5.1 involves storing a mapping between an incrementing 1028 counter and the connection information; however this would require 1029 the Edge Proxy to keep an infeasible amount of state. It is unclear 1030 when this state could be removed and the approach would have problems 1031 if the proxy crashed and lost the value of the counter. A stateless 1032 example is provided below. A proxy can use any algorithm it wants as 1033 long as the flow token is unique to a flow, the flow can be recovered 1034 from the token, and the token cannot be modified by attackers. 1036 Example Algorithm: When the proxy boots it selects a 20-octet 1037 crypto random key called K that only the Edge Proxy knows. A byte 1038 array, called S, is formed that contains the following information 1039 about the flow the request was received on: an enumeration 1040 indicating the protocol, the local IP address and port, the remote 1041 IP address and port. The HMAC of S is computed using the key K 1042 and the HMAC-SHA1-80 algorithm, as defined in [RFC2104]. The 1043 concatenation of the HMAC and S are base64 encoded, as defined in 1044 [RFC4648], and used as the flow identifier. When using IPv4 1045 addresses, this will result in a 32-octet identifier. 1047 5.3. Forwarding Non-REGISTER Requests 1049 When an Edge Proxy receives a request, it applies normal routing 1050 procedures with the following additions. If the Edge Proxy receives 1051 a request where the edge proxy is the host in the topmost Route 1052 header field value, and the Route header field value contains a flow 1053 token, the proxy follows the procedures of this section. Otherwise 1054 the edge proxy skips the procedures in this section, removes itself 1055 from the Route header field, and continues processing the request. 1057 The proxy decodes the flow token and compares the flow in the flow 1058 token with the source of the request to determine if this is an 1059 "incoming" or "outgoing" request. 1061 If the flow in the flow token identified by the topmost Route header 1062 field value matches the source IP address and port of the request, 1063 the request is an "outgoing" request, otherwise, it is an "incoming" 1064 request. 1066 5.3.1. Processing Incoming Requests 1068 If the Route header value contains an ob URI parameter, the Route 1069 header was probably copied from the Path header in a registration. 1070 If the Route header value contains an ob URI parameter, and the 1071 request is a new dialog-forming request, the proxy needs to adjust 1072 the route set to insure that subsequent requests in the dialog can be 1073 delivered over a valid flow to the UA instance identified by the flow 1074 token. 1076 Note: A simple approach to satisfy this requirement is for the 1077 proxy to add a Record-Route header field value that contains the 1078 flow-token, by copying the URI in the Route header minus the 'ob' 1079 parameter. 1081 Next, whether the Route header field contained an ob URI parameter or 1082 not, the proxy removes the Route header field value and forwards the 1083 request over the 'logical flow' identified by the flow token, that is 1084 known to deliver data to the specific target UA instance. If the 1085 flow token has been tampered with, the proxy SHOULD send a 403 1086 (Forbidden) response. If the flow no longer exists the proxy SHOULD 1087 send a 430 (Flow Failed) response to the request. 1089 Proxies which used the example algorithm described in Section 5.2 to 1090 form a flow token follow the procedures below to determine the 1091 correct flow. To decode the flow token, take the flow identifier in 1092 the user portion of the URI and base64 decode it, then verify the 1093 HMAC is correct by recomputing the HMAC and checking that it matches. 1094 If the HMAC is not correct, the request has been tampered with. 1096 5.3.2. Processing Outgoing Requests 1098 For mid-dialog requests to work with outbound UAs, the requests need 1099 to be forwarded over some valid flow to the appropriate UA instance. 1100 If the Edge Proxy receives an outgoing dialog-forming request, the 1101 Edge Proxy can use the presence of the ob URI parameter in the UAC's 1102 Contact URI (or topmost Route header field) to determine if the Edge 1103 Proxy needs to assist in mid-dialog request routing. 1105 Implementation note: Specific procedures at the edge proxy to 1106 ensure that mid-dialog requests are routed over an existing flow 1107 are not part of this specification. However, an approach such as 1108 having the Edge Proxy add a Record-Route header with a flow token 1109 is one way to ensure that mid-dialog requests are routed over the 1110 correct flow. 1112 5.4. Edge Proxy Keep alive Handling 1114 All edge proxies compliant with this specification MUST implement 1115 support for STUN NAT Keep alives on its SIP UDP ports as described in 1116 Section 8. 1118 When a server receives a double CRLF sequence between SIP messages on 1119 a connection oriented transport such as TCP or SCTP, it MUST 1120 immediately respond with a single CRLF over the same connection. 1122 The last proxy to forward a successful registration response to a UA 1123 MAY include a Flow-Timer header field if the response contains the 1124 outbound option-tag in a Require header field value in the response. 1125 The reason a proxy would send a Flow-Timer is if it wishes to detect 1126 flow failures proactively and take appropriate action (e.g., log 1127 alarms, provide alternative treatment if incoming requests for the UA 1128 are received, etc.). The server MUST wait for an amount of time 1129 larger than the Flow-Timer in order to have a grace period to account 1130 for transport delay. 1132 6. Registrar Procedures 1134 This specification updates the definition of a binding in [RFC3261] 1135 Section 10 and [RFC3327] Section 5.3. 1137 Registrars which implement this specification MUST support the Path 1138 header mechanism [RFC3327]. 1140 When receiving a REGISTER request, the registrar MUST check from its 1141 Via header field if the registrar is the first hop or not. If the 1142 registrar is not the first hop, it MUST examine the Path header of 1143 the request. If the Path header field is missing or it exists but 1144 the first URI does not have an ob URI parameter, then outbound 1145 processing MUST NOT be applied to the registration. In this case, 1146 the following processing applies: if the REGISTER request contains 1147 the reg-id and the outbound option tag in a Supported header field, 1148 then the registrar MUST respond to the REGISTER request with a 439 1149 (First Hop Lacks Outbound Support) response; otherwise, the registrar 1150 MUST ignore the reg-id parameter of the Contact header. See 1151 Section 11.6 for more information on the 439 response code. 1153 A Contact header field value with an instance-id media feature tag 1154 but no reg-id header field parameter is valid (this combination will 1155 result in the creation of a GRUU, as described in GRUU 1156 [I-D.ietf-sip-gruu] specification), but one with a reg-id but no 1157 instance-id is not. If the registrar processes a Contact header 1158 field value with a reg-id but no instance-id, it simply ignores the 1159 reg-id parameter. 1161 A registration containing a reg-id header field parameter and a non- 1162 zero expiration is used to register a single UA instance over a 1163 single flow, and can also de-register any Contact header fields with 1164 zero expiration. Therefore if the Contact header field contains more 1165 than one header field value with a non-zero expiration and any of 1166 these header field values contain a reg-id Contact header field 1167 parameter, the entire registration SHOULD be rejected with a 400 (Bad 1168 Request) response. The justification for recommending rejection 1169 versus making it mandatory is that the receiver is allowed by 1170 [RFC3261] to squelch (not respond to) excessively malformed or 1171 malicious messages. 1173 If the Contact header did not contain a reg-id Contact header field 1174 parameter or if that parameter was ignored (as described above) the 1175 registrar MUST NOT include the outbound option-tag in the Require 1176 header field of its response. 1178 The registrar MUST be prepared to receive, simultaneously for the 1179 same AOR, some registrations that use instance-id and reg-id and some 1180 registrations that do not. The Registrar MAY be configured with 1181 local policy to reject any registrations that do not include the 1182 instance-id and reg-id, or with Path header field values that do not 1183 contain the ob URI parameter. If the Contact header field does not 1184 contain a '+sip.instance' media feature parameter, the registrar 1185 processes the request using the Contact binding rules in [RFC3261]. 1187 When a '+sip.instance' media feature parameter and a reg-id Contact 1188 header field parameter are present in a Contact header field of a 1189 REGISTER request (after the Contact header validation as described 1190 above), the corresponding binding is between an AOR and the 1191 combination of the instance-id (from the +sip.instance media feature 1192 parameter) and the value of reg-id Contact header field parameter 1193 parameter. The registrar MUST store in the binding the Contact URI, 1194 all the Contact header field parameters, and any Path header field 1195 values. (Even though the Contact URI is not used for binding 1196 comparisons, it is still needed by the authoritative proxy to form 1197 the target set.) Provided that the UAC had included an oubound 1198 option-tag (defined in Section 11.4) in a Supported header field 1199 value in the REGISTER request, the Registrar MUST include the 1200 outbound option-tag in a Require header field value in its response 1201 to that REGISTER request. 1203 If the UAC has a direct flow with the registrar, the registrar MUST 1204 store enough information to uniquely identify the network flow over 1205 which the request arrived. For common operating systems with TCP, 1206 this would typically just be the handle to the file descriptor where 1207 the handle would become invalid if the TCP session was closed. For 1208 common operating systems with UDP this would typically be the file 1209 descriptor for the local socket that received the request, the local 1210 interface, and the IP address and port number of the remote side that 1211 sent the request. The registrar MAY store this information by adding 1212 itself to the Path header field with an appropriate flow token. 1214 If the registrar receives a re-registration for a specific 1215 combination of AOR, instance-id and reg-id values, the registrar MUST 1216 update any information that uniquely identifies the network flow over 1217 which the request arrived if that information has changed, and SHOULD 1218 update the time the binding was last updated. 1220 To be compliant with this specification, registrars which can receive 1221 SIP requests directly from a UAC without intervening edge proxies 1222 MUST implement the same keep alive mechanisms as Edge Proxies 1223 (Section 5.4). Registrars with a direct flow with a UA MAY include a 1224 Flow-Timer header in a 2XX class registration response which includes 1225 the outbound option-tag in the Require header. 1227 7. Authoritative Proxy Procedures: Forwarding Requests 1229 When a proxy uses the location service to look up a registration 1230 binding and then proxies a request to a particular contact, it 1231 selects a contact to use normally, with a few additional rules: 1233 o The proxy MUST NOT populate the target set with more than one 1234 contact with the same AOR and instance-id at a time. 1235 o If a request for a particular AOR and instance-id fails with a 430 1236 (Flow Failed) response, the proxy SHOULD replace the failed branch 1237 with another target (if one is available) with the same AOR and 1238 instance-id, but a different reg-id. 1239 o If the proxy receives a final response from a branch other than a 1240 408 (Request Timeout) or a 430 (Flow Failed) response, the proxy 1241 MUST NOT forward the same request to another target representing 1242 the same AOR and instance-id. The targeted instance has already 1243 provided its response. 1245 The proxy uses the next-hop target of the message and the value of 1246 any stored Path header field vector in the registration binding to 1247 decide how to forward and populate the Route header in the request. 1248 If the proxy is colocated with the registrar and stored information 1249 about the flow to the UA that created the binding, then the proxy 1250 MUST send the request over the same 'logical flow' saved with the 1251 binding, since that flow is known to deliver data to the specific 1252 target UA instance's network flow that was saved with the binding. 1254 Implementation note: Typically this means that for TCP, the 1255 request is sent on the same TCP socket that received the REGISTER 1256 request. For UDP, the request is sent from the same local IP 1257 address and port over which the registration was received, to the 1258 same IP address and port from which the REGISTER was received. 1260 If a proxy or registrar receives information from the network that 1261 indicates that no future messages will be delivered on a specific 1262 flow, then the proxy MUST invalidate all the bindings in the target 1263 set that use that flow (regardless of AOR). Examples of this are a 1264 TCP socket closing or receiving a destination unreachable ICMP error 1265 on a UDP flow. Similarly, if a proxy closes a file descriptor, it 1266 MUST invalidate all the bindings in the target set with flows that 1267 use that file descriptor. 1269 8. STUN Keep alive Processing 1271 This section describes changes to the SIP transport layer that allow 1272 SIP and STUN [RFC5389] Binding Requests to be mixed over the same 1273 flow. This constitutes a new STUN usage. The STUN messages are used 1274 to verify that connectivity is still available over a UDP flow, and 1275 to provide periodic keep alives. These STUN keep alives are always 1276 sent to the next SIP hop. STUN messages are not delivered end-to- 1277 end. 1279 The only STUN messages required by this usage are Binding Requests, 1280 Binding Responses, and Binding Error Responses. The UAC sends 1281 Binding Requests over the same UDP flow that is used for sending SIP 1282 messages. These Binding Requests do not require any STUN attributes. 1283 The corresponding Binding Responses do not require any STUN 1284 attributes except the XOR-MAPPED-ADDRESS. The UAS, proxy, or 1285 registrar responds to a valid Binding Request with a Binding Response 1286 which MUST include the XOR-MAPPED-ADDRESS attribute. 1288 If a server compliant to this section receives SIP requests on a 1289 given interface and UDP port, it MUST also provide a limited version 1290 of a STUN server on the same interface and UDP port. 1292 Note: It is easy to distinguish STUN and SIP packets sent over 1293 UDP, because the first octet of a STUN Binding method has a value 1294 of 0 or 1 while the first octet of a SIP message is never a 0 or 1295 1. 1297 Because sending and receiving binary STUN data on the same ports used 1298 for SIP is a significant and non-backwards compatible change to RFC 1299 3261, this section requires a number of checks before sending STUN 1300 messages to a SIP node. If a SIP node sends STUN requests (for 1301 example due to incorrect configuration) despite these warnings, the 1302 node could be blacklisted for UDP traffic. 1304 A SIP node MUST NOT send STUN requests over a flow unless it has an 1305 explicit indication that the target next hop SIP server claims to 1306 support this specification. UACs MUST NOT use an ambiguous 1307 configuration option such as "Work through NATs?" or "Do Keep 1308 alives?" to imply next hop STUN support. A UAC MAY use the presence 1309 of an ob URI parameter in the Path header in a registration response 1310 as an indication that its first edge proxy supports the keep alives 1311 defined in this document. 1313 Note: Typically, a SIP node first sends a SIP request and waits 1314 to receive a 2XX class response over a flow to a new target 1315 destination, before sending any STUN messages. When scheduled for 1316 the next NAT refresh, the SIP node sends a STUN request to the 1317 target. 1319 Once a flow is established, failure of a STUN request (including its 1320 retransmissions) is considered a failure of the underlying flow. For 1321 SIP over UDP flows, if the XOR-MAPPED-ADDRESS returned over the flow 1322 changes, this indicates that the underlying connectivity has changed, 1323 and is considered a flow failure. 1325 The SIP keep alive STUN usage requires no backwards compatibility 1326 with [RFC3489]. 1328 8.1. Use with Sigcomp 1330 When STUN is used together with SigComp [RFC3320] compressed SIP 1331 messages over the same flow, the STUN messages are simply sent 1332 uncompressed, "outside" of SigComp. This is supported by 1333 multiplexing STUN messages with SigComp messages by checking the two 1334 topmost bits of the message. These bits are always one for SigComp, 1335 or zero for STUN. 1337 Note: All SigComp messages contain a prefix (the five most- 1338 significant bits of the first byte are set to one) that does not 1339 occur in UTF-8 [RFC3629] encoded text messages, so for 1340 applications which use this encoding (or ASCII encoding) it is 1341 possible to multiplex uncompressed application messages and 1342 SigComp messages on the same UDP port. The most significant two 1343 bits of every STUN Binding method are both zeroes. This, combined 1344 with the magic cookie, aids in differentiating STUN packets from 1345 other protocols when STUN is multiplexed with other protocols on 1346 the same port. 1348 9. Example Message Flow 1350 Below is an example message flow illustrating most of the concepts 1351 discussed in this specification. In many cases, Via, Content-Length 1352 and Max-Forwards headers are omitted for brevity and readability. 1354 In these examples, "EP1" and "EP2" are outbound proxies, and "Proxy" 1355 is the authoritativeProxy. 1357 The section is subdivided into independent calls flows: however, 1358 they are structured in sequential order of an hypothetical sequence 1359 of call flows. 1361 9.1. Subscription to configuration package 1363 If the outbound proxy set is already configured on Bob's UA, then 1364 this subsection can be skipped. Otherwise, if the outbound proxy set 1365 is learned through the configuration package, Bob's UA sends a 1366 SUBSCRIBE request for the UA profile configuration package 1367 [I-D.ietf-sipping-config-framework]. This request is a poll (Expires 1368 is zero). After receiving the NOTIFY request, Bob's UA fetches the 1369 external configuration using HTTPS (not shown) and obtains a 1370 configuration file which contains the outbound-proxy-set "sip: 1371 ep1.example.com;lr" and "sip:ep2.example.com;lr". 1373 [----example.com domain-------------------------] 1374 Bob EP1 EP2 Proxy Config 1375 | | | | | 1376 1)|SUBSCRIBE->| | | | 1377 2)| |---SUBSCRIBE Event: ua-profile ->| 1378 3)| |<--200 OK -----------------------| 1379 4)|<--200 OK--| | | | 1380 5)| |<--NOTIFY------------------------| 1381 6)|<--NOTIFY--| | | | 1382 7)|---200 OK->| | | | 1383 8)| |---200 OK ---------------------->| 1384 | | | | | 1386 In this example, the DNS server happens to be configured so that sip: 1387 example.com resolves to EP1 and EP2. 1389 Example Message #1: 1391 SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com 1392 SIP/2.0 1393 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnlsdkdj2 1394 Max-Forwards: 70 1395 From: ;tag=23324 1396 To: 1397 Call-ID: nSz1TWN54x7My0GvpEBj 1398 CSeq: 1 SUBSCRIBE 1399 Event: ua-profile ;profile-type=device 1400 ;vendor="example.com";model="uPhone";version="1.1" 1401 Expires: 0 1402 Supported: path, outbound 1403 Accept: message/external-body, application/x-uPhone-config 1404 Contact: 1405 ;+sip.instance="" 1406 Content-Length: 0 1408 In message #2, EP1 adds the following Record-Route header: 1410 Record-Route: 1411 1413 In message #5, the configuration server sends a NOTIFY with an 1414 external URL for Bob to fetch his configuration. The NOTIFY has a 1415 Subscription-State header that ends the subscription. 1417 Message #5 1419 NOTIFY sip:192.0.2.2;transport=tcp;ob SIP/2.0 1420 Via: SIP/2.0/TCP 192.0.2.5;branch=z9hG4bKn81dd2 1421 Max-Forwards: 70 1422 To: ;tag=23324 1423 From: ;tag=0983 1424 Call-ID: nSz1TWN54x7My0GvpEBj 1425 CSeq: 1 NOTIFY 1426 Route: 1427 Subscription-State: terminated;reason=timeout 1428 Event: ua-profile 1429 Content-Type: message/external-body; access-type="URL" 1430 ;expiration="Thu, 01 Jan 2009 09:00:00 UTC" 1431 ;URL="http://example.com/uPhone.cfg" 1432 ;size=9999;hash=10AB568E91245681AC1B 1433 Content-Length: 0 1435 EP1 receives this NOTIFY request, strips off the Route header, 1436 extracts the flow-token, calculates the correct flow and forwards the 1437 request (Message #6) over that flow to Bob. 1439 Bob's UA fetches the configuration file and learns the outbound proxy 1440 set. 1442 9.2. Registration 1444 Now that Bob's UA is configured with the outbound-proxy-set whether 1445 through configuration or using the configuration framework procedures 1446 of the previous section, Bob's UA sends REGISTER requests through 1447 each edge proxy in the set. Once the registrations succeed, Bob's UA 1448 begins sending CRLF keep alives about every 2 minutes. 1450 Bob EP1 EP2 Proxy Alice 1451 | | | | | 1452 9)|-REGISTER->| | | | 1453 10)| |---REGISTER-->| | 1454 11)| |<----200 OK---| | 1455 12)|<-200 OK---| | | | 1456 13)|----REGISTER---->| | | 1457 14)| | |--REG-->| | 1458 15)| | |<-200---| | 1459 16)|<----200 OK------| | | 1460 | | | | | 1461 | about 120 seconds later... | 1462 | | | | | 1463 17)|--2CRLF--->| | | | 1464 18)|<--CRLF----| | | | 1465 19)|------2CRLF----->| | | 1466 20)|<------CRLF------| | | 1467 | | | | | 1469 In message #9, Bob's UA sends its first registration through the 1470 first edge proxy in the outbound-proxy-set by including a loose 1471 route. The UA includes an instance-id and reg-id in its Contact 1472 header field value. Note the option-tags in the Supported header. 1474 Message #9 1476 REGISTER sip:example.com SIP/2.0 1477 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7 1478 Max-Forwards: 70 1479 From: Bob ;tag=7F94778B653B 1480 To: Bob 1481 Call-ID: 16CB75F21C70 1482 CSeq: 1 REGISTER 1483 Supported: path, outbound 1484 Route: 1485 Contact: ;reg-id=1 1486 ;+sip.instance="" 1487 Content-Length: 0 1489 Message #10 is similar. EP1 removes the Route header field value, 1490 decrements Max-Forwards, and adds its Via header field value. Since 1491 EP1 is the first edge proxy, it adds a Path header with a flow token 1492 and includes the 'ob' parameter. 1494 Path: 1496 Since the response to the REGISTER (message #11) contains the 1497 outbound option-tag in the Require header field, Bob's UA will know 1498 that the registrar used outbound binding rules. The response also 1499 contains the currently active Contacts, the Path for the current 1500 registration. 1502 Message #11 1504 SIP/2.0 200 OK 1505 Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi 1506 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7 1507 From: Bob ;tag=7F94778B653B 1508 To: Bob ;tag=6AF99445E44A 1509 Call-ID: 16CB75F21C70 1510 CSeq: 1 REGISTER 1511 Supported: path, outbound 1512 Require: outbound 1513 Contact: ;reg-id=1;expires=3600 1514 ;+sip.instance="" 1515 Path: 1516 Content-Length: 0 1518 The second registration through EP2 (message #13) is similar other 1519 than the Call-ID has changed, the reg-id is 2, and the Route header 1520 goes through EP2. 1522 Message #13 1524 REGISTER sip:example.com SIP/2.0 1525 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym 1526 Max-Forwards: 70 1527 From: Bob ;tag=755285EABDE2 1528 To: Bob 1529 Call-ID: E05133BD26DD 1530 CSeq: 1 REGISTER 1531 Supported: path, outbound 1532 Route: 1533 Contact: ;reg-id=2 1534 ;+sip.instance="" 1535 Content-Length: 0 1537 Likewise in message #14, EP2 adds a Path header with flow token and 1538 'ob' parameter. 1540 Path: 1542 Message #16 tells Bob's UA that outbound registration was successful, 1543 and shows both Contacts. Note that only the Path corresponding to 1544 the current registration is returned. 1546 Message #16 1548 SIP/2.0 200 OK 1549 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym 1550 From: Bob ;tag=755285EABDE2 1551 To: Bob ;tag=49A9AD0B3F6A 1552 Call-ID: E05133BD26DD 1553 Supported: path, outbound 1554 Require: outbound 1555 CSeq: 1 REGISTER 1556 Contact: ;reg-id=1;expires=3600 1557 ;+sip.instance="" 1558 Contact: ;reg-id=2;expires=3600 1559 ;+sip.instance="" 1560 Path: 1561 Content-Length: 0 1563 9.3. Incoming call and proxy crash 1565 In this example, after registration, EP1 crashes and reboots. Before 1566 Bob's UA notices that its flow to EP1 is no longer responding, Alice 1567 calls Bob. Bob's authoritative proxy first tries the flow to EP1, but 1568 EP1 no longer has a flow to Bob so it responds with a 430 Flow Failed 1569 response. The proxy removes the stale registration and tries the 1570 next binding for the same instance. 1572 Bob EP1 EP2 Proxy Alice 1573 | | | | | 1574 | CRASH X | | | 1575 | Reboot | | | 1576 | | | | | 1577 21)| | | |<-INVITE-| 1578 22)| |<---INVITE----| | 1579 23)| |----430------>| | 1580 24)| | |<-INVITE| | 1581 25)|<---INVITE-------| | | 1582 26)|----200 OK------>| | | 1583 27)| | |200 OK->| | 1584 28)| | | |-200 OK->| 1585 29)| | |<----------ACK----| 1586 30)|<---ACK----------| | | 1587 | | | | | 1588 31)| | |<----------BYE----| 1589 32)|<---BYE----------| | | 1590 33)|----200 OK------>| | | 1591 34)| | |--------200 OK--->| 1592 | | | | | 1594 Message #21 1596 INVITE sip:bob@example.com SIP/2.0 1597 To: Bob 1598 From: Alice ;tag=02935 1599 Call-ID: klmvCxVWGp6MxJp2T2mb 1600 CSeq: 1 INVITE 1602 Bob's proxy rewrites the Request-URI to the Contact URI used in Bob's 1603 registration, and places the path for one of the registrations 1604 towards Bob's UA instance into a Route header field. This Route goes 1605 through EP1. 1607 Message #22 1609 INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0 1610 To: Bob 1611 From: Alice ;tag=02935 1612 Call-ID: klmvCxVWGp6MxJp2T2mb 1613 CSeq: 1 INVITE 1614 Route: 1616 Since EP1 just rebooted, it does not have the flow described in the 1617 flow token. It returns a 430 Flow Failed response. 1619 Message #23 1621 SIP/2.0 430 Flow Failed 1622 To: Bob 1623 From: Alice ;tag=02935 1624 Call-ID: klmvCxVWGp6MxJp2T2mb 1625 CSeq: 1 INVITE 1627 The proxy deletes the binding for this path and tries to forward the 1628 INVITE again, this time with the path through EP2. 1630 Message #24 1632 INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0 1633 To: Bob 1634 From: Alice ;tag=02935 1635 Call-ID: klmvCxVWGp6MxJp2T2mb 1636 CSeq: 1 INVITE 1637 Route: 1639 In message #25, EP2 needs to add a Record-Route header field value, 1640 so that any subsequent in-dialog messages from Alice's UA arrive at 1641 Bob's UA. EP2 can determine it needs to Record-Route since the 1642 request is a dialog-forming request and the Route header contained a 1643 flow token and an 'ob' parameter. This Record-Route information is 1644 passed back to Alice's UA in the responses (messages #26, 27, and 28) 1646 Message #25 1648 INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0 1649 To: Bob 1650 From: Alice ;tag=02935 1651 Call-ID: klmvCxVWGp6MxJp2T2mb 1652 CSeq: 1 INVITE 1653 Record-Route: 1654 1656 Message #26 1658 SIP/2.0 200 OK 1659 To: Bob ;tag=skduk2 1660 From: Alice ;tag=02935 1661 Call-ID: klmvCxVWGp6MxJp2T2mb 1662 CSeq: 1 INVITE 1663 Record-Route: 1664 1666 At this point, both UAs have the correct route-set for the dialog. 1667 Any subsequent requests in this dialog will route correctly. For 1668 example, the ACK request in message #29 is sent form Alice's UA 1669 directly to EP2. The BYE request in message #31 uses the same route- 1670 set. 1672 Message #29 1674 ACK sip:bob@192.0.2.2;transport=tcp SIP/2.0 1675 To: Bob ;tag=skduk2 1676 From: Alice ;tag=02935 1677 Call-ID: klmvCxVWGp6MxJp2T2mb 1678 CSeq: 1 ACK 1679 Route: 1681 Message #31 1683 BYE sip:bob@192.0.2.2;transport=tcp SIP/2.0 1684 To: Bob ;tag=skduk2 1685 From: Alice ;tag=02935 1686 Call-ID: klmvCxVWGp6MxJp2T2mb 1687 CSeq: 2 BYE 1688 Route: 1690 9.4. Re-registration 1692 Somewhat later, Bob's UA sends keep alives to both its edge proxies, 1693 but it discovers that the flow with EP1 failed. Bob's UA re- 1694 registers through EP1 using the same reg-id and Call-ID it previously 1695 used. 1697 Bob EP1 EP2 Proxy Alice 1698 | | | | | 1699 35)|------2CRLF----->| | | 1700 36)|<------CRLF------| | | 1701 37)|--2CRLF->X | | | | 1702 | | | | | 1703 38)|-REGISTER->| | | | 1704 39)| |---REGISTER-->| | 1705 40)| |<----200 OK---| | 1706 41)|<-200 OK---| | | | 1707 | | | | | 1709 Message #38 1711 REGISTER sip:example.com SIP/2.0 1712 From: Bob ;tag=7F94778B653B 1713 To: Bob 1714 Call-ID: 16CB75F21C70 1715 CSeq: 2 REGISTER 1716 Supported: path, outbound 1717 Route: 1718 Contact: ;reg-id=1 1719 ;+sip.instance="" 1721 In message #39, EP1 inserts a Path header with a new flow token: 1723 Path: 1725 9.5. Outgoing call 1727 Finally, Bob makes an outgoing call to Alice. Bob's UA includes an 1728 'ob' parameter in its Contact URI in message #42. EP1 adds a Record- 1729 Route with a flow-token in message #43. The route-set is returned to 1730 Bob in the response (messages #45, 46, and 47) and either Bob or 1731 Alice can send in-dialog requests. 1733 Bob EP1 EP2 Proxy Alice 1734 | | | | | 1735 42)|--INVITE-->| | | | 1736 43)| |---INVITE---->| | 1737 44)| | | |-INVITE->| 1738 45)| | | |<--200---| 1739 46)| |<----200 OK---| | 1740 47)|<-200 OK---| | | | 1741 48)|--ACK----->| | | | 1742 49)| |-----ACK--------------->| 1743 | | | | | 1744 50)|-- BYE---->| | | | 1745 51)| |-----------BYE--------->| 1746 52)| |<----------200 OK-------| 1747 53)|<--200 OK--| | | | 1748 | | | | | 1750 Message #42 1752 INVITE sip:alice@a.example SIP/2.0 1753 From: Bob ;tag=ldw22z 1754 To: Alice 1755 Call-ID: 95KGsk2V/Eis9LcpBYy3 1756 CSeq: 1 INVITE 1757 Route: 1758 Contact: 1760 In message #43, EP1 adds the following Record-Route header. 1762 Record-Route: 1763 1765 When EP1 receives the BYE (message #50) from Bob's UA, it can tell 1766 that the request is an "outgoing" request (since the source of the 1767 request matches the flow in the flow token) and simply deletes its 1768 Route header field value and forwards the request on to Alice's UA. 1770 Message #50 1772 BYE sip:alice@a.example SIP/2.0 1773 From: Bob ;tag=ldw22z 1774 To: Alice ;tag=plqus8 1775 Call-ID: 95KGsk2V/Eis9LcpBYy3 1776 CSeq: 2 BYE 1777 Route: 1778 Contact: 1780 10. Grammar 1782 This specification defines a new header field "Flow-Timer", new 1783 Contact header field parameters, reg-id and +sip.instance. The 1784 grammar includes the definitions from [RFC3261]. Flow-Timer is an 1785 extension-header from the message-header in the [RFC3261] ABNF. 1787 The ABNF[RFC5234] is: 1789 Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT 1791 contact-params =/ c-p-reg / c-p-instance 1793 c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2**31 - 1) 1795 c-p-instance = "+sip.instance" EQUAL 1796 DQUOTE "<" instance-val ">" DQUOTE 1798 instance-val = 1*uric ; defined in RFC 3261 1800 The value of the reg-id MUST NOT be 0 and MUST be less than 2**31. 1802 11. IANA Considerations 1804 11.1. Flow-Timer Header Field 1806 This specification defines a new SIP header field "Flow-Timer" whose 1807 syntax is defined in Section 10. 1809 Header Name compact Reference 1810 ----------------- ------- --------- 1811 Flow-Timer [RFCXXXX] 1813 [NOTE TO RFC Editor: Please replace XXXX with 1814 the RFC number of this specification.] 1816 11.2. 'reg-id' Contact Header Field Parameter 1818 This specification defines a new Contact header field parameter 1819 called reg-id in the "Header Field Parameters and Parameter Values" 1820 sub-registry as per the registry created by [RFC3968]. The syntax is 1821 defined in Section 10. The required information is: 1823 Predefined 1824 Header Field Parameter Name Values Reference 1825 ---------------------- --------------------- ---------- --------- 1826 Contact reg-id No [RFCXXXX] 1828 [NOTE TO RFC Editor: Please replace XXXX with 1829 the RFC number of this specification.] 1831 11.3. SIP/SIPS URI Parameters 1833 This specification augments the "SIP/SIPS URI Parameters" sub- 1834 registry as per the registry created by [RFC3969]. The required 1835 information is: 1837 Parameter Name Predefined Values Reference 1838 -------------- ----------------- --------- 1839 ob No [RFCXXXX] 1841 [NOTE TO RFC Editor: Please replace XXXX with 1842 the RFC number of this specification.] 1844 11.4. SIP Option Tag 1846 This specification registers a new SIP option tag, as per the 1847 guidelines in Section 27.1 of [RFC3261]. 1849 Name: outbound 1850 Description: This option-tag is used to identify UAs and Registrars 1851 which support extensions for Client Initiated Connections. A UA 1852 places this option in a Supported header to communicate its 1853 support for this extension. A Registrar places this option-tag in 1854 a Require header to indicate to the registering User Agent that 1855 the Registrar used registrations using the binding rules defined 1856 in this extension. 1858 11.5. 430 (Flow Failed) Response Code 1860 This document registers a new SIP response code (430 Flow Failed), as 1861 per the guidelines in Section 27.4 of [RFC3261]. This response code 1862 is used by an Edge Proxy to indicate to the Authoritative Proxy that 1863 a specific flow to a UA instance has failed. Other flows to the same 1864 instance could still succeed. The Authoritative Proxy SHOULD attempt 1865 to forward to another target (flow) with the same instance-id and 1866 AOR. Endpoints should never receive a 430 response. If an endpoint 1867 receives a 430 response it should treat it as a 400 (Bad Request) per 1868 normal 8.1.3.2/[RFC3261] procedures. This response code is defined 1869 by the following information, which has been added to the method and 1870 response-code sub-registry under 1871 http://www.iana.org/assignments/sip-parameters. 1873 Response Code Reference 1874 ------------------------------------------ --------- 1875 Request Failure 4xx 1876 430 Flow Failed [RFCXXXX] 1878 [NOTE TO RFC Editor: Please replace XXXX with 1879 the RFC number of this specification.] 1881 11.6. 439 (First Hop Lacks Outbound Support) Response Code 1883 This document registers a new SIP response code (439 First Hop Lacks 1884 Outbound Support), as per the guidelines in Section 27.4 of 1885 [RFC3261]. This response code is used by a registrar to indicate 1886 that it supports the 'outbound' feature described in this 1887 specification, but that the first outbound proxy that the user is 1888 attempting to register through does not. Note that this response 1889 code is only appropriate in the case that the registering user agent 1890 advertises support for outbound processing by including the outbound 1891 option tag in a Supported header field. Proxies MUST NOT send a 439 1892 response to any requests that do not contain a reg-id parameter and 1893 an outbound option tag in a Supported header field. This response 1894 code is defined by the following information, which has been added to 1895 the method and response-code sub-registry under 1896 http://www.iana.org/assignments/sip-parameters. 1898 Response Code Reference 1899 ------------------------------------------ --------- 1900 Request Failure 4xx 1901 439 First Hop Lacks Outbound Support [RFCXXXX] 1903 [NOTE TO RFC Editor: Please replace XXXX with 1904 the RFC number of this specification.] 1906 11.7. Media Feature Tag 1908 This section registers a new media feature tag, per the procedures 1909 defined in [RFC2506]. The tag is placed into the sip tree, which is 1910 defined in [RFC3840]. 1912 Media feature tag name: sip.instance 1914 ASN.1 Identifier: New assignment by IANA. 1916 Summary of the media feature indicated by this tag: This feature tag 1917 contains a string containing a URN that indicates a unique identifier 1918 associated with the UA instance registering the Contact. 1920 Values appropriate for use with this feature tag: String (equality 1921 relationship). 1923 The feature tag is intended primarily for use in the following 1924 applications, protocols, services, or negotiation mechanisms: This 1925 feature tag is most useful in a communications application, for 1926 describing the capabilities of a device, such as a phone or PDA. 1928 Examples of typical use: Routing a call to a specific device. 1930 Related standards or documents: RFC XXXX 1932 [Note to IANA: Please replace XXXX with the RFC number of this 1933 specification.] 1935 Security Considerations: This media feature tag can be used in ways 1936 which affect application behaviors. For example, the SIP caller 1937 preferences extension [RFC3841] allows for call routing decisions to 1938 be based on the values of these parameters. Therefore, if an 1939 attacker can modify the values of this tag, they might be able to 1940 affect the behavior of applications. As a result, applications which 1941 utilize this media feature tag SHOULD provide a means for ensuring 1942 its integrity. Similarly, this feature tag should only be trusted as 1943 valid when it comes from the user or user agent described by the tag. 1944 As a result, protocols for conveying this feature tag SHOULD provide 1945 a mechanism for guaranteeing authenticity. 1947 12. Security Considerations 1949 One of the key security concerns in this work is making sure that an 1950 attacker cannot hijack the sessions of a valid user and cause all 1951 calls destined to that user to be sent to the attacker. Note that 1952 the intent is not to prevent existing active attacks on SIP UDP and 1953 TCP traffic, but to insure that no new attacks are added by 1954 introducing the outbound mechanism. 1956 The simple case is when there are no edge proxies. In this case, the 1957 only time an entry can be added to the routing for a given AOR is 1958 when the registration succeeds. SIP already protects against 1959 attackers being able to successfully register, and this scheme relies 1960 on that security. Some implementers have considered the idea of just 1961 saving the instance-id without relating it to the AOR with which it 1962 registered. This idea will not work because an attacker's UA can 1963 impersonate a valid user's instance-id and hijack that user's calls. 1965 The more complex case involves one or more edge proxies. When a UA 1966 sends a REGISTER request through an Edge Proxy on to the registrar, 1967 the Edge Proxy inserts a Path header field value. If the 1968 registration is successfully authenticated, the registrar stores the 1969 value of the Path header field. Later when the registrar forwards a 1970 request destined for the UA, it copies the stored value of the Path 1971 header field into the Route header field of the request and forwards 1972 the request to the Edge Proxy. 1974 The only time an Edge Proxy will route over a particular flow is when 1975 it has received a Route header that has the flow identifier 1976 information that it has created. An incoming request would have 1977 gotten this information from the registrar. The registrar will only 1978 save this information for a given AOR if the registration for the AOR 1979 has been successful; and the registration will only be successful if 1980 the UA can correctly authenticate. Even if an attacker has spoofed 1981 some bad information in the Path header sent to the registrar, the 1982 attacker will not be able to get the registrar to accept this 1983 information for an AOR that does not belong to the attacker. The 1984 registrar will not hand out this bad information to others, and 1985 others will not be misled into contacting the attacker. 1987 The Security Considerations discussed in [RFC3261] and [RFC3327] are 1988 also relevant to this document. For the security considerations of 1989 generating flow tokens, please also see Section 5.2. A discussion of 1990 preventing the avalanche restart problem is in Section 4.5. 1992 This document does not change the mandatory to implement security 1993 mechanisms in SIP. User Agents are already required to implement 1994 Digest authentication while support of TLS is recommended; proxy 1995 servers are already required to implement Digest and TLS. 1997 13. Operational Notes on Transports 1999 This entire section is non-normative. 2001 [RFC3261] requires proxies, registrars, and User Agents to implement 2002 both TCP and UDP but deployments can chose which transport protocols 2003 they want to use. Deployments need to be careful in choosing what 2004 transports to use. Many SIP features and extensions, such as large 2005 presence notification bodies, result in SIP requests that can be too 2006 large to be reasonably transported over UDP. [RFC3261] states that 2007 when a request is too large for UDP, the device sending the request 2008 attempts to switch over to TCP. It is important to note that when 2009 using outbound, this will only work if the UA has formed both UDP and 2010 TCP outbound flows. This specification allows the UA to do so but in 2011 most cases it will probably make more sense for the UA to form a TCP 2012 outbound connection only, rather than forming both UDP and TCP flows. 2013 One of the key reasons that many deployments choose not to use TCP 2014 has to do with the difficulty of building proxies that can maintain a 2015 very large number of active TCP connections. Many deployments today 2016 use SIP in such a way that the messages are small enough that they 2017 work over UDP but they can not take advantage of all the 2018 functionality SIP offers. Deployments that use only UDP outbound 2019 connections are going to fail with sufficiently large SIP messages. 2021 14. Requirements 2023 This specification was developed to meet the following requirements: 2025 1. Must be able to detect that a UA supports these mechanisms. 2026 2. Support UAs behind NATs. 2027 3. Support TLS to a UA without a stable DNS name or IP address. 2028 4. Detect failure of a connection and be able to correct for this. 2029 5. Support many UAs simultaneously rebooting. 2030 6. Support a NAT rebooting or resetting. 2031 7. Minimize initial startup load on a proxy. 2032 8. Support architectures with edge proxies. 2034 15. Acknowledgments 2036 Francois Audet acted as document shepherd for this draft, tracking 2037 hundreds of comments and incorporating many grammatical fixes as well 2038 as prodding the editors to "get on with it". Jonathan Rosenberg, 2039 Erkki Koivusalo, and Byron Campen provided many comments and useful 2040 text. Dave Oran came up with the idea of using the most recent 2041 registration first in the proxy. Alan Hawrylyshen co-authored the 2042 draft that formed the initial text of this specification. 2043 Additionally, many of the concepts here originated at a connection 2044 reuse meeting at IETF 60 that included the authors, Jon Peterson, 2045 Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat. The TCP 2046 design team consisting of Chris Boulton, Scott Lawrence, Rajnish 2047 Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input and text. 2048 Nils Ohlmeier provided many fixes and initial implementation 2049 experience. In addition, thanks to the following folks for useful 2050 comments: Francois Audet, Flemming Andreasen, Mike Hammer, Dan Wing, 2051 Srivatsa Srinivasan, Dale Worely, Juha Heinanen, Eric Rescorla, 2052 Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel, 2053 Derek MacDonald, Dean Willis and Robert Sparks. 2055 16. References 2056 16.1. Normative References 2058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2059 Requirement Levels", BCP 14, RFC 2119, March 1997. 2061 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 2063 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 2064 Registration Procedure", BCP 31, RFC 2506, March 1999. 2066 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2067 A., Peterson, J., Sparks, R., Handley, M., and E. 2068 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2069 June 2002. 2071 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2072 Protocol (SIP): Locating SIP Servers", RFC 3263, 2073 June 2002. 2075 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 2076 (SIP) Extension Header Field for Registering Non-Adjacent 2077 Contacts", RFC 3327, December 2002. 2079 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 2080 Session Initiation Protocol (SIP) for Symmetric Response 2081 Routing", RFC 3581, August 2003. 2083 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2084 10646", STD 63, RFC 3629, November 2003. 2086 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2087 "Indicating User Agent Capabilities in the Session 2088 Initiation Protocol (SIP)", RFC 3840, August 2004. 2090 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 2091 Preferences for the Session Initiation Protocol (SIP)", 2092 RFC 3841, August 2004. 2094 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 2095 (IANA) Header Field Parameter Registry for the Session 2096 Initiation Protocol (SIP)", BCP 98, RFC 3968, 2097 December 2004. 2099 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 2100 (IANA) Uniform Resource Identifier (URI) Parameter 2101 Registry for the Session Initiation Protocol (SIP)", 2102 BCP 99, RFC 3969, December 2004. 2104 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2105 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2106 July 2005. 2108 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2109 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2111 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2112 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2113 October 2008. 2115 16.2. Informational References 2117 [I-D.ietf-sip-gruu] 2118 Rosenberg, J., "Obtaining and Using Globally Routable User 2119 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2120 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 2121 October 2007. 2123 [I-D.ietf-sipping-config-framework] 2124 Channabasappa, S., "A Framework for Session Initiation 2125 Protocol User Agent Profile Delivery", 2126 draft-ietf-sipping-config-framework-15 (work in progress), 2127 February 2008. 2129 [I-D.ietf-sipping-nat-scenarios] 2130 Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, 2131 "Best Current Practices for NAT Traversal for Client- 2132 Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in 2133 progress), September 2008. 2135 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2136 August 1980. 2138 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2139 RFC 793, September 1981. 2141 [RFC1035] Mockapetris, P., "Domain names - implementation and 2142 specification", STD 13, RFC 1035, November 1987. 2144 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2145 Hashing for Message Authentication", RFC 2104, 2146 February 1997. 2148 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2149 RFC 2131, March 1997. 2151 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2152 specifying the location of services (DNS SRV)", RFC 2782, 2153 February 2000. 2155 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 2156 Liu, Z., and J. Rosenberg, "Signaling Compression 2157 (SigComp)", RFC 3320, January 2003. 2159 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 2160 "STUN - Simple Traversal of User Datagram Protocol (UDP) 2161 Through Network Address Translators (NATs)", RFC 3489, 2162 March 2003. 2164 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2165 Resource Identifier (URI): Generic Syntax", STD 66, 2166 RFC 3986, January 2005. 2168 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2169 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2171 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2172 Encodings", RFC 4648, October 2006. 2174 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2175 RFC 4960, September 2007. 2177 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2178 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2180 Appendix A. Default Flow Registration Backoff Times 2182 The base-time used for the flow re-registration backoff times 2183 described in Section 4.5 are configurable. If the base-time-all-fail 2184 value is set to the default of 30 seconds and the base-time-not- 2185 failed value is set to the default of 90 seconds, the following table 2186 shows the resulting amount of time the UA will wait to retry 2187 registration. 2189 +-------------------+--------------------+---------------------+ 2190 | # of reg failures | all flows unusable | > 1 non-failed flow | 2191 +-------------------+--------------------+---------------------+ 2192 | 0 | 0 s | 0 s | 2193 | 1 | 30-60 s | 90-180 s | 2194 | 2 | 1-2 min | 3-6 min | 2195 | 3 | 2-4 min | 6-12 min | 2196 | 4 | 4-8 min | 12-24 min | 2197 | 5 | 8-16 min | 15-30 min | 2198 | 6 or more | 15-30 min | 15-30 min | 2199 +-------------------+--------------------+---------------------+ 2201 Authors' Addresses 2203 Cullen Jennings (editor) 2204 Cisco Systems 2205 170 West Tasman Drive 2206 Mailstop SJC-21/2 2207 San Jose, CA 95134 2208 USA 2210 Phone: +1 408 902-3341 2211 Email: fluffy@cisco.com 2213 Rohan Mahy (editor) 2214 Unaffiliated 2216 Email: rohan@ekabal.com