idnits 2.17.1 draft-ietf-sip-outbound-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1219. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: This mechanism without a GRUU is not reliable if any of the proxies on the path fail so it SHOULD not be used for long lived subscriptions. Once a UA acquires an appropriate GRUU, it should terminate these subscriptions and re-subscribe using the normal GRUU based approach. -- 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 (October 23, 2005) is 6754 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 982 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-04 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-02 -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. '9') (Obsoleted by RFC 4648) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-07 == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-route-construct-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG C. Jennings, Ed. 3 Internet-Draft Cisco Systems 4 Expires: April 26, 2006 R. Mahy, Ed. 5 SIP Edge LLC 6 October 23, 2005 8 Managing Client Initiated Connections in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-outbound-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 26, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 Session Initiation Protocol (SIP) allows proxy servers to initiate 44 TCP connections and send asynchronous UDP datagrams to User Agents in 45 order to deliver requests. However, many practical considerations, 46 such as the existence of firewalls and NATs, prevent servers from 47 connecting to User Agents in this way. Even when a proxy server can 48 open a TCP connection to a User Agent, most User Agents lack a 49 certificate suitable to act as a TLS server. This specification 50 defines behaviors for User Agents, registrars and proxy servers that 51 allow requests to be delivered on existing connections established by 52 the User Agent. It also defines keep alive behaviors needed to keep 53 NAT bindings open and specifies the usage of multiple connections for 54 high availability systems. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 60 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 4 63 3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 5 64 3.3. Multiple Connections from a User Agent . . . . . . . . . . 6 65 3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.5. Keep Alive Technique . . . . . . . . . . . . . . . . . . . 9 67 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 10 68 4.1. Forming Flows . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1.1. Request without GRUU . . . . . . . . . . . . . . . . . 11 70 4.2. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 11 71 4.3. Flow Failure Recovery . . . . . . . . . . . . . . . . . . 12 72 4.4. Registration by Other Instances . . . . . . . . . . . . . 13 73 5. Registrar Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 74 5.1. Processing Register Requests . . . . . . . . . . . . . . . 13 75 5.2. Forwarding Requests . . . . . . . . . . . . . . . . . . . 14 76 6. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 15 77 6.1. Processing Register Requests . . . . . . . . . . . . . . . 15 78 6.2. Forwarding Requests . . . . . . . . . . . . . . . . . . . 16 79 7. Mechanisms for All Servers . . . . . . . . . . . . . . . . . . 17 80 7.1. STUN Processing . . . . . . . . . . . . . . . . . . . . . 17 81 7.2. Pin-Route Processing . . . . . . . . . . . . . . . . . . . 17 82 8. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 18 83 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 13. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 14. Changes from 00 Version . . . . . . . . . . . . . . . . . . . 24 89 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 16.1. Normative References . . . . . . . . . . . . . . . . . . . 25 92 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 94 Intellectual Property and Copyright Statements . . . . . . . . . . 28 96 1. Introduction 98 There are many environments for SIP deployments in which the User 99 Agent (UA) can form a connection to a Registrar or Proxy but in which 100 the connections in the reverse direction to the UA are not possible. 101 This can happen for several reasons. Connection to the UA can be 102 blocked by a firewall device between the UA and the proxy or 103 registrar, which will only allow new connections in the direction of 104 the UA to the Proxy. Similarly there may be a NAT, which are only 105 capable of allowing new connections from the private address side to 106 the public side. This specification allows SIP registration when the 107 UA is behind a firewall or NAT. 109 Most IP phones and personal computers get their network 110 configurations dynamically via a protocol such as DHCP. These 111 systems typically do not have a useful name in DNS, and they 112 definitely do not have a long-term, stable DNS name that is 113 appropriate for binding to a certificate. It is impractical for them 114 to have a certificate that can be used as a client-side TLS 115 certificate for SIP. However, these systems can still form TLS 116 connections to a proxy or registrar such that the UA authenticates 117 the server certificate, and the server authenticates the UA using a 118 shared secret in a digest challenge over that TLS connection. 120 The key idea of this specification is that when a UA sends a REGISTER 121 request, the proxy can later use this same connection, be it UDP, 122 TCP, or another transport protocol, to forward any requests that need 123 to go to this UA. For a UA to receive incoming requests, the UA has 124 to connect to the server. Since the server can't connect to the UA, 125 the UA has to make sure that a connection is always active. This 126 requires the UA to detect when a connection fails. Since, such 127 detection takes time and leaves a window of opportunity for missed 128 incoming requests, this mechanism allows the UA to use multiple 129 connections, referred to as "flows", to the proxy or registrar and 130 using a keep alive mechanism on each flow so that the UA can detect 131 when a flow has failed. 133 2. Conventions and Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [2]. 139 2.1. Definitions 140 Edge Proxy: An Edge Proxy is any proxy that is located topologically 141 between the registering User Agent and the registrar. 142 flow: A Flow is a network protocol layer connection between two hosts 143 that is represented by the network address of both ends and the 144 protocol. For TCP and UDP this would include the IP addresses and 145 ports of both ends and the protocol (TCP or UDP). With TCP, a 146 flow would often have a one to one correspondence with a single 147 file descriptor in the operating system. 148 flow-id: This refers to the value of a new header field parameter 149 value for the contact header. When a UA register multiple times, 150 each registration gets a unique flow-id value. This does not 151 refer to flow. 152 instance-id: This specification uses the word instance-id to refer to 153 the value of the "sip.instance" media feature tag in the Contact 154 header field as defined in [1]. This is a URN that uniquely 155 identifies the UA. 157 3. Overview 159 Several scenarios in which this technique is useful are discussed 160 below, including the simple collocated registrar and proxy, a User 161 Agent desiring multiple connections to a resource (for redundancy for 162 example), and a system that uses Edge Proxies. 164 3.1. Summary of Mechanism 166 The overall approach is fairly simple. Each UA has a unique 167 instance-id (found in the GRUU[1]) that stays the same for this UA 168 even if the UA reboots or is power cycled. Each UA can register 169 multiple times for the same AOR to achieve high reliability. Each 170 registration includes the instance-id for the UA and a flow-id label 171 that is different for each connection. 173 UAs use STUN as the keep alive mechanism to keep their flow to the 174 proxy or registrar alive. A UA can create more than one flow using 175 multiple registrations for the same AOR. The instance-id parameter 176 is used by the proxy to identify which UA a flow is associated with. 177 The flow-id is used by the proxy and registrar to tell the difference 178 between a UA re-registering and one that is registering over an 179 additional flow. The proxies keep track of the flows used for 180 successful registrations. 182 When a proxy goes to route a message to a UA for which it has a 183 binding, it can use any one of the flows on which a successful 184 registration has been completed. A failure on a particular flow can 185 be tried again on an alternate flow. Proxies can determine which 186 flows go to the same UA by looking at the instance-id. Proxies can 187 tell that a flow replaces a previously abandoned flow by looking at 188 the flow-id. 190 3.2. Single Registrar and UA 192 In this example there a single server is acting as both a registrar 193 and proxy. 195 +-----------+ 196 | Registrar | 197 | Proxy | 198 +-----+-----+ 199 | 200 | 201 +----+--+ 202 | User | 203 | Agent | 204 +-------+ 206 User Agents forming only a single connection continue to register 207 normally but include the instance-id as described in the GRUU [1] 208 specification and can also add a flow-id parameter to the Contact 209 header field value. The flow-id parameter is used to allow the 210 registrar to detect and avoid using invalid contacts when a UA 211 reboots or reconnects after its old connection has failed for some 212 reason. 214 For clarity, here is an example. Bob's UA creates a new TCP flow to 215 the registrar and sends the following REGISTER request. 217 REGISTER sip:example.com SIP/2.0 218 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036 219 Max-Forwards: 70 220 From: Bob ;tag=d879h76 221 To: Bob 222 Call-ID: 8921348ju72je840.204 223 CSeq: 1 REGISTER 224 Contact: ; flow-id=1; 225 ;+sip.instance="" 226 Content-Length: 0 228 Note: Implementors often ask why the value of the sip.instance is 229 inside angle brackets. This is a requirement of RFC 3840 [7] 230 which defines media feature tags in SIP. Feature tags which are 231 strings are compared by case sensitive string comparison. To 232 differentiate these tags from tokens (which are not case 233 sensitive), case sensitive parameters such as the sip.instance 234 media feature tag are placed inside angle brackets. 236 The registrar challenges this registration to authenticate Bob. When 237 the registrar adds an entry for this contact under the AOR for Bob, 238 the registrar also keeps track of the connection over which it 239 received this registration. 241 The registrar saves the instance-id (as defined in [1]) and flow-id 242 (as defined in Section 9) along with the rest of the Contact header 243 field. If the instance-id and flow-id are the same as a previous 244 registration for the same AOR, the proxy uses the most recently 245 created registration first. This allows a UA that has rebooted to 246 replace its previous registration for each flow with minimal impact 247 on overall system load. 249 Later when Alice sends a request to Bob, his proxy selects the target 250 set. The proxy forwards the request to elements in the target set 251 based on the proxy's policy. The proxy looks at the the target set 252 and uses the instance-id to understand that two targets both end up 253 routing to the same UA. When the proxy goes to forward a request to 254 a given target, it looks and finds the flows that received the 255 registration. The proxy then forwards the request on that flow 256 instead of trying to form a new flow to that contact. This allows 257 the proxy to forward a request to a particular contact down the same 258 flow that did the registration for this AOR. If the proxy had 259 multiple flows that all went to this UA, it would choose any one of 260 registration bindings that it had for this AOR and that had the same 261 instance-id as the selected UA. In general, if two registrations 262 have the same flow-id and instance-id, the proxy would favor the most 263 recently registered flow. This is so that if a UA reboots, the proxy 264 will prefer to use the most recent flow that goes to this UA instead 265 of trying one of the old flows which will presumably fail. 267 3.3. Multiple Connections from a User Agent 269 There are various ways to deploy SIP to build a reliable and 270 scaleable system. This section discusses one such design that is 271 possible with the mechanisms in this draft. Other designs are also 272 possible. 274 In this example system, the logical proxy/registrar for the domain is 275 running on two hosts that share the appropriate state and can both 276 provide registrar and proxy functionality for the domain. The UA 277 will form connections to two of the physical hosts that can perform 278 the proxy/registrar function for the domain. Reliability is achieved 279 by having the UA form two connections to the domain. Scaleability is 280 achieved by using DNS SRV to load balance the primary connection 281 across a set of machines that can service the primary connection and 282 also using DNS SRV to load balance across a separate set of machines 283 that can service the backup connection. The deployment here requires 284 that DNS be configured with an entry that resolves to all the primary 285 hosts and another that resolves to all the backup hosts. Designs 286 having only one set were also considered but in this case, there 287 would have to be some way to ensure that the two connection did not 288 accidentally resolve to the same host. Various approaches for this 289 are possible but all probably require extensions to the SIP protocol 290 so they were not included in this specification. This approach can 291 work with the disadvantage that slightly more configuration of DNS is 292 required. 294 +-------------------+ 295 | Domain | 296 | Logical Proxy/Reg | 297 | | 298 |+-----+ +-----+| 299 ||Host1| |Host2|| 300 |+-----+ +-----+| 301 +---\------------/--+ 302 \ / 303 \ / 304 \ / 305 \ / 306 +------+ 307 | User | 308 | Agent| 309 +------+ 311 The UA is configured with a primary and backup registration URI. 312 These URIs are configured into the UA through whatever the normal 313 mechanism is to configure the proxy or registrar for the UA. They 314 might look something like "sip:primary.example.com;sip-stun" and 315 "sip:backup.example.com;sip-stun" if the domain was example.com. The 316 "sip-stun" tag indicates that they support STUN as described later in 317 this specification. Note that each of them could resolve to several 318 different hosts. The administrative domain that created these URIs 319 MUST ensure that the two URIs resolve to separate hosts. These URIs 320 have normal SIP processing so things like SRV can be used to do load 321 balancing across a proxy farm. 323 The User Agent would get a GRUU from the domain to use at its 324 contact. The GRUU would refer to the domain, not host1 or host2. 325 Regardless of which host received a request to GRUU, the domain would 326 need to ensure that the request got sent to host1 or host2 and then 327 sent across the appropriate flow to the UA. The domain might choose 328 to use the Path header (as described in the next section) approach to 329 form this internal routing to host1 or host2. 331 When a single server fails, all the UAs that have a registration with 332 it will detect this and try to reconnect. This can cause large loads 333 on the server and is referred to as the avalanche restart problem 334 further discussed in Section 4.3. The multiple flows to many servers 335 help reduce the load caused by the avalanche restart. If a UA has 336 multiple flows, and one of the servers fails, it can delay some 337 significant time before trying to form a new connection to replace 338 the flow to the server that failed. By spreading out the time used 339 for all the UAs to reconnect to a server, the load on the server is 340 reduced. 342 3.4. Edge Proxies 344 Some SIP deployments use edge proxies such that the UA sends the 345 REGISTER to an Edge Proxy that then forwards the REGISTER to the 346 Registrar. The Edge Proxy includes a Path header [10] so that when 347 the registrar later forwards a request to this UA, the request is 348 routed through the Edge Proxy. There could be a NAT for FW between 349 the UA and the Edge Proxy and there could also be one between the 350 Edge Proxy and the Registrar. This second case typically happens 351 when the Edge Proxy is in an enterprise the Registrar is located at a 352 service provider. 354 +---------+ 355 |Registrar| 356 |Proxy | 357 +---------+ 358 / \ 359 ----------------------------NAT/FW 360 / \ 361 +-----+ +-----+ 362 |Edge1| |Edge2| 363 +-----+ +-----+ 364 \ / 365 \ / 366 ----------------------------NAT/FW 367 \ / 368 \ / 369 +------+ 370 |User | 371 |Agent | 372 +------+ 374 These systems can use effectively the same mechanism as described in 375 the previous sections but need to use the Path header. When the Edge 376 Proxy receives a registration, it needs to create an identifier value 377 that is unique to this flow (and not a subsequent flow with the same 378 addresses) and put this identifier in the path header. This is done 379 by putting the value in the user portion of a loose route in the path 380 header. If the registration succeeds, the Edge Proxy needs to map 381 future requests that are routed to the identifier value that was put 382 in the Path header to the associated flow. 384 The term Edge Proxy is often used to refer to deployments where the 385 the Edge Proxy is in the same administrative domain as the Registrar. 386 However, in this specification we use the term to refer to any proxy 387 between the UA and the Registrar. For example the Edge Proxy may be 388 inside an enterprise that requires its use and the registrar could be 389 a service provider with no relationship to the enterprise. 390 Regardless if they are in the same administrative domain, this 391 specification requires that Registrars and Edge proxies support the 392 Path header mechanism in RFC 3327 [10]. 394 3.5. Keep Alive Technique 396 A keep alive mechanism needs to detect both failure of a connection 397 and changes to the NAT public mapping as well as keeping any NAT 398 bindings refreshed. This specification uses STUN [5] over the same 399 flow as the SIP traffic to perform the keep alive. A flow definition 400 could change because a NAT device in the network path reboots and the 401 resulting public IP address or port mapping for the UA changes. To 402 detect this, requests are sent over the connection that is being used 403 for the SIP traffic. The proxy or registrar acts as a STUN server on 404 the SIP signaling port. 406 Note: The STUN mechanism is very robust and allows the detection 407 of a changed IP address. Many other options were considered. It 408 may also be possible to do this with OPTIONS messages and rport; 409 although this approach has the advantage of being backwards 410 compatible, it also increases the load on the proxy or registrar 411 server. The TCP KEEP_ALIVE mechanism is not used because most 412 operating systems do not allow the time to be set on a per 413 connection basis. Linux, Solaris, OS X, and Windows all allow 414 KEEP_ALIVEs to be turned on or off on a single socket using the 415 SO_KEEPALIVE socket options but can not change the duration of the 416 timer for an individual socket. The length of the timer typically 417 defaults to 7200 seconds. The length of the timer can be changed 418 to a smaller value by setting a kernel parameter but that affects 419 all TCP connections on the host and thus is not appropriate to 420 use. 422 If the UA detects that the connection has failed or that the flow 423 definition has changed, it MUST re-register and MUST use the back-off 424 mechanism described in Section 4 in order to provide congestion 425 relief when a large number of agents simultaneously reboot. 427 4. User Agent Mechanisms 429 The UA behavior is divided up into sections. The first describes 430 what a client must do when forming a new connection, the second when 431 detecting failure of a connection, and the third on failure recovery. 433 4.1. Forming Flows 435 When a User Agent initiates a dialog, it MUST provide a Contact URI 436 which has GRUU properties if it is in possession of an appropriate 437 GRUU. If it can not provide a GRUU, it needs to follow the procedure 438 specified in Section 4.1.1. 440 UAs are configured with one or more SIP URIs representing the default 441 outbound proxies with which to register. A UA MUST support sets with 442 at least two outbound proxy URIs (primary and backup) and SHOULD 443 support sets with up to four URIs. For each outbound proxy URI in 444 the set, the UA MUST send a REGISTER in the normal way using this URI 445 as the default outbound proxy. Forming the route set for the request 446 is discussed in [15] but typically results in sending the REGISTER 447 with the Route header field containing a loose route to the outbound 448 proxy URI. The UA MUST include the instance-id as described in [1]. 449 The UA MUST also add a distinct flow-id parameter to the Contact 450 header field. The UA SHOULD use a flow-id value of 1 for the first 451 URI in the set, and a flow-id value of 2 for the second, and so on. 452 Each one of these registrations will form a new flow from the UA to 453 the proxy. The flow-id sequence does not have to be exactly 1,2,3 454 but it does have to be exactly the same flow-id sequence each time 455 the device power cycles or reboots so that the flow-id values will 456 collide with the previously used flow-id values and the proxy can 457 realize that the older registrations are probably not useful. 459 If the 200 response to a REGISTER contains a Service Route header 460 field value as defined in RFC 3608 [16], then whichever proxy sends 461 the 200 response last will affect where all future requests from this 462 UA are directed. 464 Note that the UA needs to honor 503 responses to registrations as 465 described in RFC 3261 and RFC 3263 [4]. In particular, implementors 466 should note that when receiving a 503 with a Retry-After, the UA 467 should wait the indicated amount of time and retry the registration. 468 A Retry-After header field value of 0 is valid and indicates the UA 469 should retry the REGISTER immediately. Implementations need to 470 ensure that when retrying the REGISTER they redo the DNS resolution 471 process such that if multiple hosts are reachable from the URI, there 472 is a chance that the UA will select an alternate host from the one it 473 chose the previous time the URI was resolved. 475 Note on Instance-ID Selection: The instance-id needs to be a URN but 476 there are many ways one can be generated. A particularly simple way 477 for both "hard" phones and "soft" phones is to use a UUID as defined 478 in [6]. A device like a soft-phone, when first installed, should 479 generate a UUID [6] and then save this in persistent storage for all 480 future use. For a device such as a hard phone, which will only ever 481 have a single SIP UA present, the UUID can be generated at any time 482 because it is guaranteed that no other UUID is being generated at the 483 same time on that physical device. This means the value of the time 484 component of the UUID can be arbitrarily selected to be any time less 485 than the time when the device was manufactured. A time of 0 (as 486 shown in the example in Section 3.2) is perfectly legal as long as 487 the device knows no other UUIDs were generated at this time. 489 4.1.1. Request without GRUU 491 If the UA does not have a GRUU, it MUST send the request with a 492 Contact header field containing a +sip.instance media feature 493 parameter, and it MUST include the "pin-route" option-tag in both a 494 Proxy-Require and a Require header field value. A User Agent 495 compliant with this specification MUST NOT initiate a dialog with an 496 INVITE without a GRUU in the Contact header field. (At the time of 497 this writing this is allowed only for dialogs initiated with the 498 SUBSCRIBE method.) 500 This mechanism without a GRUU is not reliable if any of the proxies 501 on the path fail so it SHOULD not be used for long lived 502 subscriptions. Once a UA acquires an appropriate GRUU, it should 503 terminate these subscriptions and re-subscribe using the normal GRUU 504 based approach. 506 4.2. Detecting Flow Failure 508 The UA needs to detect if a given flow has failed, and if it has 509 failed, follow the procedures in Section 4.1 to form a new flow to 510 replace the failed one. 512 User Agents that form flows MUST check if the configured URI they are 513 connecting to has the "sip-stun" tag (defined in Section 10) and, if 514 the tag is present, then the UA needs to periodically perform STUN 515 [5] requests over the flow. The time between STUN requests when 516 using UDP SHOULD be a random number between 24 and 29 seconds while 517 for other transport protocols it SHOULD be a random number between 95 518 and 120 seconds. The times MAY be configurable. 520 Note on selection of time values: For UDP, the upper bound of 29 521 seconds was selected so that multiple STUN packets would be sent 522 before 30 seconds based on information that some NATs had UDP 523 timeouts as low as 30 seconds. The 24 second lower bound was 524 selected so that after 10 minutes the jitter this introduce would 525 have unsyncronized the STUN requests from different devices to evenly 526 spread the load on the servers. For TCP, the 120 seconds was chosen 527 based on the idea that for a good user experience, failures would be 528 detected in this time and a new connection set up. Operators that 529 wish to change the relationship between load on servers and the 530 expected time that a user may not receive inbound communications will 531 probably adjust this time widely. The 95 seconds lower bound was 532 chosen so that the jitter introduced would result in a relatively 533 even load on the servers after 30 minutes. 535 If the mapped address in the STUN response changes, the UA must treat 536 this as a failure on the flow. Any time a SIP message is sent and 537 the proxy does not respond, this is also considered a failure, the 538 flow is discarded and the procedures in Section 4.3 are followed to 539 form a new flow. 541 4.3. Flow Failure Recovery 543 When a flow to a particular URI in the proxy set fails, the UA needs 544 to form a new flow to replace it. The new flow MUST have the same 545 flow-id as the flow it is replacing. This is done in much the same 546 way as the flows are described as being formed in Section 4.1; 547 however, if there is a failure in forming this flow, the UA needs to 548 wait a certain amount of time before retrying to form a flow to this 549 particular URI in the proxy set. The time to wait is computed in the 550 following way. If all of the flows to every URI in the proxy set 551 have failed, the base time is set to 30 seconds; otherwise, in the 552 case where at least one of the flows has not failed, the base time is 553 set to 90 seconds. The wait time is computed by taking the base time 554 multiplied by two to power of the number of consecutive registration 555 failures to that URI up to a maximum of 1800 seconds. 557 wait-time = min( 1800, (base-time * (2 ^ consecutive-failures))) 559 These three times SHOULD be configurable in the UA. The three times 560 are the max-time with a default of 1800 seconds, the base-time-all- 561 fail with a default of 30 seconds, and the base-time-not-failed with 562 a default of 60 seconds. For example if the base time was 30 563 seconds, and there had been three failures, then the wait time would 564 be min(1800,30*(2^3)) or 240 seconds. The delay time is computed by 565 selecting a uniform random time between 50 and 100 percent of the the 566 wait time. The UA MUST wait for the value of the delay time before 567 trying another registration to form a new flow for that URI. 569 To be explicitly clear on the boundary conditions: when the UA boots 570 it immediately tries to register. If this fails and no registration 571 on other flows had succeeded, the first retry would happen somewhere 572 between 30 and 60 seconds after the failure of the first registration 573 request. If the number of consecutive-failures is large enough that 574 the maximum of 1800 seconds is being reached, then the UA keep trying 575 forever with a random time between 900 and 1800 seconds between the 576 attempts. 578 SIP dialogs can be used for one or more "usages". For example, a 579 session created with INVITE (a session "usage") and a subscription (a 580 subscription "usage") can share a dialog. On failure of a flow, a 581 User Agent might wish to resynchronizing the state of any active 582 usages on any dialogs using the flow. For example, the User Agent 583 could send a new subscription for each subscription usage and an 584 INVITE with replaces for each session usage. Note that when a flow 585 was obtained via a REGISTER request, the flow might be used by many 586 dialogs and dialog usages. A flow obtained via another request (e.g. 587 a SUBSCRIBE request) only has usages from a single dialog. The only 588 reason to do this is that a message may have been lost while the flow 589 was being reestablished. The GRUU will ensure that any future 590 messages are still delivered to the UA even if it does not re- 591 subscribe, re-INVITE, or otherwise refresh the usage. Deployments 592 need to carefully consider the implications of these sorts of 593 operations. This approach only helps in a very narrow corner case 594 and it will cause a huge load on the system if a single proxy 595 crashes. In some deployments, this will cause more harm than good. 597 4.4. Registration by Other Instances 599 A User Agent MUST NOT include an instance-id or flow-id in the 600 Contact header field of a registration if the registering UA is not 601 the same instance as the UA referred to by the target Contact header 602 field. (This practice is occasionally used to install forwarding 603 policy into registrars.) 605 5. Registrar Mechanisms 607 5.1. Processing Register Requests 609 Registrars which implement this specification, MUST support the Path 610 header mechanism[10] and processes REGISTER requests as described in 611 Section 10 of RFC 3261 with the following change. Any time the 612 registrar checks if a new contact matches an existing contact in the 613 location database, it MUST also check and see if both the instance-id 614 and flow-id match. If they do not both match, then they are not the 615 same contact. Additionally, if the both the instance-id and flow-id 616 are present and do match, then it is considered a match regardless of 617 if the value of the contact header field value matches. The 618 registrar MUST be prepared to receive some registrations that use 619 instance-id and flow-id and some that do not, simultaneously for the 620 same AOR. 622 In addition to the normal information stored in the binding record, 623 some additional information MUST be stored for any registration that 624 contains a flow-id header parameter in the Contact header field 625 value. The registrar MUST store enough information to uniquely 626 identify the network flow over which the request arrived. For common 627 operating systems with TCP, this would typically just be the file 628 descriptor. For common operating systems with UDP this would 629 typically be the file descriptor for the local socket that received 630 the request, the local interface, and the IP address and port number 631 of the remote side that sent the request. 633 The registrar MUST also store all the Contact header field 634 information including the flow-id and instance-id and SHOULD also 635 store the time at which the binding was last updated. If a Path 636 header field is present RFC 3327 [10] requires this to be stored and 637 the registrar MUST store the Path header field value with the binding 638 record. Any time a messages is forwarded over the flow that created 639 this binding, this stored Path header field value will be used to 640 route the message. If the registrar receives a re-registration, it 641 MUST update the information that uniquely identifies the network flow 642 over which the request arrived and SHOULD update the time the binding 643 was last updated. 645 The REGISTRAR MAY be configured with local policy to reject any 646 registrations that do not include the instance-id and flow-id to 647 eliminate the amplification attack described in [14]. 649 5.2. Forwarding Requests 651 When a proxy uses the location service to look up a registration 652 binding and then proxies a request to a particular contact, it 653 selects a contact to use normally, with a few additional rules: 655 o The proxy MUST NOT populate the target set with more than one 656 contact with the same AOR and instance-id at a time. If a request 657 for a particular AOR and instance-id fails with a 410 response, 658 the proxy SHOULD replace the failed branch with another target 659 with the same AOR and instance-id, but a different flow-id. 660 o If two bindings have the same instance-id and flow-id, it SHOULD 661 prefer the contact that was most recently updated. 663 Note that if the request URI is a GRUU, the proxy will only select 664 contacts with the AOR and instance-id associated with the GRUU. The 665 rules above still apply to a GRUU. This allows a request routed to a 666 GRUU to first try one of the flows to a UA, then if that fails, try 667 another flow to the same UA instance. 669 The proxy uses normal forwarding rules looking at the Route of the 670 message and any values of the of the stored Path header field value 671 in the registration binding to decide how to forward the request and 672 populate the Route header in the request. Additionally, when the 673 proxy forwards a request to a binding that contains a flow-id, the 674 proxy MUST send the request over the same network flow that was saved 675 with the binding. This means that for TCP, the request MUST be sent 676 on the same TCP socket that received the REGISTER request. For UDP, 677 the request MUST be sent from the same local IP address and port over 678 which the registration was received to the same IP address and port 679 from which the REGISTER was received. 681 If a proxy or registrar receives an indication from the network that 682 indicates that no future messages on this flow will work, then it 683 MUST remove all the bindings that use that flow (regardless of AOR). 684 Examples of this are a TCP socket closing or receiving a destination 685 unreachable ICMP error on a UDP flow. Similarly, if a proxy closes a 686 file descriptor, it MUST remove all the bindings that use that flow. 688 6. Edge Proxy Mechanisms 690 6.1. Processing Register Requests 692 When an Edge Proxy receives a registration request it MUST form a 693 flow identifier token that is unique to this network flow and use 694 this token as the user part of the URI that this proxy inserts into 695 the Path header. Edge proxies MUST use a Path header. A trivial way 696 to satisfy this requirement involves storing a mapping between an 697 incrementing counter and the connection information; however this 698 would require the Edge Proxy to keep an impractical amount of state. 699 It is unclear when this state could be removed and the approach would 700 have problems if the proxy crashed and lost the value of the counter. 701 Two stateless examples are provided below. A proxy can use any 702 algorithm it wants as long as the flow token is unique to a flow, the 703 flow can be recovered from the token, and the token can not be 704 modified by attackers. 706 Algorithm 1: The proxy generates a flow token for connection-oriented 707 transports by concatenating the file descriptor (or equivalent) 708 with the NTP time the connection was created, and base64 encoding 709 the result. This results in an approximately 16 octet identifier. 710 The proxy generates a flow token for UDP by concatenating the file 711 descriptor and the remote IP address and port, then base64 712 encoding the result. 714 Algorithm 2: When the proxy boots it selects a 20 byte crypto random 715 key called K that only the Edge Proxy knows. A byte array, called 716 S, is formed that contains the following information about the 717 flow the request was received on: an enumeration indicating the 718 protocol, the local IP address and port, the remote IP address and 719 port. The HMAC of S is computed using the key K and the HMAC- 720 SHA1-80 algorithm, as defined in [8]. The concatenation of the 721 HMAC and S are base64 encoded, as defined in [9], and used as the 722 flow identifier. With IPv4 address, this will result in a 32 723 octet identifier. 725 Algorithm 1 MUST NOT be used unless the REGISTER request is over a 726 SIPS protected transport. If the SIPS level of integrity protection 727 is not available, an attacker can hijack another user's calls. 729 6.2. Forwarding Requests 731 When the Edge Proxy receives a request it applies normal routing 732 procedures with the addition that it is routed to a URI with a flow 733 identifier token that this proxy created, then the proxy MUST forward 734 the request over the flow that received the REGISTER request that 735 caused the flow identifier token to be created. For connection- 736 oriented transports, if the flow no longer exists the proxy SHOULD 737 send a 410 response to the request. The advantage to a stateless 738 approach to managing the flow information is that there is no state 739 on the edge proxy that requires clean up that has to be synchronized 740 with the registrar. 742 Algorithm 1: The proxy base64 decodes the user part of the Route 743 header. For TCP, if a connection specified by the file descriptor 744 is present and the creation time of the file descriptor matches 745 the creation time encoded in the Route header, the proxy forwards 746 the request over that connection. For UDP, the proxy forwards the 747 request from the encoded file descriptor to the source IP address 748 and port. 749 Algorithm 2: To decode the flow token take the flow identifier in the 750 user portion of the URI, and base64 decode it, then verity the 751 HMAC is correct by recomputing the HMAC and checking it matches. 752 If the HMAC is not correct, the proxy SHOULD send a 403 response. 753 If the HMAC was correct then the proxy should forward the request 754 on the flow that was specified by the information in the flow 755 identifier. If this flow no longer exists, the proxy SHOULD send 756 a 410 response to the request. 758 Edge Proxies MUST Record-Route so that mid-dialog requests still are 759 routed over the correct flow. 761 7. Mechanisms for All Servers 763 7.1. STUN Processing 765 TODO: This section needs to be brought into sync with the STUN draft 766 and check there are not issues for SIP and STUN on TCP or UDP 767 connections. 769 A SIP device that receives SIP messages directly from a UA needs to 770 behave as specified in this section. Such devices would generally 771 include a Registrar and an Edge Proxy, as they both receive register 772 requests directly from a UA. 774 If the server receives SIP requests on a given interface and port, it 775 MUST also provide a limited version of a STUN server on the same 776 interface and port. Specifically it MUST be capable of receiving and 777 responding to STUN requests with the exception that it does not need 778 to support STUN requests with the changed port or changed address 779 flag set. This allows the STUN server to run with only one port and 780 IP address. 782 It is easy to distinguish STUN and SIP packets because the first 783 octet of a STUN packet has a value of 0 or 1 while the first octet of 784 a SIP message is never a 0 or 1. 786 When a URI is created that refers to a SIP device that supports STUN 787 as described in this section, the URI parameter "sip-stun", as 788 defined in Section 10 MUST be added to the URI. This allows a UA to 789 inspect the URI to decide if it should attempt to send STUN requests 790 to this location. The sip-stun tag would typically show up in the 791 URI in the Route header field value of a REGISTER request and would 792 not be in the request URI. 794 7.2. Pin-Route Processing 796 A sip device receives a request with the "pin-route" options tag set 797 in the Proxy-Require header field or the Require header field needs 798 to follow the procedures in this section. 800 A UAS that receives a request with the "pin-route" option tag in the 801 Require header MUST either reject the request if pin-route is not 802 supported, or if pin-route is supported by this UAS, the UAS MUST 803 ensure that any message send in the dialog formed by this request is 804 sent on the same flow as the initial request. This specification 805 does not mandate that all UAs support this option but certain UAs, 806 such as the NOTIFIER in the configuration framework, will want to 807 support this so they can form subscriptions with devices that do not 808 have a GRUU. 810 A proxy that receives a request with the "pin-route" option tag in 811 the Proxy-Require header MUST add a record-route header field value 812 that resolves to this proxy and it MUST ensure that any future 813 requests or responses in this dialog are forwarded on the same flow 814 as the original request. The suggested way to do this is to form a 815 flow identifier token in the same way that an Edge Proxy would form 816 this for the Path header and insert this flow identifier token in the 817 user portion of the URI used in the record route header field value. 819 8. Example Message Flow 821 The following call flow shows a basic registration and an incoming 822 call. Part way through the call, the flow to the Primary proxy is 823 lost. The BYE message for the call is rerouted to the callee via the 824 Backup proxy. When connectivity to the primary proxy is established, 825 the Callee registers again to replace the lost flow as shown in 826 message 15. 828 [-----example.com domain -------------------] 829 Caller Backup Primary Callee 830 | | | (1) REGISTER | 831 | | |<-----------------| 832 | | |(2) 200 OK | 833 | | |----------------->| 834 | | | (3) REGISTER | 835 | |<------------------------------------| 836 | |(4) 200 OK | | 837 | |------------------------------------>| 838 |(5) INVITE | | | 839 |----------------------------------->| | 840 | | |(6) INVITE | 841 | | |----------------->| 842 | | | (7) 200 OK | 843 | | |<-----------------| 844 | | (8) 200 OK | | 845 |<-----------------------------------| | 846 |(9) ACK | | | 847 |----------------------------------->| | 848 | | |(10) ACK | 849 | | |----------------->| 850 | | CRASH X | 851 |(11) BYE | | 852 |---------------->| | 853 | | (12) BYE | 854 | |------------------------------------>| 855 | | (13) 200 OK | 856 | |<------------------------------------| 857 | (14) 200 OK | | 858 |<----------------| REBOOT | | 859 | | | (15) REGISTER | 860 | | |<-----------------| 861 | | |(16) 200 OK | 862 | | |----------------->| 864 This call flow assumes that the Callee has been configured with a 865 proxy set that consists of "sip:primary.example.com;lr;sip-stun" and 866 "sip:backup.example.com;lr;sip-stun". The Callee REGISTER in message 867 (1) looks like: 869 REGISTER sip:example.com SIP/2.0 870 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 871 Max-Forwards: 70 872 From: Callee ;tag=a73kszlfl 873 To: Callee 874 Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 875 CSeq: 1 REGISTER 876 Route: 877 Contact: 878 ;+sip.instance="" 879 ;flow-id=1 880 Content-Length: 0 882 In the message, note that the Route is set and the Contact header 883 field value contains the instance-id and flow-id. The response to 884 the REGISTER in message (2) would look like: 886 SIP/2.0 200 OK 887 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 888 From: Callee ;tag=a73kszlfl 889 To: Callee ;tag=b88sn 890 Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 891 CSeq: 1 REGISTER 892 Contact: 893 ;+sip.instance="" 894 ;flow-id=1 895 ;expires=3600 896 Content-Length: 0 898 The second registration in message 3 and 4 are similar other than the 899 Call-ID has changed, the flow-id is 2, and the route is set to the 900 backup instead of the primary. They look like: 902 REGISTER sip:example.com SIP/2.0 903 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 904 Max-Forwards: 70 905 From: Callee ;tag=a73kszlfl 906 To: Callee 907 Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 908 CSeq: 1 REGISTER 909 Route: 910 Contact: 911 ;+sip.instance="" 912 ;flow-id=2 914 Content-Length: 0 916 SIP/2.0 200 OK 917 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 918 From: Callee ;tag=a73kszlfl 919 To: Callee ;tag=b88sn 920 Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 921 CSeq: 1 REGISTER 922 Contact: 923 ;+sip.instance="" 924 ;flow-id=1 925 ;expires=3600 926 Contact: 927 ;+sip.instance="" 928 ;flow-id=2 929 ;expires=3600 930 Content-Length: 0 932 The messages in the call flow are very normal. The only interesting 933 thing to note is that the INVITE in message 6 will have a: 935 Record-Route: 937 Message 11 seems seams strange in that it goes to the backup instead 938 of the primary. The Caller actually sends the message to the domain 939 of the callee based on the GRUU that the callee provided in their 940 Contact header field value when the dialog was formed and the domain 941 selected a host (primary or backup) that was currently available. 942 How the domain does this is an implementation detail up to the 943 domain. 945 The registrations in message 15 and 16 are the same as message 1 and 946 2 other than the Call-ID has changed. 948 9. Grammar 950 This specification defines a new Contact header field parameter, 951 flow-id. The grammar for DIGIT and EQUAL is obtained from RFC 3261 952 [3]. 954 contact-params = c-p-q / c-p-expires / c-p-flow / contact-extension 955 c-p-flow = "flow-id" EQUAL 1*DIGIT 957 The value of the flow-id MUST NOT be 0 and MUST be less than 2**31. 959 10. IANA Considerations 961 This specification defines a new Contact header field parameter 962 called flow-id in the "Header Field Parameters and Parameter Values" 963 sub-registry as per the registry created by [11] at 964 http://www.iana.org/assignments/sip-parameters. The required 965 information is: 967 Header Field Parameter Name Predefined Reference 968 Values 969 ____________________________________________________________________ 970 Contact flow-id Yes [RFC AAAA] 972 [NOTE TO RFC Editor: Please replace AAAA with 973 the RFC number of this specification.] 975 This specification defines a new value in the "SIP/SIPS URI 976 Parameters" sub-registry as per the registry created by [12] at 977 http://www.iana.org/assignments/sip-parameters. The required 978 information is: 980 Parameter Name Predefined Values Reference 981 ____________________________________________ 982 sip-stun No [RFC AAAA] 984 [NOTE TO RFC Editor: Please replace AAAA with 985 the RFC number of this specification.] 987 TODO: Add IANA section for "pin-route" option tag. 989 11. Security Considerations 991 One of the key security concerns in this work is making sure that an 992 attacker cannot hijack the sessions of a valid user and cause all 993 calls destined to that user to be sent to the attacker. 995 The simple case is when there are no edge proxies. In this case, the 996 only time an entry can be added to the routing for a given AOR is 997 when the registration succeeds. SIP protects against attackers being 998 able to successfully register, and this scheme relies on that 999 security. Some implementers have considered the idea of just saving 1000 the instance-id without relating it to the AOR with which it 1001 registered. This idea will not work because an attacker's UA can 1002 impersonate a valid user's instance-id and hijack that user's calls. 1004 The more complex case involves one or more edge proxies. When a UA 1005 sends a REGISTER request through an Edge Proxy on to the registrar, 1006 the Edge Proxy inserts a Path header field value. If the 1007 registration is successfully authenticated, the proxy stores the 1008 value of the Path header field. Later when the registrar forwards a 1009 request destined for the UA, it copies the stored value of the Path 1010 header field into the route header field of the request and forwards 1011 the request to the Edge Proxy. 1013 The only time an Edge Proxy will route over a particular flow is when 1014 it has received a route header that has the flow identifier 1015 information that it has created. An incoming request would have 1016 gotten this information from the registrar. The registrar will only 1017 save this information for a given AOR if the registration for the AOR 1018 has been successful; and the registration will only be successful if 1019 the UA can correctly authenticate. Even if an attacker has spoofed 1020 some bad information in the path header sent to the registrar, the 1021 attacker will not be able to get the registrar to accept this 1022 information for an AOR that does not belong to the attacker. The 1023 registrar will not hand out this bad information to others, and 1024 others will not be misled into contacting the attacker. 1026 12. Open Issues 1028 Service Route: The current interaction of this draft and 1029 draft-rosenberg-sip-route-construct [15] does not work. Currently 1030 the Service Route specification, RCFC 3608, suggests that the service 1031 route is appended to the outbound proxy set. That will work with 1032 this specification. However the [15] draft is suggesting to change 1033 the behavior so that the Service Route replaces the outbound proxy. 1034 This is basically so that SIP can be used to make configuration 1035 changes to the UA. The problem is that this specification requires 1036 two or more URIs for the outbound configuration (so that reliability 1037 is possible) and the Service Route would only be able to provide a 1038 single URI. If it is desirable to use Service Route this way, it 1039 probably needs to be modified in many ways including allowing it to 1040 return different Service Routes to different devices registering for 1041 the same AOR. 1043 Record Routing Edge Proxies: If an Edge Proxy record routes with a 1044 name that resolves explicitly to it and then crashes, all future 1045 requests in that dialog will fail. If an Edge Proxy record routes 1046 with a name that resolves to many edge proxies or does not record 1047 route at all, then requests that do not have GRUU as a contact will 1048 not work. A suggested resolution to this is to require GRUU for long 1049 lived dialogs and have the Edge proxies use path headers and not 1050 record route. 1052 SUBSCRIBEs without a GRUU. Earlier version of draft assumed that a 1053 REGISTER was always the first message. However the configuration 1054 framework[13] needs to perform a SUBSCRIBE to get the configuration 1055 that will allow the UA to register. This specification needs to deal 1056 with situations where there is a SUBSCRIBE but no REGISTER. The 1057 current resolution is to record route for these special cases and 1058 mitigate the reliability implications of this by not allowing these 1059 dialogs to be long lived. 1061 The terminology of flow, flow-id, connection is confusing. Do we 1062 want to change it? 1064 13. Requirements 1066 This specification was developed to meet the following requirements: 1068 1. Must be able to detect that a UA supports these mechanisms. 1069 2. Support UAs behind NATs. 1070 3. Support TLS to a UA without a stable DNS name or IP. 1071 4. Detect failure of connection and be able to correct for this. 1072 5. Support many UAs simultaneously rebooting. 1073 6. Support a NAT rebooting or resetting. 1074 7. Support proxy farms with multiple hosts for scaling and 1075 reliability purposes. 1076 8. Minimize initial startup load on a proxy. 1077 9. Support proxies that provide geographic redundancy. 1078 10. Support architectures with edge proxies. 1079 11. Must be able to receive notifications over the same flow used to 1080 send a subscription, even before any registrations have been 1081 established. This ensures compatibility with the SIP 1082 configuration framework [13]. 1084 14. Changes from 00 Version 1086 Moved TCP keep alive to be STUN. 1088 Allowed SUBSCRIBE to create flow mappings. Added pin-route option 1089 tags to support this. 1091 Added text about updating dialog state on each usage after a 1092 connection failure. 1094 15. Acknowledgments 1096 Jonathan Rosenberg provided many comments and useful text. Dave Oran 1097 came up with the idea of using the most recent registration first in 1098 the proxy. Alan Hawrylyshen co-authored the draft that formed the 1099 initial text of this specification. Additionally, many of the 1100 concepts here originated at a connection reuse meeting at IETF 60 1101 that included the authors, Jon Peterson, Jonathan Rosenberg, Alan 1102 Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of 1103 Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and 1104 Ganesh Jayadevan provided input and text. Nils Ohlmeier provided 1105 many fixes and initial implementation experience. In addition, 1106 thanks to the following folks for useful comments: Francois Audet, 1107 Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, and 1108 Lyndsay Campbell. 1110 16. References 1112 16.1. Normative References 1114 [1] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 1115 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 1116 draft-ietf-sip-gruu-04 (work in progress), July 2005. 1118 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1119 Levels", BCP 14, RFC 2119, March 1997. 1121 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1122 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1123 Session Initiation Protocol", RFC 3261, June 2002. 1125 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1126 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1128 [5] Rosenberg, J., "Simple Traversal of UDP Through Network Address 1129 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 (work 1130 in progress), July 2005. 1132 [6] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 1133 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1135 [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User 1136 Agent Capabilities in the Session Initiation Protocol (SIP)", 1137 RFC 3840, August 2004. 1139 16.2. Informative References 1141 [8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1142 for Message Authentication", RFC 2104, February 1997. 1144 [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1145 RFC 3548, July 2003. 1147 [10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1148 Extension Header Field for Registering Non-Adjacent Contacts", 1149 RFC 3327, December 2002. 1151 [11] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1152 Header Field Parameter Registry for the Session Initiation 1153 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1155 [12] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1156 Uniform Resource Identifier (URI) Parameter Registry for the 1157 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1158 December 2004. 1160 [13] Petrie, D., "A Framework for Session Initiation Protocol User 1161 Agent Profile Delivery", draft-ietf-sipping-config-framework-07 1162 (work in progress), July 2005. 1164 [14] Lawrence, S., Hawrylyshen, A., and R. Sparks, "Problems with 1165 Max-Forwards Processing (and Potential Solutions)", 1166 October 2005. 1168 [15] Rosenberg, J., "Clarifying Construction of the Route Header 1169 Field in the Session Initiation Protocol (SIP)", 1170 draft-rosenberg-sip-route-construct-00 (work in progress), 1171 July 2005. 1173 [16] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1174 Extension Header Field for Service Route Discovery During 1175 Registration", RFC 3608, October 2003. 1177 Authors' Addresses 1179 Cullen Jennings (editor) 1180 Cisco Systems 1181 170 West Tasman Drive 1182 Mailstop SJC-21/2 1183 San Jose, CA 95134 1184 USA 1186 Phone: +1 408 902-3341 1187 Email: fluffy@cisco.com 1189 Rohan Mahy (editor) 1190 SIP Edge LLC 1191 5617 Scotts Valley Drive, Suite 200 1192 Scotts Valley, CA 95066 1193 USA 1195 Email: rohan@ekabal.com 1197 Intellectual Property Statement 1199 The IETF takes no position regarding the validity or scope of any 1200 Intellectual Property Rights or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; nor does it represent that it has 1204 made any independent effort to identify any such rights. Information 1205 on the procedures with respect to rights in RFC documents can be 1206 found in BCP 78 and BCP 79. 1208 Copies of IPR disclosures made to the IETF Secretariat and any 1209 assurances of licenses to be made available, or the result of an 1210 attempt made to obtain a general license or permission for the use of 1211 such proprietary rights by implementers or users of this 1212 specification can be obtained from the IETF on-line IPR repository at 1213 http://www.ietf.org/ipr. 1215 The IETF invites any interested party to bring to its attention any 1216 copyrights, patents or patent applications, or other proprietary 1217 rights that may cover technology that may be required to implement 1218 this standard. Please address the information to the IETF at 1219 ietf-ipr@ietf.org. 1221 Disclaimer of Validity 1223 This document and the information contained herein are provided on an 1224 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1225 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1226 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1227 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1228 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1229 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1231 Copyright Statement 1233 Copyright (C) The Internet Society (2005). This document is subject 1234 to the rights, licenses and restrictions contained in BCP 78, and 1235 except as set forth therein, the authors retain all their rights. 1237 Acknowledgment 1239 Funding for the RFC Editor function is currently provided by the 1240 Internet Society.