idnits 2.17.1 draft-ietf-sipping-overload-reqs-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 21, 2008) is 5817 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-11 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Informational May 21, 2008 5 Expires: November 22, 2008 7 Requirements for Management of Overload in the Session Initiation 8 Protocol 9 draft-ietf-sipping-overload-reqs-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Overload occurs in Session Initiation Protocol (SIP) networks when 43 proxies and user agents have insuffient resources to complete the 44 processing of a request. SIP provides limited support for overload 45 handling through its 503 response code, which tells an upstream 46 element that it is overloaded. However, numerous problems have been 47 identified with this mechanism. This draft summarizes the problems 48 with the existing 503 mechanism, and provides some requirements for a 49 solution. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Causes of Overload . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Current SIP Mechanisms . . . . . . . . . . . . . . . . . . . . 5 57 5. Problems with the Mechanism . . . . . . . . . . . . . . . . . 6 58 5.1. Load Amplification . . . . . . . . . . . . . . . . . . . . 6 59 5.2. Underutilization . . . . . . . . . . . . . . . . . . . . . 9 60 5.3. The Off/On Retry-After Problem . . . . . . . . . . . . . . 9 61 5.4. Ambiguous Usages . . . . . . . . . . . . . . . . . . . . . 10 62 6. Solution Requirements . . . . . . . . . . . . . . . . . . . . 10 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . . . 15 70 1. Introduction 72 Overload occurs in Session Initiation Protocol (SIP) [RFC3261] 73 networks when proxies and user agents have insuffient resources to 74 complete the processing of a request or a response. SIP provides 75 limited support for overload handling through its 503 response code. 76 This code allows a server to tell an upstream element that it is 77 overloaded. However, numerous problems have been identified with 78 this mechanism. 80 This draft describes the general problem of SIP overload, and then 81 reviews the current SIP mechanisms for dealing with overload. It 82 then explains some of the problems with these mechanisms. Finally, 83 the document provides a set of requirements for fixing these 84 problems. 86 2. Causes of Overload 88 Overload occurs when an element, such as a SIP user agent or proxy, 89 has insufficient resources to successfully process all of the traffic 90 it is receiving. Resources include all of the capabilities of the 91 element used to process a request, including CPU processing, memory, 92 I/O, or disk resources. It can also include external resources, such 93 as a database or DNS server, in which case the CPU, processing, 94 memory, I/O and disk resources of those servers are effectively part 95 of the logical element processing the request. Overload can occur 96 for many reasons, including: 98 Poor Capacity Planning: SIP networks need to be designed with 99 sufficient numbers of servers, hardware, disks, and so on, in 100 order to meet the needs of the subscribers they are expected to 101 serve. Capacity planning is the process of determining these 102 needs. It is based on the number of expected subscribers and the 103 types of flows they are expected to use. If this work is not done 104 properly, the network may have insufficient capacity to handle 105 predictable usages, including regular usages and predictably high 106 ones (such as high voice calling volumes on Mothers Day). 108 Dependency Failures: A SIP element can become overloaded because a 109 resource on which it is dependent has failed or become overloaded, 110 greatly reducing the logical capacity of the element. In these 111 cases, even minimal traffic might cause the server to go into 112 overload. Examples of such dependency overloads include DNS 113 servers, databases, disks and network interfaces. 115 Component Failures: A SIP element can become overloaded when it is a 116 member of a cluster of servers which each share the load of 117 traffic, and one or more of the other members in the cluster fail. 118 In this case, the remaining elements take over the work of the 119 failed elements. Normally, capacity planning takes such failures 120 into account, and servers are typically run with enough spare 121 capacity to handle failure of another element. However, unusual 122 failure conditions can cause many elements to fail at once. This 123 is often the case with software failures, where a bad packet or 124 bad database entry hits the same bug in a set of elements in a 125 cluster. 127 Avalanche Restart: One of the most troubling sources of overload is 128 avalanche restart. This happens when a large number of clients 129 all simultaneously attempt to connect to the network with a SIP 130 registration. Avalanche restart can be caused by several events. 131 One is the "Manhattan Reboots" scenario, where there is a power 132 failure in a large metropolitan area, such as Manhattan. When 133 power is restored, all of the SIP phones, whether in PCs or 134 standalone devices, simultaneously power on and begin booting. 135 They will all then connect to the network and register, causing a 136 flood of SIP REGISTER messages. Another cause of avalanche 137 restart is failure of a large network connection, for example, the 138 access router for an enterprise. When it fails, SIP clients will 139 detect the failure rapidly using the mechanisms in 140 [I-D.ietf-sip-outbound]. When connectivity is restored, this is 141 detected, and clients re-REGISTER, all within a short time period. 142 Another source of avalanche restart is failure of a proxy server. 143 If clients had all connected to the server with TCP, its failure 144 will be detected, followed by re-connection and re-registration to 145 another server. Note that [I-D.ietf-sip-outbound] does provide 146 some remedies to this case. 148 Flash Crowds: A flash crowd occurs when an extremely large number of 149 users all attempt to simultaneously make a call. One example of 150 how this can happen is a television commercial that advertises a 151 number to call to receive a free gift. If the gift is compelling 152 and many people see the ad, many calls can be simultaneously made 153 to the same number. This can send the system into overload. 155 Unfortunately, the overload problem tends to compound itself. When a 156 network goes into overload, this can frequently cause failures of the 157 elements that are trying to process the traffic. This causes even 158 more load on the remaining elements. Furthermore, during overload, 159 the overall capacity of functional elements goes down, since much of 160 their resources are spent just rejecting or treating load that they 161 cannot actually process. In addition, overload tends to cause SIP 162 messages to be delayed or lost, which causes retransmissions to be 163 sent, further increasing the amount of work in the network. This 164 compounding factor can produce substantial multipliers on the load in 165 the system. Indeed, in the case of UDP, with as many as 7 166 retransmits of an INVITE request prior to timeout, overload can 167 multiply the already-heavy message volume by as much as seven! 169 3. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 4. Current SIP Mechanisms 177 SIP provides very basic support for overload. It defines the 503 178 response code, which is sent by an element that is overloaded. RFC 179 3261 defines it thusly: 181 The server is temporarily unable to process the request due to 182 a temporary overloading or maintenance of the server. The 183 server MAY indicate when the client should retry the request in 184 a Retry-After header field. If no Retry-After is given, the 185 client MUST act as if it had received a 500 (Server Internal 186 Error) response. 188 A client (proxy or UAC) receiving a 503 (Service Unavailable) 189 SHOULD attempt to forward the request to an alternate server. 190 It SHOULD NOT forward any other requests to that server for the 191 duration specified in the Retry-After header field, if present. 193 Servers MAY refuse the connection or drop the request instead of 194 responding with 503 (Service Unavailable). 196 The objective is to provide a mechanism to move the work of the 197 overloaded server to another server, so that the request can be 198 processed. The Retry-After header field, when present, is meant to 199 allow a server to tell an upstream element to back off for a period 200 of time, so that the overloaded server can work through its backlog 201 of work. 203 RFC3261 also instructs proxies to not forward 503 responses upstream, 204 at SHOULD NOT strength. This is to avoid the upstream server of 205 mistakingly concluding that the proxy is overloaded, when in fact the 206 problem was an element further downstream. 208 5. Problems with the Mechanism 210 At the surface, the 503 mechanism seems workable. Unfortunately, 211 this mechanism has had numerous problems in actual deployment. These 212 problems are described here. 214 5.1. Load Amplification 216 The principal problem with the 503 mechanism is that it tends to 217 substantially amplify the load in the network when the network is 218 overloaded, causing further escalation of the problem and introducing 219 the very real possibility of congestive collapse. Consider the 220 topology in Figure 2. 222 +------+ 223 > | | 224 / | S1 | 225 / | | 226 / +------+ 227 / 228 / 229 / 230 / 231 +------+ / +------+ 232 --------> | |/ | | 233 | P1 |---------> | S2 | 234 --------> | |\ | | 235 +------+ \ +------+ 236 \ 237 \ 238 \ 239 \ 240 \ 241 \ +------+ 242 \ | | 243 > | S3 | 244 | | 245 +------+ 247 Figure 2 249 Proxy P1 receives SIP requests from many sources, and acts solely as 250 a load balancer, proxying the requests to servers S1, S2 and S3 for 251 processing. The input load increases to the point where all three 252 servers become overloaded. Server S1, when it receives its next 253 request, generates a 503. However, because the server is loaded, it 254 might take some time to generate the 503. If SIP is being run over 255 UDP, this may result in request retransmissions which further 256 increase the work on S1. Even in the case of TCP, if the server is 257 loaded and the kernel cannot send TCP acknowledgements fast enough, 258 TCP retransmits may occur. When the 503 is received by P1, it 259 retries the request on S2. S2 is also overloaded, and eventually 260 generates a 503, but in the interim may also be hit with retransmits. 261 P1 once again tries another server, this time S3, which also 262 eventually rejects it with a 503. 264 Thus, the processing of this request, which ultimately failed, 265 involved four SIP transactions (client to P1, P1 to S1, P1 to S2, P1 266 to S3), each of which may have involved many retransmissions - up to 267 7 in the case of UDP. Thus, under unloaded conditions, a single 268 request from a client would generate one request (to S1, S2 or S3) 269 and two responses (from S1 to P1, then P1 to the client). When the 270 network is overloaded, a single request from the client, before 271 timing out, could generate as many as 18 requests and as many 272 responses when UDP is used! The situation is better with TCP (or any 273 reliable transport in general), but even if there was never a TCP 274 segment retransmitted, a single request from the client can generate 275 3 requests and four responses. Each server had to expend resources 276 to process these messages. Thus, more messages and more work were 277 sent into the network at the point at which the elements became 278 overloaded. The 503 mechanism works well when a single element is 279 overloaded. But, when the problem is overall network load, the 503 280 mechanism actually generates more messages and more work for all 281 servers, ultimately resulting in the rejection of the request anyway. 283 The problem becomes amplified further if one considers proxies 284 upstream from P1, as shown in Figure 3. 286 +------+ 287 > | | < 288 / | S1 | \\ 289 / | | \\ 290 / +------+ \\ 291 / \ 292 / \\ 293 / \\ 294 / \ 295 +------+ / +------+ +------+ 296 | | / | | | | 297 | P1 | ---------> | S2 |<----------| P2 | 298 | | \ | | | | 299 +------+ \ +------+ +------+ 300 ^ \ / ^ 301 \ \ // / 302 \ \ // / 303 \ \ // / 304 \ \ / / 305 \ \ +------+ // / 306 \ \ | | // / 307 \ > | S3 | < / 308 \ | | / 309 \ +------+ / 310 \ / 311 \ / 312 \ / 313 \ / 314 \ / 315 \ / 316 \ / 317 \ / 318 +------+ 319 | | 320 | PA | 321 | | 322 +------+ 323 ^ ^ 324 | | 325 | | 327 Figure 3 329 Here, proxy PA receives requests, and sends these to proxies P1 or 330 P2. P1 and P2 both load balance across S1 through S3. Assuming 331 again S1 through S3 are all overloaded, a request arrives at PA, 332 which tries P1 first. P1 tries S1, S2 and then S3, and each 333 transaction resulting in many request retransmits if UDP is used. 335 Since P1 is unable to eventually process the request, it rejects it. 336 However, since all of its downstream dependencies are busy, it 337 decides to send a 503. This propagates to PA, which tries P2, which 338 tries S1 through S3 again, resulting in a 503 once more. Thus, in 339 this case, we have doubled the number of SIP transactions and overall 340 work in the network compared to the previous case. The problem here 341 is that the fact that S1 through S3 were overloaded was known to P1, 342 but this information was not passed back to PA and through to P2, so 343 that P2 will retry S1 through S3 again. 345 5.2. Underutilization 347 Interestingly, there are also examples of deployments where the 348 network capacity was greatly reduced as a consequence of the overload 349 mechanism. Consider again Figure 2. Unfortunately, RFC 3261 is 350 unclear on the scope of a 503. When it is received by P1, does the 351 proxy cease sending requests to that IP address? To the hostname? 352 To the URI? Some implementations have chosen the hostname as the 353 scope. When the hostname for a URI points to an SRV record in the 354 DNS, which, in turn, maps to a cluster of downstream servers (S1, S2 355 and S3 in the example), a 503 response from a single one of them will 356 make the proxy believe that the entire cluster is overloaded. 357 Consequently, proxy P1 will cease sending any traffic to any element 358 in the cluster, even though there are elements in the cluster that 359 are underutilized. 361 5.3. The Off/On Retry-After Problem 363 The Retry-After mechanism allows a server to tell an upstream element 364 to stop sending traffic for a period of time. The work that would 365 have otherwise been sent to that server is instead sent to another 366 server. The mechanism is an all-or-nothing technique. A server can 367 turn off all traffic towards it, or none of it. There is nothing in 368 between. This tends to cause highly oscillatory behavior under even 369 mild overload. Consider a proxy P1 which is balancing requests 370 between two servers S1 and S2. The input load just reaches the point 371 where both S1 and S2 are at 100% capacity. A request arrives at P1, 372 and is sent to S1. S1 rejects this request with a 503 , and decides 373 to use Retry-After to clear its backlog. P1 stops sending all 374 traffic to S1. Now, S2 gets traffic, but it is seriously overloaded 375 - at 200% capacity! It decides to reject a request with a 503 and a 376 Retry-After, which now forces P1 to reject all traffic until S1's 377 Retry-After timer expires. At that point, all load is shunted back 378 to S1, which reaches overload, and the cycle repeats. 380 Its important to observe that this problem is only observed for 381 servers where there are a small number of upstream elements sending 382 it traffic, as is the case in these examples. If a proxy was 383 accessed by a large number of clients, each of which sends a small 384 amount of traffic, the 503 mechanism with Retry-After is quite 385 effective when utilized with a subset of the clients. This is 386 because spreading the 503 out amongst the clients has the effect of 387 providing the proxy more fine-grained controls on the amount of work 388 it receives. 390 5.4. Ambiguous Usages 392 Unfortunately, the specific instances under which a server is to send 393 a 503 are ambiguous. The result is that implementations generate 503 394 for many reasons, only some of which are related to actual overload. 395 For example, RFC 3398 [RFC3398], which specifies interworking from 396 SIP to ISUP, defines the usage of 503 when the gateway receives 397 certain ISUP cause codes from downstream switches. In these cases, 398 the gateway has ample capacity; its just that this specific request 399 could not be processed because of a downstream problem. All 400 subsequent requests might succeed if they take a different route in 401 the PSTN. 403 This causes two problems. Firstly, during periods of overload, it 404 exacerbates the problems above because it causes additional 503 to be 405 fed into the system, causing further work to be generated in 406 conditions of overload. The other problem is that it becomes hard 407 for an upstream element to know whether to retry when a 503 is 408 received. There are classes of failures where trying on another 409 server won't help, since the reason for the failure was that a common 410 downstream resource is unavailable. For example, if servers S1 and 411 S2 share a database, and the database fails. A request sent to S1 412 will result in a 503, but retrying on S2 won't help since the same 413 database is unavailable. 415 6. Solution Requirements 417 In this section, we propose requirements for an overload control 418 mechanism for SIP which addresses these problems. 420 REQ 1: The overload mechanism shall strive to maintain the overall 421 useful throughput (taking into consideration the quality-of- 422 service needs of the using applications) of a SIP server at 423 reasonable levels even when the incoming load on the network is 424 far in excess of its capacity. The overall throughput under load 425 is the ultimate measure of the value of an overload control 426 mechanism. 428 REQ 2: When a single network element fails, goes into overload, or 429 suffers from reduced processing capacity, the mechanism should 430 strive to limit the impact of this on other elements in the 431 network. This helps to prevent a small-scale failure from 432 becoming a widespread outage. 434 REQ 3: The mechanism should seek to minimize the amount of 435 configuration required in order to work. For example, it is 436 better to avoid needing to configure a server with its SIP message 437 throughput, as these kinds of quantities are hard to determine. 439 REQ 4: The mechanism must be capable of dealing with elements which 440 do not support it, so that a network can consist of a mix of ones 441 which do and don't support it. In other words, the mechanism 442 should not work only in environments where all elements support 443 it. It is reasonable to assume that it works better in such 444 environments, of course. Ideally, there should be incremental 445 improvements in overall network throughput as increasing numbers 446 of elements in the network support the mechanism. 448 REQ 5: The mechanism should not assume that it will only be deployed 449 in environments with completely trusted elements. It should seek 450 to operate as effectively as possible in environments where other 451 elements are malicious, including preventing malicious elements 452 from obtaining more than a fair share of service. 454 REQ 6: When overload is signaled by means of a specific message, the 455 message must clearly indicate that it is being sent because of 456 overload, as opposed to other, non-overload based failure 457 conditions. This requirement is meant to avoid some of the 458 problems that have arisen from the reuse of the 503 response code 459 for multiple purposes. Of course, overload is also signaled by 460 lack of response to requests. This requirement applies only to 461 explicit overload signals. 463 REQ 7: The mechanism shall provide a way for an element to throttle 464 the amount of traffic it receives from an upstream element. This 465 throttling shall be graded, so that it is not all or nothing as 466 with the current 503 mechanism. This recognizes the fact that 467 "overload" is not a binary state, and there are degrees of 468 overload. 470 REQ 8: The mechanism shall ensure that, when a request was not 471 processed successfully due to overload (or failure) of a 472 downstream element, the request will not be retried on another 473 element which is also overloaded or whose status is unknown. This 474 requirement derives from REQ 1. 476 REQ 9: That a request has been rejected from an overloaded element 477 shall not unduly restrict the ability of that request to be 478 submitted to and processed by an element that is not overloaded. 479 This requirement derives from REQ 1. 481 REQ 10: The mechanism should support servers that receive requests 482 from a large number of different upstream elements, where the set 483 of upstream elements is not enumerable. 485 REQ 11: The mechanism should support servers that receive requests 486 from a finite set of upstream elements, where the set of upstream 487 elements is enumerable. 489 REQ 12: The mechanism should work between servers in different 490 domains. 492 REQ 13: The mechanism must not dictate a specific algorithm for 493 prioritizing the processing of work within a proxy during times of 494 overload. It must permit a proxy to prioritize requests based on 495 any local policy, so that certain ones (such as a call for 496 emergency services or a call with a specific value of the 497 Resource-Priority header field [RFC4412]) are given preferential 498 treatment,such as not being dropped, being given additional 499 retransmission, or being processed ahead of others. 501 REQ 14: The mechanism should provide unambigous directions to 502 clients on when they should retry a request, and when they should 503 not. This especially applies to TCP connection establishment and 504 SIP registrations, in order to mitigate against avalanche restart. 506 REQ 15: In cases where a network element fails, is so overloaded 507 that it cannot process messages, or cannot communicate due to a 508 network failure or network partition, it will not be able to 509 provide explicit indications of its levels of congestion. The 510 mechanism should properly function in these cases. 512 REQ 16: The mechanism should attempt to minimize the overhead of the 513 overload control messaging. 515 REQ 17: The overload mechanism must not provide an avenue for 516 malicious attack. 518 REQ 18: The overload mechanism should be unambiguous about whether a 519 load indication applies to a specific IP address, host, or URI, so 520 that an upstream element can determine the load of the entity to 521 which a request is to be sent. 523 REQ 19: The specification for the overload mechanism should give 524 guidance on which message types might be desirable to process over 525 others during times of overload, based on SIP-specific 526 considerations. For example, it may be more beneficial to process 527 a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh 528 with a non-zero expiration, since the former reduces the overall 529 amount of load on the element, or to process re-INVITEs over new 530 INVITEs. 532 REQ 20: In a mixed environment of elements that do and do not 533 implement the overload mechanism, no disproportionate benefit 534 shall accrue to the users or operators of the elements that do not 535 implement the mechanism. 537 REQ 21: The overload mechanism should ensure that the system remains 538 stable. When the offered load drops from above the overall 539 capacity of the network to below the overall capacity, the 540 throughput should stabilize and become equal to the offered load. 542 REQ 22: It must be possible to disable the reporting of load 543 information towards upstream targets based on the identity of 544 those targets. This allows a domain administrator who considers 545 the load of their elements to be sensitive information, to 546 restrict access to that information. Of course, in such cases, 547 there is no expectation that the overload mechanism itself will 548 help prevent overload from that upstream target. 550 REQ 23: It must be possible for the overload mechanism to work in 551 cases where there is a load balancer in front of a farm of 552 proxies. 554 7. Security Considerations 556 Like all protocol mechanisms, a solution for overload handling must 557 prevent against malicious inside and outside attacks. This document 558 includes requirements for such security functions. 560 8. IANA Considerations 562 None. 564 9. Acknowledgements 566 The author would like to thank Steve Mayer, Mouli Chandramouli, 567 Robert Whent, Mark Perkins, Joe Stone, Vijay Gurbani, Steve Norreys, 568 Volker Hilt, Spencer Dawkins, Matt Mathis, and Dale Worley for their 569 contributions to this document. 571 10. Informative References 573 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 574 A., Peterson, J., Sparks, R., Handley, M., and E. 575 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 576 June 2002. 578 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 579 "Integrated Services Digital Network (ISDN) User Part 580 (ISUP) to Session Initiation Protocol (SIP) Mapping", 581 RFC 3398, December 2002. 583 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 584 Priority for the Session Initiation Protocol (SIP)", 585 RFC 4412, February 2006. 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 [I-D.ietf-sip-outbound] 591 Jennings, C. and R. Mahy, "Managing Client Initiated 592 Connections in the Session Initiation Protocol (SIP)", 593 draft-ietf-sip-outbound-11 (work in progress), 594 November 2007. 596 Author's Address 598 Jonathan Rosenberg 599 Cisco 600 Edison, NJ 601 US 603 Email: jdrosen@cisco.com 604 URI: http://www.jdrosen.net 606 Full Copyright Statement 608 Copyright (C) The IETF Trust (2008). 610 This document is subject to the rights, licenses and restrictions 611 contained in BCP 78, and except as set forth therein, the authors 612 retain all their rights. 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Intellectual Property 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org. 646 Acknowledgment 648 Funding for the RFC Editor function is provided by the IETF 649 Administrative Support Activity (IASA).