idnits 2.17.1 draft-ietf-sip-outbound-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1856. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document 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 RFC 3978 Section 5.4 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 7, 2007) is 6313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2279' on line 1141 -- Looks like a reference, but probably isn't: 'RFC AAAA' on line 1358 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 ** Obsolete normative reference: RFC 2141 (ref. '7') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') ** Obsolete normative reference: RFC 3548 (ref. '12') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2396 (ref. '13') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 4234 (ref. '14') (Obsoleted by RFC 5234) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-09 -- Obsolete informational reference (is this intentional?): RFC 3188 (ref. '19') (Obsoleted by RFC 8458) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-05 == Outdated reference: A later version (-10) exists of draft-ietf-rohc-sigcomp-impl-guide-08 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-11 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 13 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 (if approved) R. Mahy, Ed. 5 Intended status: Standards Track Plantronics 6 Expires: July 11, 2007 January 7, 2007 8 Managing Client Initiated Connections in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-outbound-07 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 11, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2007). 41 Abstract 43 The Session Initiation Protocol (SIP) allows proxy servers to 44 initiate TCP connections and send asynchronous UDP datagrams to User 45 Agents in order to deliver requests. However, many practical 46 considerations, such as the existence of firewalls and Network 47 Address Translators (NATs), prevent servers from connecting to User 48 Agents in this way. This specification defines behaviors for User 49 Agents, registrars and proxy servers that allow requests to be 50 delivered on existing connections established by the User Agent. It 51 also defines keep alive behaviors needed to keep NAT bindings open 52 and specifies the usage of multiple connections. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 5 61 3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6 62 3.3. Multiple Connections from a User Agent . . . . . . . . . . 7 63 3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. Keepalive Technique . . . . . . . . . . . . . . . . . . . 11 65 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 12 66 4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 12 67 4.2. Initial Registrations . . . . . . . . . . . . . . . . . . 13 68 4.2.1. Registration by Other Instances . . . . . . . . . . . 15 69 4.3. Sending Requests . . . . . . . . . . . . . . . . . . . . . 15 70 4.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 15 71 4.4.1. Keepalive with TCP KEEPALIVE . . . . . . . . . . . . . 16 72 4.4.2. Keepalive with STUN . . . . . . . . . . . . . . . . . 16 73 4.4.3. Flow Recovery . . . . . . . . . . . . . . . . . . . . 16 74 5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 18 75 5.1. Processing Register Requests . . . . . . . . . . . . . . . 18 76 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 18 77 5.3. Forwarding Requests . . . . . . . . . . . . . . . . . . . 19 78 5.4. Edge Proxy Keepalive Handling . . . . . . . . . . . . . . 20 79 6. Registrar Mechanisms: Processing REGISTER Requests . . . . . . 20 80 7. Authoritative Proxy Mechanisms: Forwarding Requests . . . . . 22 81 8. STUN Keepalive Processing . . . . . . . . . . . . . . . . . . 23 82 8.1. Explicit Probes . . . . . . . . . . . . . . . . . . . . . 25 83 8.2. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . . 25 84 9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 26 85 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 11. Definition of 430 Flow Failed response code . . . . . . . . . 30 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 88 12.1. Contact Header Field . . . . . . . . . . . . . . . . . . . 30 89 12.2. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 31 90 12.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 31 91 12.4. Response Code . . . . . . . . . . . . . . . . . . . . . . 31 92 12.5. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 31 93 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 94 14. Operational Notes on Transports . . . . . . . . . . . . . . . 33 95 15. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 16. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 97 16.1. Changes from 06 Version . . . . . . . . . . . . . . . . . 34 98 16.2. Changes from 05 Version . . . . . . . . . . . . . . . . . 34 99 16.3. Changes from 04 Version . . . . . . . . . . . . . . . . . 35 100 16.4. Changes from 03 Version . . . . . . . . . . . . . . . . . 36 101 16.5. Changes from 02 Version . . . . . . . . . . . . . . . . . 37 102 16.6. Changes from 01 Version . . . . . . . . . . . . . . . . . 37 103 16.7. Changes from 00 Version . . . . . . . . . . . . . . . . . 37 104 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 105 Appendix A. Default Flow Registration Backoff Times . . . . . . . 38 106 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 18.1. Normative References . . . . . . . . . . . . . . . . . . . 38 108 18.2. Informative References . . . . . . . . . . . . . . . . . . 39 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 110 Intellectual Property and Copyright Statements . . . . . . . . . . 42 112 1. Introduction 114 There are many environments for SIP [1] deployments in which the User 115 Agent (UA) can form a connection to a Registrar or Proxy but in which 116 connections in the reverse direction to the UA are not possible. 117 This can happen for several reasons. Connections to the UA can be 118 blocked by a firewall device between the UA and the proxy or 119 registrar, which will only allow new connections in the direction of 120 the UA to the Proxy. Similarly there a NAT could be present, which 121 is only capable of allowing new connections from the private address 122 side to the public side. This specification allows SIP registration 123 when the UA is behind such a firewall or NAT. 125 Most IP phones and personal computers get their network 126 configurations dynamically via a protocol such as DHCP (Dynamic Host 127 Configuration Protocol). These systems typically do not have a 128 useful name in the Domain Name System (DNS), and they almost never 129 have a long-term, stable DNS name that is appropriate for use in the 130 subjectAltName of a certificate, as required by [1]. However, these 131 systems can still act as a TLS client and form connections to a proxy 132 or registrar which authenticates with a server certificate. The 133 server can authenticate the UA using a shared secret in a digest 134 challenge over that TLS connection. 136 The key idea of this specification is that when a UA sends a REGISTER 137 request, the proxy can later use this same network "flow"--whether 138 this is a bidirectional stream of UDP datagrams, a TCP connection, or 139 an analogous concept of another transport protocol--to forward any 140 requests that need to go to this UA. For a UA to receive incoming 141 requests, the UA has to connect to a server. Since the server can't 142 connect to the UA, the UA has to make sure that a flow is always 143 active. This requires the UA to detect when a flow fails. Since 144 such detection takes time and leaves a window of opportunity for 145 missed incoming requests, this mechanism allows the UA to use 146 multiple flows to the proxy or registrar. This specification also 147 defines how SIP implements the STUN keepalive usage. The keepalive 148 mechanism is used to keep NAT bindings fresh, and to allow the UA to 149 detect when a flow has failed. 151 2. Conventions and Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [2]. 157 2.1. Definitions 159 Authoritative Proxy: A proxy that handles non-REGISTER requests for 160 a specific Address-of-Record (AOR), performs the logical Location 161 Server lookup described in RFC 3261, and forwards those requests 162 to specific Contact URIs. 163 Edge Proxy: An Edge Proxy is any proxy that is located topologically 164 between the registering User Agent and the Authoritative Proxy. 165 Flow: A Flow is a network protocol layer (layer 4) association 166 between two hosts that is represented by the network address and 167 port number of both ends and by the protocol. For TCP, a flow is 168 equivalent to a TCP connection. For UDP a flow is a bidirectional 169 stream of datagrams between a single pair of IP addresses and 170 ports of both peers. With TCP, a flow often has a one to one 171 correspondence with a single file descriptor in the operating 172 system. 173 reg-id: This refers to the value of a new header field parameter 174 value for the Contact header field. When a UA registers multiple 175 times, each simultaneous registration gets a unique reg-id value. 176 instance-id: This specification uses the word instance-id to refer 177 to the value of the "sip.instance" media feature tag in the 178 Contact header field. This is a Uniform Resource Name (URN) that 179 uniquely identifies this specific UA instance. 180 outbound-proxy-set A set of SIP URIs (Uniform Resource Identifiers) 181 that represents each of the outbound proxies (often Edge Proxies) 182 with which the UA will attempt to maintain a direct flow. The 183 first URI in the set is often referred to as the primary outbound 184 proxy and the second as the secondary outbound proxy. There is no 185 difference between any of the URIs in this set, nor does the 186 primary/secondary terminology imply that one is preferred over the 187 other. 189 3. Overview 191 Several scenarios in which this technique is useful are discussed 192 below, including the simple co-located registrar and proxy, a User 193 Agent desiring multiple connections to a resource (for redundancy, 194 for example), and a system that uses Edge Proxies. 196 3.1. Summary of Mechanism 198 The overall approach is fairly simple. Each UA has a unique 199 instance-id that stays the same for this UA even if the UA reboots or 200 is power cycled. Each UA can register multiple times over different 201 connections for the same SIP Address of Record (AOR) to achieve high 202 reliability. Each registration includes the instance-id for the UA 203 and a reg-id label that is different for each flow. The registrar 204 can use the instance-id to recognize that two different registrations 205 both reach the same UA. The registrar can use the reg-id label to 206 recognize that a UA is registering after a reboot or a network 207 failure. 209 When a proxy goes to route a message to a UA for which it has a 210 binding, it can use any one of the flows on which a successful 211 registration has been completed. A failure on a particular flow can 212 be tried again on an alternate flow. Proxies can determine which 213 flows go to the same UA by comparing the instance-id. Proxies can 214 tell that a flow replaces a previously abandoned flow by looking at 215 the reg-id. 217 UAs use the STUN (Simple Traversal of UDP through NATs) protocol as 218 the keepalive mechanism to keep their flow to the proxy or registrar 219 alive. 221 3.2. Single Registrar and UA 223 In the topology shown below, a single server is acting as both a 224 registrar and proxy. 226 +-----------+ 227 | Registrar | 228 | Proxy | 229 +-----+-----+ 230 | 231 | 232 +----+--+ 233 | User | 234 | Agent | 235 +-------+ 237 User Agents which form only a single flow continue to register 238 normally but include the instance-id as described in Section 4.1. 239 The UA can also include a reg-id parameter which is used to allow the 240 registrar to detect and avoid keeping invalid contacts when a UA 241 reboots or reconnects after its old connection has failed for some 242 reason. 244 For clarity, here is an example. Bob's UA creates a new TCP flow to 245 the registrar and sends the following REGISTER request. 247 REGISTER sip:example.com SIP/2.0 248 Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036 249 Max-Forwards: 70 250 From: Bob ;tag=d879h76 251 To: Bob 252 Call-ID: 8921348ju72je840.204 253 CSeq: 1 REGISTER 254 Supported: path 255 Contact: ; reg-id=1; 256 ;+sip.instance="" 257 Content-Length: 0 259 The registrar challenges this registration to authenticate Bob. When 260 the registrar adds an entry for this contact under the AOR for Bob, 261 the registrar also keeps track of the connection over which it 262 received this registration. 264 The registrar saves the instance-id 265 ("urn:uuid:00000000-0000-0000-0000-000A95A0E128") and reg-id ("1") 266 along with the rest of the Contact header field. If the instance-id 267 and reg-id are the same as a previous registration for the same AOR, 268 the registrar replaces the old Contact URI and flow information. 269 This allows a UA that has rebooted to replace its previous 270 registration for each flow with minimal impact on overall system 271 load. 273 When Alice sends a request to Bob, his authoritative proxy selects 274 the target set. The proxy forwards the request to elements in the 275 target set based on the proxy's policy. The proxy looks at the 276 target set and uses the instance-id to understand if two targets both 277 end up routing to the same UA. When the proxy goes to forward a 278 request to a given target, it looks and finds the flows over which it 279 received the registration. The proxy then forwards the request on 280 that flow instead of trying to form a new flow to that contact. This 281 allows the proxy to forward a request to a particular contact over 282 the same flow that the UA used to register this AOR. If the proxy 283 has multiple flows that all go to this UA, it can choose any one of 284 registration bindings for this AOR that has the same instance-id as 285 the selected UA. 287 3.3. Multiple Connections from a User Agent 289 There are various ways to deploy SIP to build a reliable and scalable 290 system. This section discusses one such design that is possible with 291 the mechanisms in this specification. Other designs are also 292 possible. 294 In the example system below, the logical outbound proxy/registrar for 295 the domain is running on two hosts that share the appropriate state 296 and can both provide registrar and outbound proxy functionality for 297 the domain. The UA will form connections to two of the physical 298 hosts that can perform the outbound proxy/registrar function for the 299 domain. Reliability is achieved by having the UA form two TCP 300 connections to the domain. 302 Scalability is achieved by using DNS SRV to load balance the primary 303 connection across a set of machines that can service the primary 304 connection, and also using DNS SRV to load balance across a separate 305 set of machines that can service the secondary connection. The 306 deployment here requires that DNS is configured with one entry that 307 resolves to all the primary hosts and another entry that resolves to 308 all the secondary hosts. While this introduces additional DNS 309 configuration, the approach works and requires no addition SIP 310 extensions. 312 Note: Approaches which select multiple connections from a single 313 DNS SRV set were also considered, but cannot prevent two 314 connections from accidentally resolving to the same host. The 315 approach in this document does not prevent future extensions, such 316 as the SIP UA configuration framework [18], from adding other ways 317 for a User Agent to discover its outbound-proxy-set. 319 +-------------------+ 320 | Domain | 321 | Logical Proxy/Reg | 322 | | 323 |+-----+ +-----+| 324 ||Host1| |Host2|| 325 |+-----+ +-----+| 326 +---\------------/--+ 327 \ / 328 \ / 329 \ / 330 \ / 331 +------+ 332 | User | 333 | Agent| 334 +------+ 336 The UA is configured with multiple outbound proxy registration URIs. 337 These URIs are configured into the UA through whatever the normal 338 mechanism is to configure the proxy or registrar address in the UA. 339 If the AOR is Alice@example.com, the outbound-proxy-set might look 340 something like "sip:primary.example.com;keepalive=stun" and "sip: 341 secondary.example.com;keepalive=stun". The "keepalive=stun" tag 342 indicates that a SIP server supports STUN and SIP multiplexed over 343 the same flow, as described later in this specification. Note that 344 each URI in the outbound-proxy-set could resolve to several different 345 physical hosts. The administrative domain that created these URIs 346 should ensure that the two URIs resolve to separate hosts. These 347 URIs are handled according to normal SIP processing rules, so 348 mechanisms like SRV can be used to do load balancing across a proxy 349 farm. 351 The domain also needs to ensure that a request for the UA sent to 352 host1 or host2 is then sent across the appropriate flow to the UA. 353 The domain might choose to use the Path header approach (as described 354 in the next section) to store this internal routing information on 355 host1 or host2. 357 When a single server fails, all the UAs that have a flow through it 358 will detect a flow failure and try to reconnect. This can cause 359 large loads on the server. When large numbers of hosts reconnect 360 nearly simultaneously, this is referred to as the avalanche restart 361 problem, and is further discussed in Section 4.4.3. The multiple 362 flows to many servers help reduce the load caused by the avalanche 363 restart. If a UA has multiple flows, and one of the servers fails, 364 the UA delays the specified time before trying to form a new 365 connection to replace the flow to the server that failed. By 366 spreading out the time used for all the UAs to reconnect to a server, 367 the load on the server farm is reduced. 369 When used in this fashion to achieve high reliability, the operator 370 will need to configure DNS such that the various URIs in the outbound 371 proxy set do not resolve to the same host. 373 Another motivation for maintaining multiple flows between the UA and 374 its registrar is related to multihomed UAs. Such UAs can benefit 375 from multiple connections from different interfaces to protect 376 against the failure of an individual access link. 378 3.4. Edge Proxies 380 Some SIP deployments use edge proxies such that the UA sends the 381 REGISTER to an Edge Proxy that then forwards the REGISTER to the 382 Registrar. The Edge Proxy includes a Path header [3] so that when 383 the registrar later forwards a request to this UA, the request is 384 routed through the Edge Proxy. There could be a NAT or firewall 385 between the UA and the Edge Proxy. 387 +---------+ 388 |Registrar| 389 |Proxy | 390 +---------+ 391 / \ 392 / \ 393 / \ 394 +-----+ +-----+ 395 |Edge1| |Edge2| 396 +-----+ +-----+ 397 \ / 398 \ / 399 ----------------------------NAT/FW 400 \ / 401 \ / 402 +------+ 403 |User | 404 |Agent | 405 +------+ 407 These systems can use effectively the same mechanism as described in 408 the previous sections but need to use the Path header. When the Edge 409 Proxy receives a registration, it needs to create an identifier value 410 that is unique to this flow (and not a subsequent flow with the same 411 addresses) and put this identifier in the Path header URI. This 412 identifier has two purposes. First, it allows the Edge Proxy to map 413 future requests back to the correct flow. Second, because the 414 identifier will only be returned if the user authentication with the 415 registrar succeeds, it allows the Edge Proxy to indirectly check the 416 user's authentication information via the registrar. The identifier 417 is placed in the user portion of a loose route in the Path header. 418 If the registration succeeds, the Edge Proxy needs to map future 419 requests that are routed to the identifier value from the Path 420 header, to the associated flow. 422 The term Edge Proxy is often used to refer to deployments where the 423 Edge Proxy is in the same administrative domain as the Registrar. 424 However, in this specification we use the term to refer to any proxy 425 between the UA and the Registrar. For example the Edge Proxy may be 426 inside an enterprise that requires its use and the registrar could be 427 from a service provider with no relationship to the enterprise. 428 Regardless if they are in the same administrative domain, this 429 specification requires that Registrars and Edge proxies support the 430 Path header mechanism in RFC 3327 [3]. 432 3.5. Keepalive Technique 434 A keepalive mechanism needs to detect failure of a connection and 435 changes to the NAT public mapping, as well as keeping any NAT 436 bindings refreshed. This specification describes using STUN [4] over 437 the same flow as the SIP traffic to perform the keepalive. For 438 connection-oriented transports (e.g. TCP and TLS over TCP), the UAC 439 MAY use TCP keepalives to detect flow failure if the UAC can send 440 these keepalives and detect a keepalive failure according to the time 441 frames described in Section 4.4. 443 Note: when TCP is being used, it's natural to think of using TCP 444 KEEPALIVE. Unfortunately, many operating systems and programming 445 environments do not allow the keepalive time to be set on a per- 446 connection basis. Thus, applications may not be able to set an 447 appropriate time. 449 For connection-less transports, a flow definition could change 450 because a NAT device in the network path reboots and the resulting 451 public IP address or port mapping for the UA changes. To detect 452 this, requests are sent over the same flow that is being used for the 453 SIP traffic. The proxy or registrar acts as a STUN server on the SIP 454 signaling port. 456 Note: The STUN mechanism is very robust and allows the detection 457 of a changed IP address. Many other options were considered, but 458 the SIP Working Group selected the STUN-based approach, since it 459 works over any transport. Approaches using SIP requests were 460 abandoned because to achieve the required performance, the server 461 needs to deviate from the SIP specification in significant ways. 462 This would result in many undesirable and non-deterministic 463 behaviors in some environments. 464 Another approach considered to detect a changed flow was using 465 OPTIONS messages and the rport parameter. Although the OPTIONS 466 approach has the advantage of being backwards compatible, it also 467 significantly increases the load on the proxy or registrar server. 468 Related to this idea was an idea of creating a new SIP PING method 469 that was like OPTIONS but faster. It would be critical that this 470 PING method did not violate the processing requirements of a 471 proxies and UAS so it was never clear how it would be 472 significantly faster than OPTIONS given it would still have to 473 obey things like checking the Proxy-Require header. After 474 considerable consideration the working group came to some 475 consensus that the STUN approach was a better solution that these 476 alternative designs. 478 When the UA detects that a flow has failed or that the flow 479 definition has changed, the UA needs to re-register and will use the 480 back-off mechanism described in Section 4 to provide congestion 481 relief when a large number of agents simultaneously reboot. 483 4. User Agent Mechanisms 485 4.1. Instance ID Creation 487 Each UA MUST have an Instance Identifier URN that uniquely identifies 488 the device. Usage of a URN provides a persistent and unique name for 489 the UA instance. It also provides an easy way to guarantee 490 uniqueness within the AOR. This URN MUST be persistent across power 491 cycles of the device. The Instance ID MUST NOT change as the device 492 moves from one network to another. 494 A UA SHOULD use a UUID URN [5] as its instance-id. The UUID URN 495 allows for non-centralized computation of a URN based on time, unique 496 names (such as a MAC address), or a random number generator. 498 A device like a soft-phone, when first installed, can generate a 499 UUID [5] and then save this in persistent storage for all future 500 use. For a device such as a hard phone, which will only ever have 501 a single SIP UA present, the UUID can include the MAC address and 502 be generated at any time because it is guaranteed that no other 503 UUID is being generated at the same time on that physical device. 504 This means the value of the time component of the UUID can be 505 arbitrarily selected to be any time less than the time when the 506 device was manufactured. A time of 0 (as shown in the example in 507 Section 3.2) is perfectly legal as long as the device knows no 508 other UUIDs were generated at this time. 510 If a URN scheme other than UUID is used, the URN MUST be selected 511 such that the instance can be certain that no other instance 512 registering against the same AOR would choose the same URN value. An 513 example of a URN that would not meet the requirements of this 514 specification is the national bibliographic number [19]. Since there 515 is no clear relationship between a SIP UA instance and a URN in this 516 namespace, there is no way a selection of a value can be performed 517 that guarantees that another UA instance doesn't choose the same 518 value. 520 The UA SHOULD include a "sip.instance" media feature tag as a UA 521 characteristic [6] in requests and responses. As described in [6], 522 this media feature tag will be encoded in the Contact header field as 523 the "+sip.instance" Contact header field parameter. The value of 524 this parameter MUST be a URN [7]. One case where a UA may not want 525 to include the URN in the sip.instance media feature tag is when it 526 is making an anonymous request or some other privacy concern requires 527 that the UA not reveal its identity. 529 RFC 3840 [6] defines equality rules for callee capabilities 530 parameters, and according to that specification, the 531 "sip.instance" media feature tag will be compared by case- 532 sensitive string comparison. This means that the URN will be 533 encapsulated by angle brackets ("<" and ">") when it is placed 534 within the quoted string value of the +sip.instance Contact header 535 field parameter. The case-sensitive matching rules apply only to 536 the generic usages defined in RFC 3840 [6] and in the caller 537 preferences specification [8]. When the instance ID is used in 538 this specification, it is effectively "extracted" from the value 539 in the "sip.instance" media feature tag. Thus, equality 540 comparisons are performed using the rules for URN equality that 541 are specific to the scheme in the URN. If the element performing 542 the comparisons does not understand the URN scheme, it performs 543 the comparisons using the lexical equality rules defined in RFC 544 2141 [7]. Lexical equality could result in two URNs being 545 considered unequal when they are actually equal. In this specific 546 usage of URNs, the only element which provides the URN is the SIP 547 UA instance identified by that URN. As a result, the UA instance 548 SHOULD provide lexically equivalent URNs in each registration it 549 generates. This is likely to be normal behavior in any case; 550 clients are not likely to modify the value of the instance ID so 551 that it remains functionally equivalent yet lexigraphically 552 different from previous registrations. 554 4.2. Initial Registrations 556 At configuration time UAs obtain one or more SIP URIs representing 557 the default outbound-proxy-set. This specification assumes the set 558 is determined via any of a number of configuration mechanisms, and 559 future specifications can define additional mechanisms such as using 560 DNS to discover this set. How the UA is configured is outside the 561 scope of this specification. However, a UA MUST support sets with at 562 least two outbound proxy URIs and SHOULD support sets with up to four 563 URIs. For each outbound proxy URI in the set, the UA SHOULD send a 564 REGISTER in the normal way using this URI as the default outbound 565 proxy. Forming the route set for the request is outside the scope of 566 this document, but typically results in sending the REGISTER such 567 that the topmost Route header field contains a loose route to the 568 outbound proxy URI. Other issues related to outbound route 569 construction are discussed in [20]. 571 Registration requests, other than those described in Section 4.2.1, 572 MUST include an instance-id media feature tag as specified in 573 Section 4.1. 575 These ordinary registration requests include a distinct reg-id 576 parameter to the Contact header field. Each one of these 577 registrations will form a new flow from the UA to the proxy. The 578 sequence of reg-id values does not have to be sequential but MUST be 579 exactly the same sequence of reg-id values each time the UA instance 580 power cycles or reboots so that the reg-id values will collide with 581 the previously used reg-id values. This is so the registrar can 582 replace the older registration. 584 The UAC can situationally decide whether to request outbound 585 behavior by including or omitting the 'reg-id' parameter. For 586 example, imagine the outbound-proxy-set contains two proxies in 587 different domains, EP1 and EP2. If an outbound-style registration 588 succeeded for a flow through EP1, the UA might decide to include 589 'outbound' in its option-tag when registering with EP2, in order 590 to insure consistency. Similarly, if the registration through EP1 591 did not support outbound, the UA might decide to omit the 'reg-id' 592 parameter when registering with EP2. 594 The UAC MUST indicate that it supports the Path header [3] mechanism, 595 by including the 'path' option-tag in a Supported header field value 596 in its REGISTER requests. Other than optionally examining the Path 597 vector in the response, this is all that is required of the UAC to 598 support Path. 600 The UAC MAY examine successful registrations for the presence of an 601 'outbound' option-tag in a Supported header field value. Presence of 602 this option-tag indicates that the registrar is compliant with this 603 specification, and that any edge proxies which need to participate 604 are also compliant. 606 Note that the UA needs to honor 503 (Service Unavailable) responses 607 to registrations as described in RFC 3261 and RFC 3263 [9]. In 608 particular, implementors should note that when receiving a 503 609 (Service Unavailable) response with a Retry-After header field, the 610 UA is expected to wait the indicated amount of time and retry the 611 registration. A Retry-After header field value of 0 is valid and 612 indicates the UA is expected to retry the REGISTER immediately. 613 Implementations need to ensure that when retrying the REGISTER, they 614 revisit the DNS resolution results such that the UA can select an 615 alternate host from the one chosen the previous time the URI was 616 resolved. 618 Finally, re-registrations which merely refresh an existing valid 619 registration SHOULD be sent over the same flow as the original 620 registration. 622 4.2.1. Registration by Other Instances 624 A User Agent MUST NOT include a reg-id header parameter in the 625 Contact header field of a registration if the registering UA is not 626 the same instance as the UA referred to by the target Contact header 627 field. (This practice is occasionally used to install forwarding 628 policy into registrars.) 630 Note that a UAC also MUST NOT include an instance-id or reg-id 631 parameter in a request to unregister all Contacts (a single Contact 632 header field value with the value of "*"). 634 4.3. Sending Requests 636 When a UA is about to send a request, it first performs normal 637 processing to select the next hop URI. The UA can use a variety of 638 techniques to compute the route set and accordingly the next hop URI. 639 Discussion of these techniques is outside the scope of this document 640 but could include mechanisms specified in RFC 3608 [21] (Service 641 Route) and [20]. 643 The UA performs normal DNS resolution on the next hop URI (as 644 described in RFC 3263 [9]) to find a protocol, IP address, and port. 645 For non-TLS protocols, if the UA has an existing flow to this IP 646 address, and port with the correct protocol, then the UA MUST use the 647 existing connection. For TLS protocols, there MUST also be a match 648 between the host production in the next hop and one of the URIs 649 contained in the subjectAltName in the peer certificate. If the UA 650 cannot use one of the existing flows, then it SHOULD form a new flow 651 by sending a datagram or opening a new connection to the next hop, as 652 appropriate for the transport protocol. 654 Note that if the UA wants its flow to work through NATs or 655 firewalls it still needs to put the 'rport' parameter [10] in its 656 Via header field value, and send from the port it is prepared to 657 receive on. More general information about NAT traversal in SIP 658 is described in [22]. 660 4.4. Detecting Flow Failure 662 The UA needs to detect when a specific flow fails. The UA actively 663 tries to detect failure by periodically sending keepalive messages 664 using one of the techniques described in Section 4.4.1 or 665 Section 4.4.2. If a flow has failed, the UA follows the procedures 666 in Section 4.2 to form a new flow to replace the failed one. 668 The time between keepalive requests when using UDP-based transports 669 SHOULD be a random number between 24 and 29 seconds while for TCP- 670 based transports it SHOULD be a random number between 95 and 120 671 seconds. These times MAY be configurable. Issues such as battery 672 consumption might motivate longer keepalive intervals. 674 Note on selection of time values: For UDP, the upper bound of 29 675 seconds was selected so that multiple STUN packets could be sent 676 before 30 seconds based on information that many NATs have UDP 677 timeouts as low as 30 seconds. The 24 second lower bound was 678 selected so that after 10 minutes the jitter introduced by 679 different timers will make the keepalive requests unsynchronized 680 to evenly spread the load on the servers. For TCP, the 120 681 seconds upper bound was chosen based on the idea that for a good 682 user experience, failures normally will be detected in this amount 683 of time and a new connection set up. Operators that wish to 684 change the relationship between load on servers and the expected 685 time that a user might not receive inbound communications will 686 probably adjust this time. The 95 seconds lower bound was chosen 687 so that the jitter introduced will result in a relatively even 688 load on the servers after 30 minutes. 690 4.4.1. Keepalive with TCP KEEPALIVE 692 User Agents that are capable of generating per-connection TCP 693 keepalives with timer values consistent with those in this section 694 MAY use TCP keepalives instead of using STUN keepalives for TCP-based 695 flows. 697 4.4.2. Keepalive with STUN 699 User Agents that form flows, check if the configured URI they are 700 connecting to has a 'keepalive' URI parameter (defined in Section 12) 701 with the value of 'stun'. If the parameter is present and the UA is 702 not already performing keepalives using another supported mechanism, 703 the UA needs to periodically perform keepalive checks by sending STUN 704 [4] Binding Requests over the flow as described in Section 8. 706 If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the 707 UA MUST treat this event as a failure on the flow. 709 4.4.3. Flow Recovery 711 When a flow to a particular URI in the outbound-proxy-set fails, the 712 UA needs to form a new flow to replace the old flow and replace any 713 registrations that were previously sent over this flow. Each new 714 registration MUST have the same reg-id as the registration it 715 replaces. This is done in much the same way as forming a brand new 716 flow as described in Section 4.2; however, if there is a failure in 717 forming this flow, the UA needs to wait a certain amount of time 718 before retrying to form a flow to this particular next hop. 720 The amount of time to wait depends if the previous attempt at 721 establishing a flow was successful. For the purposes of this 722 section, a flow is considered successful if outbound registration 723 succeeded and keepalives have not timed out for min-regtime seconds 724 (default of 120 seconds) after a registration. For STUN-based 725 keepalives, this means three successful STUN transactions over UDP or 726 one successful STUN transaction over TCP. If a flow is established 727 and is alive after this amount of time, the number of consecutive 728 registration failures is set to zero. Each time a flow fails before 729 two minutes, the number of consecutive registration failures is 730 incremented by one. Note that a failure during the initial STUN 731 validation does not count against the number of consecutive 732 registration failures. 734 The number of seconds to wait is computed in the following way. If 735 all of the flows to every URI in the outbound proxy set have failed, 736 the base time is set to 30 seconds; otherwise, in the case where at 737 least one of the flows has not failed, the base time is set to 90 738 seconds. The wait time is computed by taking two raised to the power 739 of the number of consecutive registration failures for that URI, and 740 multiplying this by the base time, up to a maximum of 1800 seconds. 742 wait-time = min( max-time, (base-time * (2 ^ consecutive-failures))) 744 These times MAY be configurable in the UA. The four times are: 745 o max-time with a default of 1800 seconds 746 o base-time-all-fail with a default of 30 seconds 747 o base-time-not-failed with a default of 90 seconds 748 o min-regtime with a default of 120 seconds 749 For example, if the base time is 30 seconds, and there were three 750 failures, then the wait time is min(1800,30*(2^3)) or 240 seconds. 751 The delay time is computed by selecting a uniform random time between 752 50 and 100 percent of the wait time. The UA MUST wait for the value 753 of the delay time before trying another registration to form a new 754 flow for that URI. 756 To be explicitly clear on the boundary conditions: when the UA boots 757 it immediately tries to register. If this fails and no registration 758 on other flows succeed, the first retry happens somewhere between 30 759 and 60 seconds after the failure of the first registration request. 760 If the number of consecutive-failures is large enough that the 761 maximum of 1800 seconds is reached, the UA will keep trying 762 indefinitely with a random time of 15 to 30 minutes between each 763 attempt. 765 5. Edge Proxy Mechanisms 767 5.1. Processing Register Requests 769 When an Edge Proxy receives a registration request with a reg-id 770 header parameter in the Contact header field, it needs to determine 771 if it (the edge proxy) will have to be visited for any subsequent 772 requests sent to the user agent identified in the Contact header 773 field, or not. If the Edge Proxy determines that this is the case, 774 it inserts its URI in a Path header field value as described in RFC 775 3327 [3]. If the Edge Proxy is the first SIP node after the UAC, it 776 either MUST store a "flow token"--containing information about the 777 flow from the previous hop--in its Path URI, or reject the request. 778 The flow token MUST be an identifier that is unique to this network 779 flow. The flow token MAY be placed in the userpart of the URI. In 780 addition, the first node MUST include an 'ob' URI parameter in its 781 Path header field value. If the Edge Proxy is not the first SIP node 782 after the UAC it MUST NOT place an 'ob' URI parameter in a Path 783 header field value. The Edge Proxy can determine if it is the first 784 hop by examining the Via header field. 786 5.2. Generating Flow Tokens 788 A trivial but impractical way to satisfy the flow token requirement 789 in Section 5.1 involves storing a mapping between an incrementing 790 counter and the connection information; however this would require 791 the Edge Proxy to keep an impractical amount of state. It is unclear 792 when this state could be removed and the approach would have problems 793 if the proxy crashed and lost the value of the counter. Two 794 stateless examples are provided below. A proxy can use any algorithm 795 it wants as long as the flow token is unique to a flow, the flow can 796 be recovered from the token, and the token can not be modified by 797 attackers. 799 Algorithm 1: The proxy generates a flow token for connection- 800 oriented transports by concatenating the file descriptor (or 801 equivalent) with the NTP time the connection was created, and 802 base64 encoding the result. This results in an identifier 803 approximately 16 octets long. The proxy generates a flow token 804 for UDP by concatenating the file descriptor and the remote IP 805 address and port, then base64 encoding the result. (No NTP time 806 is needed for UDP.) This algorithm MUST NOT be used unless all 807 messages between the Edge proxy and Registrar use a SIPS protected 808 transport. If the SIPS level of integrity protection is not 809 available, an attacker can hijack another user's calls. 811 Algorithm 2: When the proxy boots it selects a 20-octet crypto 812 random key called K that only the Edge Proxy knows. A byte array, 813 called S, is formed that contains the following information about 814 the flow the request was received on: an enumeration indicating 815 the protocol, the local IP address and port, the remote IP address 816 and port. The HMAC of S is computed using the key K and the HMAC- 817 SHA1-80 algorithm, as defined in [11]. The concatenation of the 818 HMAC and S are base64 encoded, as defined in [12], and used as the 819 flow identifier. When using IPv4 addresses, this will result in a 820 32-octet identifier. 822 5.3. Forwarding Requests 824 When an Edge Proxy receives a request, it applies normal routing 825 procedures with the following addition. If the Edge Proxy receives a 826 request where the edge proxy is the host in the topmost Route header 827 field value, and the Route header contains a flow token, the proxy 828 compares the flow in the flow token with the source of the request. 829 If these refer to the same flow, the Edge Proxy removes the Route 830 header and continues processing the request. Otherwise, if the top- 831 most Route header refers to the Edge Proxy and contains a valid flow 832 identifier token created by this proxy, the proxy MUST remove the 833 Route header and forward the request over the 'logical flow' 834 identified by the flow token, that is known to deliver data to the 835 specific target UA instance. For connection-oriented transports, if 836 the flow no longer exists the proxy SHOULD send a 430 (Flow Failed) 837 response to the request. 839 The advantage to a stateless approach to managing the flow 840 information is that there is no state on the Edge Proxy that 841 requires clean up or that has to be synchronized with the 842 registrar. 844 Proxies which used one of the two algorithms described in this 845 document to form a flow token follow the procedures below to 846 determine the correct flow. 848 Algorithm 1: The proxy base64 decodes the user part of the Route 849 header. For a TCP-based transport, if a connection specified by 850 the file descriptor is present and the creation time of the file 851 descriptor matches the creation time encoded in the Route header, 852 the proxy forwards the request over that connection. For a UDP- 853 based transport, the proxy forwards the request from the encoded 854 file descriptor to the source IP address and port. 856 Algorithm 2: To decode the flow token, take the flow identifier in 857 the user portion of the URI and base64 decode it, then verify the 858 HMAC is correct by recomputing the HMAC and checking it matches. 859 If the HMAC is not correct, the proxy SHOULD send a 403 860 (Forbidden) response. If the HMAC is correct then the proxy 861 SHOULD forward the request on the flow that was specified by the 862 information in the flow identifier. If this flow no longer 863 exists, the proxy SHOULD send a 430 (Flow Failed) response to the 864 request. 866 Note that this specification needs mid-dialog requests to be routed 867 over the same flows as those stored in the Path vector from the 868 initial registration, but techniques to ensure that mid-dialog 869 requests are routed over an existing flow are not part of this 870 specification. However, an approach such as having the Edge Proxy 871 Record-Route with a flow token is one way to ensure that mid-dialog 872 requests are routed over the correct flow. 874 5.4. Edge Proxy Keepalive Handling 876 All edge proxies compliant with this specification MUST implement 877 support for the STUN NAT Keepalive usage on its SIP ports as 878 described in Section 8. 880 6. Registrar Mechanisms: Processing REGISTER Requests 882 This specification updates the definition of a binding in RFC 3261 883 [1] Section 10 and RFC 3327 [3] Section 5.3. 885 When no +sip.instance media feature parameter is present in a Contact 886 header field value in a REGISTER request, the corresponding binding 887 is still between an AOR and the URI from that Contact header field 888 value. When a +sip.instance media feature parameter is present in a 889 Contact header field value in a REGISTER request, the corresponding 890 binding is between an AOR and the combination of the instance-id 891 (from the +sip.instance media feature parameter) and the value of 892 reg-id parameter if it is present. For a binding with an 893 instance-id, the registrar still stores the Contact header field 894 value URI with the binding, but does not consider the Contact URI for 895 comparison purposes. A Contact header field value with an 896 instance-id but no reg-id is valid, but one with a reg-id but no 897 instance-id is not. If the registrar processes a Contact header 898 field value with a reg-id but no instance-id, it simply ignores the 899 reg-id parameter. The registrar MUST be prepared to receive, 900 simultaneously for the same AOR, some registrations that use 901 instance-id and reg-id and some registrations that do not. 903 Registrars which implement this specification MUST support the Path 904 header mechanism [3]. 906 In addition to the normal information stored in the binding record, 907 some additional information needs to be stored for any registration 908 that contains an instance-id and a reg-id header parameter in the 909 Contact header field value. First the registrar examines the first 910 Path header field value, if any. If the Path header field exists and 911 the first URI does not have an 'ob' URI parameter, the registrar MUST 912 ignore the reg-id parameter and continue processing the request as if 913 it did not support this specification. Likewise if the REGISTER 914 request visited an edge proxy, but no Path header field values are 915 present, the registrar MUST ignore the reg-id parameter. 916 Specifically, the registrar MUST use RFC 3261 Contact binding rules, 917 and MUST NOT include the 'outbound' option-tag in its Supported 918 header field. The registrar can determine if it is the first hop by 919 examining the Via header field. 921 If the UAC has a direct flow with the registrar, the registrar MUST 922 store enough information to uniquely identify the network flow over 923 which the request arrived. For common operating systems with TCP, 924 this would typically just be the handle to file descriptor where the 925 handle would become invalid if the TCP session was closed. For 926 common operating systems with UDP this would typically be the file 927 descriptor for the local socket that received the request, the local 928 interface, and the IP address and port number of the remote side that 929 sent the request. The registrar MAY store this information by adding 930 itself to the Path header field with an appropriate flow token. 932 The registrar MUST also store all the Contact header field 933 information including the reg-id and instance-id parameters and 934 SHOULD also store the time at which the binding was last updated. If 935 a Path header field is present, RFC 3327 [3] requires the registrar 936 to store this information as well. If the registrar receives a re- 937 registration, it MUST update any information that uniquely identifies 938 the network flow over which the request arrived if that information 939 has changed, and SHOULD update the time the binding was last updated. 941 The Registrar MUST include the 'outbound' option-tag (defined in 942 Section (Section 12.1)) in a Supported header field value in its 943 responses to REGISTER requests for which it has performed outbound 944 processing. The Registrar MAY be configured with local policy to 945 reject any registrations that do not include the instance-id and 946 reg-id. Note that the requirements in this section applies to both 947 REGISTER requests received from an Edge Proxy as well as requests 948 received directly from the UAC. 950 To be compliant with this specification, registrars which can receive 951 SIP requests directly from a UAC without intervening edge proxies 952 MUST implement the STUN NAT Keepalive usage on its SIP ports as 953 described in Section 8. 955 7. Authoritative Proxy Mechanisms: Forwarding Requests 957 When a proxy uses the location service to look up a registration 958 binding and then proxies a request to a particular contact, it 959 selects a contact to use normally, with a few additional rules: 961 o The proxy MUST NOT populate the target set with more than one 962 contact with the same AOR and instance-id at a time. If a request 963 for a particular AOR and instance-id fails with a 430 (Flow 964 Failed) response, the proxy SHOULD replace the failed branch with 965 another target (if one is available) with the same AOR and 966 instance-id, but a different reg-id. 967 o If the proxy receives a final response from a branch other than a 968 408 (Request Timeout) or a 430 (Flow Failed) response, the proxy 969 MUST NOT forward the same request to another target representing 970 the same AOR and instance-id. The targeted instance has already 971 provided its response. 973 The proxy uses normal forwarding rules looking at the next-hop target 974 of the message and the value of any stored Path header field vector 975 in the registration binding to decide how to forward the request and 976 populate the Route header in the request. If the proxy stored 977 information about the flow over which it received the REGISTER for 978 the binding, then the proxy MUST send the request over the same 979 'logical flow' saved with the binding that is known to deliver data 980 to the specific target UA instance. 982 Typically this means that for TCP, the request is sent on the same 983 TCP socket that received the REGISTER request. For UDP, the 984 request is sent from the same local IP address and port over which 985 the registration was received, to the same IP address and port 986 from which the REGISTER was received. 988 If a proxy or registrar receives information from the network that 989 indicates that no future messages will be delivered on a specific 990 flow, then the proxy MUST invalidate all the bindings in the target 991 set that use that flow (regardless of AOR). Examples of this are a 992 TCP socket closing or receiving a destination unreachable ICMP error 993 on a UDP flow. Similarly, if a proxy closes a file descriptor, it 994 MUST invalidate all the bindings in the target set with flows that 995 use that file descriptor. 997 8. STUN Keepalive Processing 999 This section describes changes to the SIP transport layer that allow 1000 SIP and the STUN [4] NAT Keepalive usage to be mixed over the same 1001 flow. The STUN messages are used to verify connectivity is still 1002 available over a flow and to provide periodic keepalives. Note that 1003 these STUN keepalives are always sent to the next SIP hop. STUN 1004 messages are not delivered end-to-end. 1006 The only STUN messages required by this usage are Binding Requests, 1007 Binding Responses, and Error Responses. The UAC sends Binding 1008 Requests over the same UDP flow, TCP connection, or TLS channel used 1009 for sending SIP messages. These Binding Requests do not require any 1010 STUN attributes. The UAS responds to a valid Binding Request with a 1011 Binding Response which MUST include the XOR-MAPPED-ADDRESS attribute. 1012 After a successful STUN response is received over TCP or TLS over 1013 TCP, the underlying TCP connection is left in the active state. 1015 If a server compliant to this section receives SIP requests on a 1016 given interface and port, it MUST also provide a limited version of a 1017 STUN server on the same interface and port as described in Section 1018 12.3 of [4]. When STUN messages are sent with a SIP over TLS over 1019 TCP flow, the STUN messages are sent inside the TLS-protected 1020 channel. 1022 It is easy to distinguish STUN and SIP packets sent over UDP, 1023 because the first octet of a STUN packet has a value of 0 or 1 1024 while the first octet of a SIP message is never a 0 or 1. For TCP 1025 or TLS over TCP flows, determining if the first octet of the next 1026 message in a stream is SIP or STUN is still straightforward. As 1027 with any stream-based protocol, implementations need to be 1028 prepared to receive STUN messages which cross a stream buffer 1029 boundary, and SIP and STUN messages which share the same stream 1030 buffer. 1032 Because sending and receiving binary STUN data on the same ports used 1033 for SIP is a significant and non-backwards compatible change to RFC 1034 3261, this section requires a number of checks before sending STUN 1035 messages to a SIP node. If a SIP node sends STUN requests (for 1036 example due to misconfiguration) despite these warnings, the node 1037 could be blacklisted for UDP traffic, or cause its TCP server to 1038 loose framing over its connection. For each target node (as 1039 determined by IP address, address family, and port number), the 1040 sender needs to determine if that destination is validated to support 1041 STUN, that it does not support STUN, or that it needs to be 1042 validated. 1044 When a URI is created that refers to a SIP node that supports STUN as 1045 described in this section, the 'keepalive' URI parameter, as defined 1046 in Section 12 SHOULD be added to the URI, with a value of 'stun'. 1047 This allows a UA to inspect the URI to decide if it should attempt to 1048 send STUN requests to this location. For example, an edge proxy 1049 could insert this parameter into its Path URI so that the registering 1050 UA can discover the edge proxy supports STUN keepalives. 1052 A SIP node MUST NOT send STUN requests over a flow unless it has an 1053 explicit indication that the target next hop SIP server claims to 1054 support STUN. For example, automatic or manual configuration of an 1055 outbound-proxy-set which contains the keepalive=stun parameter is 1056 considered sufficient explicit indication. Note that UACs MUST NOT 1057 use an ambiguous configuration option such as "Work through NATs?" or 1058 "Do Keepalives?" to imply next hop STUN support. A SIP node MAY also 1059 probe the next hop using a SIP OPTIONS request to check for support 1060 of the 'sip-stun' option tag in a Supported header field. 1062 Furthermore, even with explicit indication of next hop STUN support, 1063 a SIP node needs to validate support for STUN the first time it sends 1064 traffic to a specific invalidated target destination. A SIP node MAY 1065 send one STUN request and its retransmissions to an invalidated 1066 destination. If a STUN request ever succeeds to a destination, that 1067 destination is thereafter validated for STUN support. If this 1068 initial STUN request does not result in a STUN response, the SIP node 1069 MUST NOT send additional STUN requests over this flow, unless a next- 1070 hop probe later validates the destination. In addition, the SIP node 1071 SHOULD remember invalidated destination nodes that have been used 1072 within one hour and SHOULD NOT send additional STUN messages to any 1073 of these destinations. 1075 If this initial STUN request does not result in a STUN response, the 1076 UA MAY send and explicit next-hop probe as described in Section 8.1. 1077 If an explicit probe indicates support for the 'sip-stun' option-tag, 1078 that destination is validated for STUN support. If an explicit probe 1079 does not indicate support for the 'sip-stun' option-tag, the target 1080 destination does not support STUN request, and the UAC MUST NOT send 1081 further STUN requests to this destination. 1083 Note that until STUN support has been verified, an initial STUN 1084 failure over UDP is not considered a flow failure. For UDP flows, an 1085 invalidated flow can still be reused for SIP traffic, however for 1086 invalidated TCP or TLS over TCP flows, the connection over which STUN 1087 requests were sent MUST be closed. 1089 Typically, a SIP node first sends a SIP request and waits to 1090 receive a final response (other than a 408 response) over a flow 1091 to a new target destination, before sending any STUN messages. 1092 When scheduled for the next NAT refresh, the SIP node sends a STUN 1093 request to the target. If none of the STUN requests succeed 1094 (result in a STUN success response), and the UAC has not already 1095 done so, the UAC sends an OPTIONS request to the next hop to 1096 verify support for the 'sip-stun' option-tag. 1098 Once a destination is validated to support STUN messages, failure of 1099 a STUN request (including its retransmissions) is considered a 1100 failure of the underlying flow. For SIP over UDP flows, if the XOR- 1101 MAPPED-ADDRESS returned over the flow changes, this indicates that 1102 the underlying connectivity has changed, and is considered a flow 1103 failure. A 408 response to a next-hop OPTIONS probe is also 1104 considered a flow failure. 1106 Note that failure of a flow causes a new flow to be formed and that 1107 the STUN validation needs to be done for this new flow even if it is 1108 to a destination that had previously been validated for STUN. 1110 8.1. Explicit Probes 1112 This section defines a new SIP option-tag called 'sip-stun'. 1113 Advertising this option-tag indicates that the server can receive SIP 1114 messages and STUN messages as part of the NAT Keepalive usage on the 1115 same port. Clients that want to probe a SIP server to determine 1116 support for STUN, can send an OPTIONS request to the next hop by 1117 setting the Max-Forwards header field to zero or addressing the 1118 request to that server. The OPTIONS response will contain a 1119 Supported header field with a list of the server's supported option- 1120 tags. 1122 A UAC SHOULD NOT include the 'sip-stun' option-tag in a Proxy- 1123 Require header. This is because a request with this header will 1124 fail in some topologies where the first proxy support sip-stun, 1125 but a subsequent proxy does not. Note that RFC 3261 does not 1126 allow proxies to remove option-tags from a Proxy-Require header 1127 field. 1129 8.2. Use with Sigcomp 1131 When STUN is used together with SigComp [23] compressed SIP messages 1132 over the same flow, how the STUN messages are sent depends on the 1133 transport protocol. For UDP flows, the STUN messages are simply sent 1134 uncompressed, "outside" of SigComp. This is supported by 1135 multiplexing STUN messages with SigComp messages by checking the two 1136 topmost bits of the message. These bits are always one for SigComp, 1137 or zero for STUN. 1139 All SigComp messages contain a prefix (the five most-significant 1140 bits of the first byte are set to one) that does not occur in 1141 UTF-8 encoded text messages [RFC-2279], so for applications which 1142 use this encoding (or ASCII encoding) it is possible to multiplex 1143 uncompressed application messages and SigComp messages on the same 1144 UDP port. 1145 The most significant two bits of every STUN message are both 1146 zeroes. This, combined with the magic cookie, aids in 1147 differentiating STUN packets from other protocols when STUN is 1148 multiplexed with other protocols on the same port. 1150 For TCP-based flows, SigComp requires that all messages are processed 1151 by the SigComp compressor to facilitate framing. For these 1152 transports, STUN messages are sent encapsulated in the SigComp "well- 1153 known shim header" as described in Section 11 of [24]. 1155 Because the bytecodes expressed in the well-known shim header do 1156 not store any state, correlation of such SigComp requests to a 1157 compartment is not necessary. To avoid ambiguity, we add the 1158 following requirement: any SigComp state that might result from a 1159 message that, once decompressed, turns out to be a STUN message, 1160 MUST be discarded. 1162 9. Example Message Flow 1164 The following call flow shows a basic registration and an incoming 1165 call. At some point, the flow to the Primary proxy is lost. An 1166 incoming INVITE tries to reach the Callee through the Primary flow, 1167 but receives an ICMP Unreachable message. The Caller retries using 1168 the Secondary Edge Proxy, which uses a separate flow. Later, after 1169 the Primary reboots, The Callee discovers the flow failure and 1170 reestablishes a new flow to the Primary. 1172 [-----example.com domain -------------------] 1173 Caller Secondary Primary Callee 1174 | | | (1) REGISTER | 1175 | | |<-----------------| 1176 | | |(2) 200 OK | 1177 | | |----------------->| 1178 | | | (3) REGISTER | 1179 | |<------------------------------------| 1180 | |(4) 200 OK | | 1181 | |------------------------------------>| 1182 | | | | 1183 | | CRASH X | 1184 |(5) INVITE | | | 1185 |----------------------------------->| | 1186 |(6) ICMP Unreachable | | 1187 |<-----------------------------------| | 1188 |(7) INVITE | | | 1189 |---------------->| | | 1190 | |(8) INVITE | | 1191 | |------------------------------------>| 1192 | |(9) 200 OK | | 1193 | |<------------------------------------| 1194 |(10) 200 OK | | | 1195 |<----------------| | | 1196 |(11) ACK | | | 1197 |---------------->| | | 1198 | |(12) ACK | | 1199 | |------------------------------------>| 1200 | | | | 1201 | | REBOOT | | 1202 | | |(13) REGISTER | 1203 | | |<-----------------| 1204 | | |(14) 200 OK | 1205 | | |----------------->| 1206 | | | | 1207 |(15) BYE | | | 1208 |---------------->| | | 1209 | | (16) BYE | | 1210 | |------------------------------------>| 1211 | | | (17) 200 OK | 1212 | |<------------------------------------| 1213 | (18) 200 OK | | | 1214 |<----------------| | | 1215 | | | | 1217 This call flow assumes that the Callee has been configured with a 1218 proxy set that consists of "sip:pri.example.com;lr;keepalive=stun" 1219 and "sip:sec.example.com;lr;keepalive=stun". The Callee REGISTER in 1220 message (1) looks like: 1222 REGISTER sip:example.com SIP/2.0 1223 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1224 Max-Forwards: 70 1225 From: Callee ;tag=7F94778B653B 1226 To: Callee 1227 Call-ID: 16CB75F21C70 1228 CSeq: 1 REGISTER 1229 Supported: path 1230 Route: 1231 Contact: 1232 ;+sip.instance="" 1233 ;reg-id=1 1234 Content-Length: 0 1236 In the message, note that the Route is set and the Contact header 1237 field value contains the instance-id and reg-id. The response to the 1238 REGISTER in message (2) would look like: 1240 SIP/2.0 200 OK 1241 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1242 From: Callee ;tag=7F94778B653B 1243 To: Callee ;tag=6AF99445E44A 1244 Call-ID: 16CB75F21C70 1245 CSeq: 1 REGISTER 1246 Supported: outbound 1247 Contact: 1248 ;+sip.instance="" 1249 ;reg-id=1 1250 ;expires=3600 1251 Content-Length: 0 1253 The second registration in message 3 and 4 are similar other than the 1254 Call-ID has changed, the reg-id is 2, and the route is set to the 1255 secondary instead of the primary. They look like: 1257 REGISTER sip:example.com SIP/2.0 1258 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnqr9bym 1259 Max-Forwards: 70 1260 From: Callee ;tag=755285EABDE2 1261 To: Callee 1262 Call-ID: E05133BD26DD 1263 CSeq: 1 REGISTER 1264 Supported: path 1265 Route: 1266 Contact: 1267 ;+sip.instance="" 1268 ;reg-id=2 1269 Content-Length: 0 1271 SIP/2.0 200 OK 1272 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnqr9bym 1273 From: Callee ;tag=755285EABDE2 1274 To: Callee ;tag=49A9AD0B3F6A 1275 Call-ID: E05133BD26DD 1276 Supported: outbound 1277 CSeq: 1 REGISTER 1278 Contact: 1279 ;+sip.instance="" 1280 ;reg-id=1 1281 ;expires=3600 1282 Contact: 1283 ;+sip.instance="" 1284 ;reg-id=2 1285 ;expires=3600 1286 Content-Length: 0 1288 The messages in the call flow are very normal. The only interesting 1289 thing to note is that the INVITE in message 8 contains a Record-Route 1290 header for the Secondary proxy, with its flow token. 1292 Record-Route: 1293 1295 The registrations in message 13 and 14 are the same as message 1 and 1296 2 other than the Call-ID and tags have changed. Because these 1297 messages will contain the same instance-id and reg-id as those in 1 1298 and 2, this flow will partially supersede that for messages 1 and 2 1299 and will be tried first by Primary. 1301 10. Grammar 1303 This specification defines new Contact header field parameters, 1304 reg-id and +sip.instance. The grammar includes the definitions from 1305 RFC 3261 [1] and includes the definition of uric from RFC 2396 [13]. 1307 Note: The "=/" syntax used in this ABNF indicates an extension of 1308 the production on the left hand side. 1310 The ABNF[14] is: 1312 contact-params =/ c-p-reg / c-p-instance 1314 c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to 2**31 1316 c-p-instance = "+sip.instance" EQUAL 1317 LDQUOT "<" instance-val ">" RDQUOT 1319 instance-val = *uric ; defined in RFC 2396 1321 The value of the reg-id MUST NOT be 0 and MUST be less than 2**31. 1323 11. Definition of 430 Flow Failed response code 1325 This specification defines a new SIP response code '430 Flow Failed'. 1326 This response code is used by an Edge Proxy to indicate to the 1327 Authoritative Proxy that a specific flow to a UA instance has failed. 1328 Other flows to the same instance could still succeed. The 1329 Authoritative Proxy SHOULD attempt to forward to another target 1330 (flow) with the same instance-id and AOR. 1332 12. IANA Considerations 1334 12.1. Contact Header Field 1336 This specification defines a new Contact header field parameter 1337 called reg-id in the "Header Field Parameters and Parameter Values" 1338 sub-registry as per the registry created by [15]. The required 1339 information is: 1341 Header Field Parameter Name Predefined Reference 1342 Values 1343 ____________________________________________________________________ 1344 Contact reg-id Yes [RFC AAAA] 1346 [NOTE TO RFC Editor: Please replace AAAA with 1347 the RFC number of this specification.] 1349 12.2. SIP/SIPS URI Parameters 1351 This specification arguments the "SIP/SIPS URI Parameters" sub- 1352 registry as per the registry created by [16]. The required 1353 information is: 1355 Parameter Name Predefined Values Reference 1356 ____________________________________________ 1357 keepalive stun [RFC AAAA] 1358 ob [RFC AAAA] 1360 [NOTE TO RFC Editor: Please replace AAAA with 1361 the RFC number of this specification.] 1363 12.3. SIP Option Tag 1365 This specification registers two new SIP option tags, as per the 1366 guidelines in Section 27.1 of RFC 3261. 1368 Name: outbound 1369 Description: This option-tag is used to identify Registrars which 1370 support extensions for Client Initiated Connections. A Registrar 1371 places this option-tag in a Supported header to communicate the 1372 Registrar's support for this extension to the registering User 1373 Agent. 1374 Name: sip-stun 1375 Description: This option-tag is used to identify SIP servers which 1376 can receive STUN requests described in the STUN NAT Keepalive 1377 usage on the same ports they use to receive SIP messages. 1379 12.4. Response Code 1381 This section registers a new SIP Response Code, as per the guidelines 1382 in Section 27.1 of RFC 3261. 1384 Code: 430 1385 Default Reason Phrase: Flow Failed 1386 Reference: This document 1388 12.5. Media Feature Tag 1390 This section registers a new media feature tag, per the procedures 1391 defined in RFC 2506 [17]. The tag is placed into the sip tree, which 1392 is defined in RFC 3840 [6]. 1394 Media feature tag name: sip.instance 1395 ASN.1 Identifier: New assignment by IANA. 1397 Summary of the media feature indicated by this tag: This feature tag 1398 contains a string containing a URN that indicates a unique identifier 1399 associated with the UA instance registering the Contact. 1401 Values appropriate for use with this feature tag: String. 1403 The feature tag is intended primarily for use in the following 1404 applications, protocols, services, or negotiation mechanisms: This 1405 feature tag is most useful in a communications application, for 1406 describing the capabilities of a device, such as a phone or PDA. 1408 Examples of typical use: Routing a call to a specific device. 1410 Related standards or documents: RFC XXXX 1412 [[Note to IANA: Please replace XXXX with the RFC number of this 1413 specification.]] 1415 Security Considerations: This media feature tag can be used in ways 1416 which affect application behaviors. For example, the SIP caller 1417 preferences extension [8] allows for call routing decisions to be 1418 based on the values of these parameters. Therefore, if an attacker 1419 can modify the values of this tag, they might be able to affect the 1420 behavior of applications. As a result, applications which utilize 1421 this media feature tag SHOULD provide a means for ensuring its 1422 integrity. Similarly, this feature tag should only be trusted as 1423 valid when it comes from the user or user agent described by the tag. 1424 As a result, protocols for conveying this feature tag SHOULD provide 1425 a mechanism for guaranteeing authenticity. 1427 13. Security Considerations 1429 One of the key security concerns in this work is making sure that an 1430 attacker cannot hijack the sessions of a valid user and cause all 1431 calls destined to that user to be sent to the attacker. 1433 The simple case is when there are no edge proxies. In this case, the 1434 only time an entry can be added to the routing for a given AOR is 1435 when the registration succeeds. SIP already protects against 1436 attackers being able to successfully register, and this scheme relies 1437 on that security. Some implementers have considered the idea of just 1438 saving the instance-id without relating it to the AOR with which it 1439 registered. This idea will not work because an attacker's UA can 1440 impersonate a valid user's instance-id and hijack that user's calls. 1442 The more complex case involves one or more edge proxies. When a UA 1443 sends a REGISTER request through an Edge Proxy on to the registrar, 1444 the Edge Proxy inserts a Path header field value. If the 1445 registration is successfully authenticated, the registrar stores the 1446 value of the Path header field. Later when the registrar forwards a 1447 request destined for the UA, it copies the stored value of the Path 1448 header field into the Route header field of the request and forwards 1449 the request to the Edge Proxy. 1451 The only time an Edge Proxy will route over a particular flow is when 1452 it has received a Route header that has the flow identifier 1453 information that it has created. An incoming request would have 1454 gotten this information from the registrar. The registrar will only 1455 save this information for a given AOR if the registration for the AOR 1456 has been successful; and the registration will only be successful if 1457 the UA can correctly authenticate. Even if an attacker has spoofed 1458 some bad information in the Path header sent to the registrar, the 1459 attacker will not be able to get the registrar to accept this 1460 information for an AOR that does not belong to the attacker. The 1461 registrar will not hand out this bad information to others, and 1462 others will not be misled into contacting the attacker. 1464 14. Operational Notes on Transports 1466 RFC 3261 requires proxies, registrars, and UA to implement both TCP 1467 and UDP but deployments can chose which protocols they want to use. 1468 Deployments need to be careful in choosing what transports to use. 1469 Many SIP features and extensions, such as large presence 1470 subscriptions packages, result in SIP requests that can be too large 1471 to be reasonably transported over UDP. RFC 3261 has an option of 1472 when a request is too large for UDP, the device sending the request 1473 can attempt to switch over to TCP. No known deployments currently 1474 use this but it is important to note that when using outbound, this 1475 will only work if the UA has formed both a UDP and TCP outbound 1476 connection. The specification allows the UA to do this but in most 1477 cases it will probably make more sense to only form TCP outbound 1478 connection than forming both UDP and TCP. One of the key reasons 1479 that many deployments choose not to use TCP has to do with the 1480 difficulty of building proxies that can maintain a very large number 1481 of active TCP connections. Many deployments today use SIP in such a 1482 way that the message are small enough that they work over UDP but 1483 they can not take advantage of all the functionality SIP offers. 1484 Deployments that use only UDP outbound connections are going to fail 1485 with sufficiently large SIP messages. 1487 15. Requirements 1489 This specification was developed to meet the following requirements: 1491 1. Must be able to detect that a UA supports these mechanisms. 1492 2. Support UAs behind NATs. 1493 3. Support TLS to a UA without a stable DNS name or IP address. 1494 4. Detect failure of a connection and be able to correct for this. 1495 5. Support many UAs simultaneously rebooting. 1496 6. Support a NAT rebooting or resetting. 1497 7. Minimize initial startup load on a proxy. 1498 8. Support architectures with edge proxies. 1500 16. Changes 1502 Note to RFC Editor: Please remove this whole section. 1504 16.1. Changes from 06 Version 1506 Added the section on operational selection of transports. 1508 Fixed various editorial typos. 1510 Put back in requirement flow token needs to be unique to flow as it 1511 had accidentally been dropped in earlier version. This did not 1512 change any of the flow token algorithms. 1514 Reordered some of the text on STUN keepalive validation to make it 1515 clearer to implementors. Did not change the actual algorithm or 1516 requirements. Added note to explain how if the proxy changes, the 1517 revalidation will happen. 1519 16.2. Changes from 05 Version 1521 Mention the relevance of the 'rport' parameter. 1523 Change registrar verification so that only first-hop proxy and the 1524 registrar need to support outbound. Other intermediaries in between 1525 do not any more. 1527 Relaxed flow-token language slightly. Instead of flow-token saving 1528 specific UDP address/port tuples over which the request arrived, make 1529 language fuzzy to save token which points to a 'logical flow' that is 1530 known to deliver data to that specific UA instance. 1532 Added comment that keepalive=stun could be added to Path. 1534 Added comment that battery concerns could motivate longer TCP 1535 keepalive intervals than the defaults. 1537 Scrubbed document for avoidable lowercase mays, shoulds, and musts. 1539 Added text about how Edge Proxies could determine they are the first 1540 hop. 1542 16.3. Changes from 04 Version 1544 Moved STUN to a separate section. Reference this section from within 1545 the relevant sections in the rest of the document. 1547 Add language clarifying that UA MUST NOT send STUN without an 1548 explicit indication the server supports STUN. 1550 Add language describing that UA MUST stop sending STUN if it appears 1551 the server does not support it. 1553 Defined a 'sip-stun' option tag. UAs can optionally probe servers 1554 for it with OPTIONS. Clarified that UAs SHOULD NOT put this in a 1555 Proxy-Require. Explain that the first-hop MUST support this option- 1556 tag. 1558 Clarify that SIP/STUN in TLS is on the "inside". STUN used with 1559 Sigcomp-compressed SIP is "outside" the compression layer for UDP, 1560 but wrapped inside the well-known shim header for TCP-based 1561 transports. 1563 Clarify how to decide what a consecutive registration timer is. Flow 1564 must be up for some time (default 120 seconds) otherwise previous 1565 registration is not considered successful. 1567 Change UAC MUST-->SHOULD register a flow for each member of outbound- 1568 proxy-set. 1570 Reworded registrar and proxy in some places (introduce the term 1571 "Authoritative Proxy"). 1573 Loosened restrictions on always storing a complete Path vector back 1574 to the registrar/authoritative proxy if a previous hop in the path 1575 vector is reachable. 1577 Added comment about reregistration typically happening over same flow 1578 as original registration. 1580 Changed 410 Gone to new response code 430 Flow Failed. Was going to 1581 change this to 480 Temporarily Unavailable. Unfortunately this would 1582 mean that the authoritative proxy deletes all flows of phones who use 1583 480 for Do Not Disturb. Oops! 1585 Restored sanity by restoring text which explains that registrations 1586 with the same reg-id replace the old registration. 1588 Added text about the 'ob' parameter which is used in Path header 1589 field URIs to make sure that the previous proxy that added a Path 1590 understood outbound processing. The registrar doesn't include 1591 Supported: outbound unless it could actually do outbound processing 1592 (ex: any Path headers have to have the 'ob' parameter). 1594 Added some text describing what a registration means when there is an 1595 instance-id, but no reg-id. 1597 16.4. Changes from 03 Version 1599 Added non-normative text motivating STUN vs. SIP PING, OPTIONS, and 1600 Double CRLF. Added discussion about why TCP Keepalives are not 1601 always available. 1603 Explained more clearly that outbound-proxy-set can be "configured" 1604 using any current or future, manual or automatic configuration/ 1605 discovery mechanism. 1607 Added a sentence which prevents an Edge Proxy from forwarding back 1608 over the flow over which the request is received if the request 1609 happens to contain a flow token for that flow. This was an 1610 oversight. 1612 Updated example message flow to show a failover example using a new 1613 dialog-creating request instead of a mid-dialog request. The old 1614 scenario was leftover from before the outbound/gruu reorganization. 1616 Fixed tags, Call-IDs, and branch parameters in the example messages. 1618 Made the ABNF use the "=/" production extension mechanism recommended 1619 by Bill Fenner. 1621 Added a table in an appendix expanding the default flow recovery 1622 timers. 1624 Incorporated numerous clarifications and rewordings for better 1625 comprehension. 1627 Fixed many typos and spelling steaks. 1629 16.5. Changes from 02 Version 1631 Removed Double CRLF Keepalive 1633 Changed ;sip-stun syntax to ;keepalive=stun 1635 Fixed incorrect text about TCP keepalives. 1637 16.6. Changes from 01 Version 1639 Moved definition of instance-id from GRUU[25] draft to this draft. 1641 Added tentative text about Double CRLF Keepalive 1643 Removed pin-route stuff 1645 Changed the name of "flow-id" to "reg-id" 1647 Reorganized document flow 1649 Described the use of STUN as a proper STUN usage 1651 Added 'outbound' option-tag to detect if registrar supports outbound 1653 16.7. Changes from 00 Version 1655 Moved TCP keepalive to be STUN. 1657 Allowed SUBSCRIBE to create flow mappings. Added pin-route option 1658 tags to support this. 1660 Added text about updating dialog state on each usage after a 1661 connection failure. 1663 17. Acknowledgments 1665 Jonathan Rosenberg provided many comments and useful text. Dave Oran 1666 came up with the idea of using the most recent registration first in 1667 the proxy. Alan Hawrylyshen co-authored the draft that formed the 1668 initial text of this specification. Additionally, many of the 1669 concepts here originated at a connection reuse meeting at IETF 60 1670 that included the authors, Jon Peterson, Jonathan Rosenberg, Alan 1671 Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of 1672 Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and 1673 Ganesh Jayadevan provided input and text. Nils Ohlmeier provided 1674 many fixes and initial implementation experience. In addition, 1675 thanks to the following folks for useful comments: Francois Audet, 1676 Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, Dale 1677 Worely, Juha Heinanen, Eric Rescorla, Lyndsay Campbell, and Erkki 1678 Koivusalo. 1680 Appendix A. Default Flow Registration Backoff Times 1682 The base-time used for the flow re-registration backoff times 1683 described in Section 4.4.3 are configurable. If the base-time-all- 1684 fail value is set to the default of 30 seconds and the base-time-not- 1685 failed value is set to the default of 90 seconds, the following table 1686 shows the resulting delay values. 1688 +-------------------+--------------------+--------------------+ 1689 | # of reg failures | all flows unusable | >1 non-failed flow | 1690 +-------------------+--------------------+--------------------+ 1691 | 0 | 0 secs | 0 secs | 1692 | 1 | 30-60 secs | 90-180 secs | 1693 | 2 | 1-2 mins | 3-6 mins | 1694 | 3 | 2-4 mins | 6-12 mins | 1695 | 4 | 4-8 mins | 12-24 mins | 1696 | 5 | 8-16 mins | 15-30 mins | 1697 | 6 or more | 15-30 mins | 15-30 mins | 1698 +-------------------+--------------------+--------------------+ 1700 18. References 1702 18.1. Normative References 1704 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1705 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1706 Session Initiation Protocol", RFC 3261, June 2002. 1708 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1709 Levels", BCP 14, RFC 2119, March 1997. 1711 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1712 Extension Header Field for Registering Non-Adjacent Contacts", 1713 RFC 3327, December 2002. 1715 [4] Rosenberg, J., "Simple Traversal Underneath Network Address 1716 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 1717 (work in progress), October 2006. 1719 [5] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 1720 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1722 [6] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1723 User Agent Capabilities in the Session Initiation Protocol 1724 (SIP)", RFC 3840, August 2004. 1726 [7] Moats, R., "URN Syntax", RFC 2141, May 1997. 1728 [8] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1729 Preferences for the Session Initiation Protocol (SIP)", 1730 RFC 3841, August 2004. 1732 [9] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1733 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1735 [10] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session 1736 Initiation Protocol (SIP) for Symmetric Response Routing", 1737 RFC 3581, August 2003. 1739 [11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1740 for Message Authentication", RFC 2104, February 1997. 1742 [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1743 RFC 3548, July 2003. 1745 [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1746 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1747 August 1998. 1749 [14] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1750 Specifications: ABNF", RFC 4234, October 2005. 1752 [15] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1753 Header Field Parameter Registry for the Session Initiation 1754 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1756 [16] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1757 Uniform Resource Identifier (URI) Parameter Registry for the 1758 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1759 December 2004. 1761 [17] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1762 Registration Procedure", BCP 31, RFC 2506, March 1999. 1764 18.2. Informative References 1766 [18] Petrie, D., "A Framework for Session Initiation Protocol User 1767 Agent Profile Delivery", draft-ietf-sipping-config-framework-09 1768 (work in progress), October 2006. 1770 [19] Hakala, J., "Using National Bibliography Numbers as Uniform 1771 Resource Names", RFC 3188, October 2001. 1773 [20] Rosenberg, J., "Construction of the Route Header Field in the 1774 Session Initiation Protocol (SIP)", 1775 draft-rosenberg-sip-route-construct-02 (work in progress), 1776 October 2006. 1778 [21] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1779 Extension Header Field for Service Route Discovery During 1780 Registration", RFC 3608, October 2003. 1782 [22] Boulton, C., "Best Current Practices for NAT Traversal for 1783 SIP", draft-ietf-sipping-nat-scenarios-05 (work in progress), 1784 June 2006. 1786 [23] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 1787 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 1788 RFC 3320, January 2003. 1790 [24] Surtees, A., "Implementer's Guide for SigComp", 1791 draft-ietf-rohc-sigcomp-impl-guide-08 (work in progress), 1792 October 2006. 1794 [25] Rosenberg, J., "Obtaining and Using Globally Routable User 1795 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1796 (SIP)", draft-ietf-sip-gruu-11 (work in progress), 1797 October 2006. 1799 Authors' Addresses 1801 Cullen Jennings (editor) 1802 Cisco Systems 1803 170 West Tasman Drive 1804 Mailstop SJC-21/2 1805 San Jose, CA 95134 1806 USA 1808 Phone: +1 408 902-3341 1809 Email: fluffy@cisco.com 1810 Rohan Mahy (editor) 1811 Plantronics 1812 345 Encincal St 1813 Santa Cruz, CA 95060 1814 USA 1816 Email: rohan@ekabal.com 1818 Full Copyright Statement 1820 Copyright (C) The Internet Society (2007). 1822 This document is subject to the rights, licenses and restrictions 1823 contained in BCP 78, and except as set forth therein, the authors 1824 retain all their rights. 1826 This document and the information contained herein are provided on an 1827 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1828 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1829 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1830 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1831 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1834 Intellectual Property 1836 The IETF takes no position regarding the validity or scope of any 1837 Intellectual Property Rights or other rights that might be claimed to 1838 pertain to the implementation or use of the technology described in 1839 this document or the extent to which any license under such rights 1840 might or might not be available; nor does it represent that it has 1841 made any independent effort to identify any such rights. Information 1842 on the procedures with respect to rights in RFC documents can be 1843 found in BCP 78 and BCP 79. 1845 Copies of IPR disclosures made to the IETF Secretariat and any 1846 assurances of licenses to be made available, or the result of an 1847 attempt made to obtain a general license or permission for the use of 1848 such proprietary rights by implementers or users of this 1849 specification can be obtained from the IETF on-line IPR repository at 1850 http://www.ietf.org/ipr. 1852 The IETF invites any interested party to bring to its attention any 1853 copyrights, patents or patent applications, or other proprietary 1854 rights that may cover technology that may be required to implement 1855 this standard. Please address the information to the IETF at 1856 ietf-ipr@ietf.org. 1858 Acknowledgment 1860 Funding for the RFC Editor function is provided by the IETF 1861 Administrative Support Activity (IASA).