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