idnits 2.17.1 draft-donovan-sipping-service-override-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 756. ** 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 23, 2006) is 6517 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) == Unused Reference: '2' is defined on line 694, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-levy-sip-diversion-08 ** Downref: Normative reference to an Historic draft: draft-levy-sip-diversion (ref. '5') == Outdated reference: A later version (-11) exists of draft-levy-sip-diversion-08 -- Duplicate reference: draft-levy-sip-diversion, mentioned in '6', was also mentioned in '5'. ** Downref: Normative reference to an Historic draft: draft-levy-sip-diversion (ref. '6') Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING S. Donovan 3 Internet-Draft C. Sivachelvan 4 Expires: December 25, 2006 Cisco Systems 5 June 23, 2006 7 The Service-State Header 8 draft-donovan-sipping-service-override-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 25, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document proposes a new header for the Session Initiation 42 Protocol. This header, the Service-State header, is used to 43 communicate application state between two SIP elements. 45 Note: The name of the file will be updated to be consistent with the 46 proposed header name in the next revision of the draft. 48 1. Requirements notation 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC2119. 54 2. Introduction 56 RFC 3261 [1] proposes a deployment architecture for SIP based network 57 referred to as the SIP trapezoid. This model shown in the following 58 figure, shows the relationship between the SIP clients and the SIP 59 proxy servers involved in routing of requests between the clients. 61 +------+ +------+ 62 |Alice | SIP | Bob | 63 |Domain|-----------|Domain| 64 |Proxy | |Proxy | 65 +------+ +------+ 66 / \ 67 /SIP SIP\ 68 / \ 69 +------+ +------+ 70 |Alice | RTP | Bob | 71 |Client|-------------------|Client| 72 | | | | 73 +------+ +------+ 75 In this model, Alice's clients sends all SIP communication through 76 Alice's proxy. Bob's client does the same. As a result, a SIP 77 request from Alice's client to Bob's client flows from Alice's client 78 through Alice's proxy, then through Bob's proxy and then to Bob's 79 client. The proxies play a number of roles for the client. These 80 roles are discussed in RFC 3261. 82 Deployments of SIP based networks have extended on the SIP trapezoid 83 model to allow for the separation between the basic routing functions 84 of the proxies required in the basic SIP trapezoid model and 85 applications that are involved in the delivery of SIP based services. 86 The extended SIP trapezoid model looks as follows: 88 +------+ +------+ 89 |Alice | | Bob | 90 | Appl | | Appl | 91 |Server| |Server| 92 +------+ +------+ 93 | | 94 |SIP SIP| 95 | | 96 +------+ +------+ 97 |Alice | SIP | Bob | 98 |Domain|-----------|Domain| 99 |Proxy | |Proxy | 100 +------+ +------+ 101 / \ 102 /SIP SIP\ 103 / \ 104 +------+ +------+ 105 |Alice | Media | Bob | 106 |Client|-------------------|Client| 107 | | | | 108 +------+ +------+ 110 In this model, there is an application server associated with Alice 111 and an application server associated with Bob. Service requests are 112 optionally routed through the application server to apply application 113 specific logic. Note that in this architecture, there can be 114 multiple application servers for Alice and multiple for Bob. 116 This document proposes and extension to SIP. This extension defines 117 a mechanism for the application server to includes state in the SIP 118 messages flowing between the proxy and the application server. This 119 state can be used by the proxy when it is determining how to route 120 the SIP requests after they have been handled by the application 121 server. 123 3. The Extended SIP Trapezoid 125 The Extended SIP Trapezoid is a SIP deployment architecture that 126 facilitates the separation of SIP routing functions from SIP 127 application functions. 129 This architecture allows application developers to focus on the 130 application logic without the need to understand the intricacies of 131 the SIP protocol. 133 This model separates the processing of the proxies in the classical 134 SIP trapezoid into two logical functions, the Service Manager (SM) 135 and the Application Server (AS). In general, both the SM and the AS 136 are specialized SIP proxies handling unique functionality. However, 137 both can also be implemented as B2BUAs should it be required to meet 138 individual deployment scenarios. In addition, the AS can be deployed 139 as a redirect server if it fits the requirements of the application 140 being deployed. 142 The following figure shows the extended SIP trapezoid architecture. 144 +------+ +------+ 145 | | | | 146 | oAS | | tAS | 147 | | | | 148 +------+ +------+ 149 | | 150 |SIP SIP| 151 | | 152 +------+ +------+ 153 | | SIP | | 154 | oSM |-----------| tSM | 155 | | | | 156 +------+ +------+ 157 / \ 158 /SIP SIP\ 159 / \ 160 +------+ +------+ 161 | | Media | | 162 | oUA |-------------------| tUA | 163 | | | | 164 +------+ +------+ 166 The following is a description of each of the elements in the 167 architecture: 169 o oUA - Originating User Agent - The user agent for the client 170 originating the service request. 172 o oSM - Originating Server Manager - The Service Manager responsible 173 for the handling of service requests for the oUA. This can either 174 be statically assigned to the oUA or dynamically assigned when the 175 oUA registers. 177 o oAS - Originating Application Server - An Application Server 178 applying an originating application, an application for the 179 originating user, to the service request. There can be zero, one 180 or more oASs invoked for an individual service request. 182 o tSM - Terminating Service Manager - The Service Manager 183 responsible for the handling of service requests for the target 184 user. As with the oSM, this can either be statically assigned to 185 the tUA or dynamically assigned when the tUA registers. 187 o tAS - Terminating Application Server - An Application Server 188 applying a terminating application, an application for the target 189 user, to the service request. There can be zero, one or more tASs 190 invoked for an individual service request. 192 o tUA - Terminating User Agent - The user agent that is the target 193 of the service request. If the tUA is registered then service 194 requests to the target URI are routed to the tUA. 196 In this model, the Service Manager is responsible for the following: 198 o Authentication of the originator of service requests; 200 o Authorization of service requests; 202 o Routing of service requests to Application Servers; 204 This is based on the context of the service request. This 205 context can include things like the content of the service 206 request and provisioned data about the originator or target of 207 the service request. 209 The SM can chose to route a service request to multiple 210 Application Servers. This is referred to as chaining of 211 applications 213 o Routing of service requests between the originating SM and the 214 terminating SM; 216 o Routing of service requests to the target URI. This can be to a 217 SIP end-point using SIP Registrar state, to a proxy in another 218 administrative domain or to a gateway device for requests that are 219 targeted for a non SIP destination (for example, a SIP to ISUP 220 gateway). 222 The Application Server applies application specific logic to the 223 service request before sending (via a proxy or B2BUA model) the 224 request back to the SM. This can include applying application 225 specific routing, retargeting the request to one or more users, 226 redirecting the request to a new user and rejecting the request. 228 The following is the general model for interactions between the SM 229 and the AS: 231 +------+ +------+ 232 | | | | 233 | oAS | | tAS | 234 | | | | 235 +------+ +------+ 236 ^ | ^ | 237 2| |3 5| |6 238 | v | v 239 +------+ +------+ 240 | | 4 | | 241 | oSM |---------->| tSM | 242 | | | | 243 +------+ +------+ 244 ^ | 245 1| |7 246 | v 247 +------+ +------+ 248 | | | | 249 | oUA | | tUA | 250 | | | | 251 +------+ +------+ 253 The following steps are taken in handling of a service request in 254 this model: 256 1. A service request is routed to the oSM. There may be zero, one 257 or more other SIP proxies between the oUA and the oSM. This 258 service request is authenticated either by the oSM or by a SIP 259 element that handled the request prior to the oSM. 261 2. The oSM authorized the service request and, based on the contents 262 of the service request and other inputs, such as a subscriber 263 profile for the originator of the service request, determines 264 where to route the request. In this case, the request is routed 265 to the oAS. Note that the oSM might route the service request to 266 multiple oASs. 268 3. The oAS processes the service request and routes it back to the 269 oSM. 271 4. The oSM determines that there are no other Application Servers 272 that need to handle the service request. As a result, the oSM 273 routes the request to the tSM. If the request was targeted for a 274 different domain then the oSM would have routed the request to 275 the appropriate server for the target domain. If it had 276 determined that the request should be routed through multiple 277 application servers then it would have proxied the request to the 278 next AS. 280 5. The tSM uses the content of the request and other information, 281 such as a subscriber profile for the target of the request, to 282 determine where to route the request. In this case, the tSM 283 determines that the request needs to be routed to the tAS. As 284 was the case for originating applications, the tSM can route the 285 request to multiple terminating applications. 287 6. The tAS processes the service request and routes it back to the 288 tSM. 290 7. The tSM determines that there are no additional terminating 291 applications to which the request is to be routed and, as such, 292 routes the request to the tUA. This is done by routing to the 293 contacts registered to the target URI contained in the request- 294 URI. 296 3.1. Definitions 298 Originator Identity (OID) - The identity of the originator or a 299 service request. The OID is determined based on authentication of 300 the user and is indicated in the P-Asserted-ID [3] header or in the 301 Identity [4] header. 303 Request Target - The target of a request is the URI contained in the 304 request-URI. 306 Request Retargeting - A request is retargeted if the request-URI is 307 modified but the request is still meant to be routed to the same 308 user. Contact routing is an example of request retargeting. 310 Redirection - A request is redirected if the user to which the 311 request is to be routed is changed. Call forwarding is an example of 312 redirection. In this case, a call from Alice to Bob is forwarded, or 313 redirected, by Bob to Carol. This represents two separate "call 314 legs", one from Alice to Bob and one from Bob to Carol. In some 315 scenarios, applications need to be applied to these two call legs 316 separately. 318 The reference to a call leg above is not meant to map to the 319 concept of a call leg in the PSTN, where there is a media path 320 established for each call leg. It is also not meant to map to the 321 concept of a dialog in SIP, as redirection can result in multiple 322 of these call legs within a single dialog. This call leg is a 323 virtual concept to reflect that Alice called Bob is a separate 324 call from the redirection that results in a call from Bob to 325 Carol. 327 4. Interaction between the oSM and oAS 329 In the basic case, the oAS will apply application logic to the 330 request. The oAS can then do one of the following: 332 o Reject the request due to application specific logic. 334 o Redirect the request using the appropriate 300-class response. 336 o Handle the request as a UAS. 338 o Proxy the request back to the oSM. 340 o Re-originate the request back to the oSM, acting as a B2BUA. 342 In the cases where the oAS returns the request to the oSM, it can 343 also change information contained in the request. For instance, the 344 oSM could retarget the request, changing the address in the request- 345 URI. 347 An example service for this model is an outbound call blocking (OCB) 348 service. For instance, a service provider might offer a service to a 349 user to have all calls to paid services (for example, 900 numbers in 350 World Zone 1) blocked. If this service is active for the originating 351 user then the OCB service would reject a service request if it were 352 to a paid service. If not, it would proxy the request unchanged. 354 Note: Normal SIP proxy changes would still be applied by the oAS. 355 Unchanged in this context means the originating and target 356 identities are not changed. 358 There are also instances were the oAS will retarget the request by 359 changing the Request URI. 361 A private numbering plan service is an example where this would be 362 the case. In this case the oAS would examine digits in the 363 Request-URI and modify them based on the numbering plan. This 364 might result in a short private dialing string being modified to a 365 fully qualified E.164 number. 367 4.1. oSM Handling of a retargeted request 369 The oSM had the following alternatives for handling the retargeting 370 of a request by the oAS: 372 o Continue originating processing for the OID 373 This is the most likely scenario. 375 o Skip to the end of originating processing for the OID 377 o Restart originating processing for the OID 379 An outbound call blocking feature is an example of when this 380 might be required. 382 In order to understand the correct action to take, the oSM might need 383 information on why the request was retargeted. There is currently no 384 mechanism in SIP for doing so. This is one of the motivations for 385 the extension proposed in this document. 387 5. Interaction between tSM and tAS 389 As with the oAS, in the basic case, the tAS will apply application 390 logic to the request. The tAS can then do one of the following: 392 o Reject the request due to application specific logic. 394 o Redirect the request using the appropriate 300-class response. 396 o Handle the request as a UAS. 398 o Proxy the request back to the tSM. 400 o Re-originate the request back to the tSM, acting as a B2BUA. 402 In the basic case, the tAS will apply application logic to the 403 request and either reject the request or proxy the request back to 404 the tSM with the identities of the originator and target unchanged. 406 An example service where this might apply is an incoming call 407 screening (ICS) service. For instance, a service provider might 408 offer a service to allow a user to maintain a list of addresses from 409 which the target user will not accept calls. If this service is 410 active for the target user then the ICS service would reject a 411 service request if the OID is included in the targets screening list. 412 If not, it would proxy the request unchanged. 414 Note: Normal SIP proxy changes would still be applied by the tAS. 415 Unchanged in this context means the originating and target 416 identities are not changed. 418 There are instances where the tAS will retarget the request by 419 changing the value of the Request-URI. 421 For example, a service provider might offer a service where a user 422 can have multiple phone numbers (alias's) or other URIs for a 423 single device. The tAS would retarget the request from an alias 424 URI to the "master" URI for the device. 426 There are also instances where the tAS will redirect the request. 427 This results in the value of the Request-URI being changed. It also 428 results in the identity of the redirecting user being included in the 429 proxied request as the OID for the call leg from the redirecting user 430 to the new target URI. 432 Note: One method for indicating the identity of the redirecting 433 user is the use of the Diversion header defined in [5]. It is 434 also possible that use of the History mechanism defined in [6] 435 could be used. 437 Call forwarding, in its various flavors, are example services that 438 result in redirection. 440 Second Note: This is different from redirecting the request using 441 a SIP defined 300-class redirection response. An application 442 would handle the redirection directly, as discussed here, if it 443 needs to be in the path of responses to the request or if it needs 444 to be in the path of mid-dialog requests for requests that result 445 in dialogs being established. Sending a 300-class response takes 446 the AS out of the signaling path for responses and subsequent mid- 447 dialog requests. 449 5.1. tSM handling of changed OID 451 Changing of the OID, by adding a new OID, for example by using a 452 Diversion header, to the existing OID(s) is one method that the tSM 453 can identify the request as having been redirected. The handling 454 options for this are outlined in the section on tSM handling of a 455 redirected request. 457 5.2. tSM handling of retargeting 459 The tSM has the following options for handling the case where the tAS 460 retargets a request: 462 o Continue terminating processing for the original target URI 464 This is the most likely alternative 466 o Skip to the end of terminating processing for the original target 467 URI and continue with contact routing. This has the result of not 468 routing the request to other tASs that would have been invoked 469 otherwise. 471 o Restart terminating processing for the new Request-URI 473 This might me necessary of the service profiles for the 474 original target URI and the new retargeted URI are different. 475 For instance, the service profile for the original target URI 476 might only result in the retargeting where the service profile 477 for the new target URI might have call forwarding logic 478 associated with it. 480 5.3. tSM handling of redirection 482 The tSM has the following options for the handling of the case where 483 the tAS redirects a request: 485 o Abort terminating processing for the original target Request-URI 486 and initiate originating processing for the redirecting OID. 488 For instance, the OCB feature might be invoked to determine if 489 the redirecting user, as indicated by the redirecting OID, is 490 authorized to make a call to the new address included in the 491 Request-URI. 493 The following diagram illustrates this type of handling of a 494 redirection: 496 +------+ +------+ +------+ +------+ 497 | | | | | | | | 498 | oAS1 | | tAS2 | | oAS2 | | tAS3 | 499 | | | | | | | | 500 +------+ +------+ +------+ +------+ 501 ^ | ^ | ^ | ^ | 502 2| |3 5| |6 8| |9 11| |12 503 | v | v | v | v 504 +------+ +------+ +------+ +------+ 505 | | 4 | | 7 | | 10 | | 506 | oSM1 |---------->| tSM2 |---------->| oSM2 |---------->| tSM3 | 507 | | | | | | | | 508 +------+ +------+ +------+ +------+ 509 ^ | 510 1| |13 511 | v 512 +------+ +------+ 513 | | | | 514 | oUA1 | | tUA3 | 515 | | | | 516 +------+ +------+ 518 o Abort terminating processing for the target Request-URI and route 519 the request to the new Request-URI 521 This skips originating processing for the call from the 522 redirecting OID to the new target. 524 The following diagram illustrates this type of handling of a 525 redirection: 527 +------+ +------+ +------+ 528 | | | | | | 529 | oAS1 | | tAS2 | | tAS3 | 530 | | | | | | 531 +------+ +------+ +------+ 532 ^ | ^ | ^ | 533 2| |3 5| |6 8| |9 534 | v | v | v 535 +------+ +------+ +------+ 536 | | 4 | | 7 | | 537 | oSM1 |---------->| tSM2 |---------->| tSM3 | 538 | | | | | | 539 +------+ +------+ +------+ 540 ^ | 541 1| |10 542 | v 543 +------+ +------+ 544 | | | | 545 | oUA1 | | tUA3 | 546 | | | | 547 +------+ +------+ 549 In order to understand the correct action to take, the tSM might need 550 information on why the request was retargeted. There is currntly no 551 mechanism in SIP for doing so. This is one of the motivations for 552 the extension proposed in this document. 554 5.4. SM selection of next application 556 One of the jobs of the SM is to determine what applications to invoke 557 for a given service request. The selection of the initial 558 application can be done based on the context known at the time that 559 the service request was received. As stated previously, this can be 560 based on the content of the service request. It can also be based on 561 provisioned data about the user that originated the request or the 562 user that is the target of the request. 564 The challenge becomes determining the application that should be 565 invoked after the first, or more generally, after any application has 566 finished handling a request. This decision can take the original 567 context of the service request into consideration. However, there 568 are situations where the decision also needs to be made based on the 569 results of application, or applications, that have already handled 570 the request. 572 For example, consider the case where the following is the desired 573 application logic for a given service request: 575 1. Invoke application 1 577 2. If application 1 is successful with result of foo then invoke 578 application 2 580 3. If application 1 is successful with result of bar then invoke 581 application 3 583 As another example, consider the case where the following logic is 584 the desired application logic: 586 1. If application 1 is not successful for reason foo then invoke 587 application 2 589 2. If application 1 is not successful for reason bar then invoke 590 appliation 3 592 3. If application 1 is not successful for all other reasons then 593 reject the service request with reason xyz. 595 One of the purposes of this document is to define a standard 596 mechanism for the AS to communicate success or failure of an 597 application along with result state to the SM. 599 6. Proposed Service-State Header 601 This document proposes an extension to the Session Initiation 602 Protocol to facilitate the interaction between the Service Manager 603 function and the Application Server function. 605 This extension give the AS a mechanism to inform the SM of the action 606 that the AS took with the request. This information can then, in 607 turn, be used by SM to determine what it should do next with the 608 request. 610 The extension proposed is the Service-State header. 612 6.1. Service-State Header Syntax 614 The following is the proposed syntax for the Service-State header: 616 Service-State-extension = "Service-State" HCOLON svc-params 617 *(SEMI svc-params) 618 svc-params = (svc-token / svc-extension) 619 svc-token = "state" EQUAL gen-value 620 svc-extension = token [ EQUAL gen-value ] 621 gen-value = token / quoted-string 623 6.2. Use of the Service-State header 625 The Service-State header is optionally inserted by the AS into 626 requests and responses sent from the AS to the SM. 628 The Service-State header can be carried in any request or response 629 sent from the AS to SM, with the exception of the CANCEL request. 631 The content of the state token and any semantics associated with it 632 is outside the scope of this specification. 634 Definition of the syntax and semantics associated with the state 635 token is a local policy issue. It requires consistent definition 636 between the AS and the SM. 638 6.3. Behavior of SM 640 The SM can receive the Service-State header in a SIP message in the 641 following cases: 643 o Failure Responses - 400, 500 and 600 class responses. 645 o Redirect Responses - 300 class responses. 647 o Success Responses - 200 class responses. 649 o Proxied Requests 651 o B2BUAed Requests 653 The action taken in each of these cases depends on the content of the 654 state token in the Service-State header. The definition of that 655 action is outside the scope of this specification. 657 6.4. Removal of Service-State header 659 In all cases the oSM and the tSM MUST remove the Service-State header 660 before routing the request or response to the next hop. This 661 includes cases: 663 o The SM routes a request to another AS. 665 o The oSM routes a request to the tSM. 667 o The SM routes a request to another SIP server. 669 o The SM routes a request to the tUA. 671 o The SM routes a response upstream. 673 7. Security Considerations 675 Use of the state included in the Service-State header by the SM can 676 affect the service received by users of the system. As such, the SM 677 should only take actions using the information in the Service-State 678 header if the application is trusted. 680 Note that this is not a security concern that is unique to the 681 Service-State header. It is inherent in the Extended SIP Trapezoid 682 deployment architecture that splits functions between the SM and the 683 AS. 685 The mechanism for establishing trust between the SM and the AS is 686 outside the scope of this specification. 688 8. References 690 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 691 Peterson, J., Sparks, J., Handley, M., and E. Schooler, "SIP: 692 Session Initiation Protocol", RFC 3261, June 2002. 694 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, March 1997. 697 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 698 Protocol (SIP)", RFC 3323, November 2002. 700 [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated 701 Identity Management in the Session Initiation Protocol (SIP)", 702 draft-ietf-sip-identity-06.txts (work in progress), 703 October 2005. 705 [5] Levy, S. and B. Byerly, "Diversion Indication in SIP", Internet- 706 Draft http://www.softarmor.com/wgdb/docs/ 707 draft-levy-sip-diversion-08.txt, August 2004. 709 [6] Barnes, M., Ed., "An Extension to the Session Initiation 710 Protocol (SIP) for Request History Information", Internet- 711 Draft http://www.softarmor.com/wgdb/docs/ 712 draft-levy-sip-diversion-08.txt, August 2004. 714 Authors' Addresses 716 Steven R. Donovan 717 Cisco Systems 718 2200 E. President George Bush Turnpike 719 Richardson, TX 75082 720 USA 722 Phone: +1 972 255 0248 723 Email: srd@cisco.com 725 Chelliah Sivachelvan 726 Cisco Systems 727 2200 E. President George Bush Turnpike 728 Richardson, TX 75082 729 USA 731 Phone: +1 972 255 1169 732 Email: chelliah@cisco.com 734 Intellectual Property Statement 736 The IETF takes no position regarding the validity or scope of any 737 Intellectual Property Rights or other rights that might be claimed to 738 pertain to the implementation or use of the technology described in 739 this document or the extent to which any license under such rights 740 might or might not be available; nor does it represent that it has 741 made any independent effort to identify any such rights. Information 742 on the procedures with respect to rights in RFC documents can be 743 found in BCP 78 and BCP 79. 745 Copies of IPR disclosures made to the IETF Secretariat and any 746 assurances of licenses to be made available, or the result of an 747 attempt made to obtain a general license or permission for the use of 748 such proprietary rights by implementers or users of this 749 specification can be obtained from the IETF on-line IPR repository at 750 http://www.ietf.org/ipr. 752 The IETF invites any interested party to bring to its attention any 753 copyrights, patents or patent applications, or other proprietary 754 rights that may cover technology that may be required to implement 755 this standard. Please address the information to the IETF at 756 ietf-ipr@ietf.org. 758 Disclaimer of Validity 760 This document and the information contained herein are provided on an 761 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 762 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 763 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 764 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 765 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 766 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 768 Copyright Statement 770 Copyright (C) The Internet Society (2006). This document is subject 771 to the rights, licenses and restrictions contained in BCP 78, and 772 except as set forth therein, the authors retain all their rights. 774 Acknowledgment 776 Funding for the RFC Editor function is currently provided by the 777 Internet Society.