SIPPING S. Donovan Internet-Draft Cisco Systems Expires: August 30, 2006 February 26, 2006 The Service-Override Header draft-donovan-sipping-service-override-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes a new header for the Session Initiation Protocol. This header, the Service-Override header, is used to communicate application state between two SIP elements. Donovan Expires August 30, 2006 [Page 1] Internet-Draft The Service-Override Header February 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Donovan Expires August 30, 2006 [Page 2] Internet-Draft The Service-Override Header February 2006 2. Introduction One model for deploying services on SIP [1] networks is based on the separation of functionality between what is referred to in this document as the Service Manager (SM) and the Application Server (AS). In general, both the SM and the AS are specialized SIP proxies handling unique functionality. However, both can also be implemented as B2BUAs should it be required to meet individual deployment scenarios. In this model, the Service Manager is responsible for the following: o Authentication of the originator of service requests; o Authorization of service requests; o Routing of service requests to Application Servers; This is based on the context of the service request. This context can include things like the content of the service request and provisioned data about the originator or target of the service request. o Routing of service requests between the originating SM and the terminating SM; o Routing of service requests to the target URI. This can be to a SIP end-point using SIP Registrar state, to a proxy in another administrative domain or to a gateway device for requests that are targeted for a non SIP destination (for example, a SIP to ISUP gateway). The Application Server applies application specific logic to the service request before sending (via a proxy or B2BUA model) the request back to the SM. Donovan Expires August 30, 2006 [Page 3] Internet-Draft The Service-Override Header February 2006 The following is the general model for interactions between the SM and the AS: +------+ +------+ | | | | | oAS | | tAS | | | | | +------+ +------+ ^ | ^ | 2| |3 5| |6 | v | v +------+ +------+ | | 4 | | | oSM |---------->| tSM | | | | | +------+ +------+ ^ | 1| |7 | v +------+ +------+ | | | | | oUA | | tUA | | | | | +------+ +------+ The following steps are taken in handling of a service request in this model: 1. A service request is routed to the oSM. There may be zero, one or more other SIP proxies between the oUA and the oSM. This service request is authenticated either by the oSM or by a SIP element that handled the request prior to the oSM. 2. The oSM authorized the service request and, based on the contents of the service request and other inputs, such as a subscriber profile for the originator of the service request, determines where to route the request. In this case, the request is routed to the oAS. Note that the oSM might route the service request to multiple oASs. 3. The oAS processes the service request and routes it back to the oSM. 4. The oSM determines that there are no other Application Servers that need to handle the service request. As a result, the oSM routes the request to the tSM. If the request was targeted for a different domain then the oSM would have routed the request to Donovan Expires August 30, 2006 [Page 4] Internet-Draft The Service-Override Header February 2006 the appropriate server for the target domain. 5. The tSM uses the content of the request and other information, such as a subscriber profile for the target of the request, to determine where to route the request. In this case, the tSM determines that the request needs to be routed to the tAS. As was the case for originating applications, the tSM can route the request to multiple terminating applications. 6. The tAS processes the service request and routes it back to the tSM. 7. The tSM determines that there are no additional terminating applications to which the request is to be routed and, as such, routes the request to the tUA. This is done by routing to the contacts registered to the target URI contained in the request- URI. 2.1. Definitions Originating User Agent (oUA) - The user agent for the client originating the service request. Originating Server Manager (oSM) - The Service Manager responsible for the handling of service requests for the oUA. This can either be statically assigned to the oUA or dynamically assigned when the oUA registers. Originating Application Server (oAS) - An Application Server applying an originating application, an application for the originating user, to the service request. There can be zero, one or more oASs invoked for an individual service request. Terminating Service Manager (tSM) - The Service Manager responsible for the handling of service requests for the target user. As with the oSM, this can either be statically assigned to the tUA or dynamically assigned when the tUA registers. Terminating Application Server (tAS) - An Application Server applying an terminating application, an application for the target user, to the service request. There can be zero, one or more tASs invoked for an individual service request. Terminating User Agent (tUA) - The user agent that is the target of the service request. If the tUA is registered then service requests to the target URI are routed to the tUA. Originator Identity (OID) - The identity of the originator or a Donovan Expires August 30, 2006 [Page 5] Internet-Draft The Service-Override Header February 2006 service request. The OID is determined based on authentication of the user and is indicated in the P-Asserted-ID [3] header or in the Identity [4] header. Request Retargeting - A request is retargeted if the request-URI is modified but the request is still meant to be routed to the same user. Contact routing is an example of request retargeting. Redirection - A request is redirected if the user to which the request is to be routed is changed. Call forwarding is an example of redirection. In this case, a call from Alice to Bob is forwarded, or redirected, by Bob to Carol. This represents two separate "call legs", one from Alice to Bob and one from Bob to Carol. In some scenarios, applications need to be applied to these two call legs separately. The reference to a call leg above is not meant to map to the concept of a call leg in the PSTN, where there is a media path established for each call leg. It is also not meant to map to the concept of a dialog in SIP, as redirection can result in multiple of these call legs within a single dialog. This call leg is a virtual concept to reflect that Alice called Bob is a separate call from the redirection that results in a call from Bob to Carol. Donovan Expires August 30, 2006 [Page 6] Internet-Draft The Service-Override Header February 2006 3. Interaction between the oSM and oAS In the basic case, the oAS will apply application logic to the request and either reject the request or proxy the request back to the oSM with the identities of the originator and target unchanged. An example service for this model is an outbound call blocking (OCB) service. For instance, a service provider might offer a service to a user to have all calls to paid services (for example, 900 numbers in World Zone 1) blocked. If this service is active for the originating user then the OCB service would reject a service request if it were to a paid service. If not, it would proxy the request unchanged. Note: Normal SIP proxy changes would still be applied by the oAS. Unchanged in this context means the originating and target identities are not changed. There are instances where the oAS will modify the originator identity (OID), by changing the P-Asserted-Identity header or the target identity. There are also instances were the oAS will retarget the request by changing the Request URI. A private numbering plan service is an example where this would be the case. In this case the oAS would examine digits in the Request-URI and modify them based on the numbering plan. This might result in a short private dialing string being modified to a fully qualified E.164 number. 3.1. oSM handling of a changed OID The oSM has the following alternatives for handling a change of the identity of the originator of the request: o Reject the request o Continue originating processing for the original OID o Skip to the end of originating processing for the original OID o Restart originating processing for the new OID A mechanism is needed for the oAS to be able to suggest to the oSM how to handle a change in the OID. Donovan Expires August 30, 2006 [Page 7] Internet-Draft The Service-Override Header February 2006 3.2. oSM Handling of a retargeted request The oSM had the following alternatives for handling the retargeting of a request by the oAS: o Continue originating processing for the OID This is the most likely scenario. o Skip to the end of originating processing for the OID o Restart originating processing for the OID An outbound call blocking feature is an example of when this might be required. Donovan Expires August 30, 2006 [Page 8] Internet-Draft The Service-Override Header February 2006 4. Interaction between tSM and tAS In the basic case, the tAS will apply application logic to the request and either reject the request or proxy the request back to the tSM with the identities of the originator and target unchanged. An example service where this might apply is an incoming call screening (ICS) service. For instance, a service provider might offer a service to allow a user to maintain a list of addresses from which the target user will not accept calls. If this service is active for the target user then the ICS service would reject a service request if the OID is included in the targets screening list. If not, it would proxy the request unchanged. Note: Normal SIP proxy changes would still be applied by the oAS. Unchanged in this context means the originating and target identities are not changed. There are instances where the tAS will retarget the request by changing the value of the Request-URI. For example, a service provider might offer a service where a user can have multiple phone numbers (alias's) or other URIs for a single device. The tAS would retarget the request from an alias URI to the "master" URI for the device. There are also instances where the tAS will redirect the request. This results in the value of the Request-URI being changed. It also results in the identity of the redirecting user being included in the proxied request as the OID for the call leg from the redirecting user to the new target URI. Note: One method for indicating the identity of the redirecting user is the use of the Diversion header defined in [5]. It is also possible that use of the History mechanism defined in [6] could be used. Call forwarding, in its various flavors, are example services that result in redirection. 4.1. tSM handling of changed OID Changing of the OID, by adding a new OID, for example by using a Diversion header, to the existing OID(s) is one method that the tSM can identify the request as having been redirected. The handling options for this are outlined in the section on tSM handling of a redirected request. Donovan Expires August 30, 2006 [Page 9] Internet-Draft The Service-Override Header February 2006 4.2. tSM handling of retargeting The tSM has the following options for handling the case where the tAS retargets a request: o Continue terminating processing for the original target URI This is the most likely alternative o Skip to the end of terminating processing for the original target URI and continue with contact routing. No example for this alternative currently come to mind. o Restart terminating processing for the new Request-URI This might me necessary of the service profiles for the original target URI and the new retargeted URI are different. For instance, the service profile for the original target URI might only result in the retargeting where the service profile for the new target URI might have call forwarding logic associated with it. 4.3. tSM handling of redirection The tSM has the following options for the handling of the case where the tAS redirects a request: o Abort terminating processing for the original target Request-URI and initiate originating processing for the redirecting OID For instance, the OCB feature might be invoked to determine if the redirecting user, as indicated by the redirecting OID, is authorized to make a call to the new address included in the Request-URI. Donovan Expires August 30, 2006 [Page 10] Internet-Draft The Service-Override Header February 2006 The following diagram illustrates this type of handling of a redirection: +------+ +------+ +------+ +------+ | | | | | | | | | oAS1 | | tAS2 | | oAS2 | | tAS3 | | | | | | | | | +------+ +------+ +------+ +------+ ^ | ^ | ^ | ^ | 2| |3 5| |6 8| |9 11| |12 | v | v | v | v +------+ +------+ +------+ +------+ | | 4 | | 7 | | 10 | | | oSM1 |---------->| tSM2 |---------->| oSM2 |---------->| tSM3 | | | | | | | | | +------+ +------+ +------+ +------+ ^ | 1| |13 | v +------+ +------+ | | | | | oUA1 | | tUA3 | | | | | +------+ +------+ o Abort terminating processing for the target Request-URI and route the request to the new Request-URI This skips originating processing for the call from the redirecting OID to the new target. Donovan Expires August 30, 2006 [Page 11] Internet-Draft The Service-Override Header February 2006 The following diagram illustrates this type of handling of a redirection: +------+ +------+ +------+ | | | | | | | oAS1 | | tAS2 | | tAS3 | | | | | | | +------+ +------+ +------+ ^ | ^ | ^ | 2| |3 5| |6 8| |9 | v | v | v +------+ +------+ +------+ | | 4 | | 7 | | | oSM1 |---------->| tSM2 |---------->| tSM3 | | | | | | | +------+ +------+ +------+ ^ | 1| |10 | v +------+ +------+ | | | | | oUA1 | | tUA3 | | | | | +------+ +------+ Donovan Expires August 30, 2006 [Page 12] Internet-Draft The Service-Override Header February 2006 5. Proposed Service-Override Header This document proposes an extension to the Session Initiation Protocol to facilitate the interaction between the Service Manager function and the Application Server function. This extension give the AS a mechanism to inform the SM of the action that the AS thinks the SM should take as a result of a change in the OID, a retargeting of a request or a redirecting of a request. The extension proposed is the support of the Service Override header. 5.1. Service-Override Header Syntax The following is the proposed syntax for the Service-Override header: service-override-extension = "Service-Override" HCOLON svc-params *(SEMI svc-params) svc-params = (svc-token / svc-extension) svc-token = "service" EQUAL ( "skip" / "continue" / gen-value ) svc-extension = token [ EQUAL gen-value ] gen-value = token / quoted-string 5.2. Behavior of oSM Same OID with no Service-Override - In this scenario the oSM SHOULD continue with application processing, proxying the request to the next originating application if one is indicated for the originating user or, if originating processing is finished then to the tSM IF the target URI is in the same domain or to the appropriate down stream server if the target URI is in a different domain. Same OID with Service-Override of skip - In this case, the oAS has indicated that it thinks the oSM can skip the remainder of originating request handling. In all cases the oSM has to decide what processing is to be applied to the service request. In this scenario, it will factor the presence of a Service-Override header with a value of skip into the decision of what to do next. It can either continue with originating processing as if the Service- Override header were not there or it can abort originating processing and proxy the request to the target URI. Same OID with Service-Override of continue - This scenario is equivalent to having the same OID with no Service-Override header. Modified OID with no Service-Override - In this scenario, the oSM SHOULD abort originating processing for the original OID and restart Donovan Expires August 30, 2006 [Page 13] Internet-Draft The Service-Override Header February 2006 originating processing for the OID inserted by the oAS. Modified OID with Service-Override of skip - In this scenario, the oAS is suggesting to the oSM that it abort originating processing for the original OID and proxy the request to the target URI. The oSM MUST make the final determination, based on policy and profile information, whether to follow the suggestion in the Service-Override header or to continue with originating processing as if the Service- Override header did not exist. One example of policy that could drive this type of logic in the oSM is an indication of whether an individual AS is trusted. The oSM might decide to implement the Service-Override skip logic only for a trusted AS. Modified OID with Service-Override of continue - In this scenario the AS is suggesting to the oSM that the new OID be ignored and that originating processing be continued based on the original OID. An example service for this scenario is an aliasing service where the oAS is allowed to modify the identity presented to the target user. This does not change the identity of the originating user that is used for originating processing. oAS retargeting - The handling of the Service Override header is not changed in the oSM in the oAS retargeting scenarios. 5.3. Behavior of tSM No request-URI change with non Service-Override - In this scenario the tSM SHOULD continue with application processing, proxying the request to the next terminating application if one is indicated for the target user or initiating contact routing when there are no more terminating applications. No request-URI change with Service-Override of skip - In this case, the tAS has indicated that it thinks the tSM can skip the remainder of terminating request handling and proceed with contact routing. In all cases the tSM MUST decide what processing is to be applied to the service request. In this scenario, it will factor the presence of a Service-Override header with a value of skip into the decision of what to do next. It can either continue with terminating application processing as if the Service-Override header were not there or it can abort terminating processing and initiate contact routing. No request-URI change with Service-Override of continue - This scenario is equivalent to having no Service-Override header with no change of the target URI. Donovan Expires August 30, 2006 [Page 14] Internet-Draft The Service-Override Header February 2006 Retarget with no Service-Override - In this scenario the tSM SHOULD re-start terminating processing using the new target URI value in the request-URI to determine the terminating applications to be invoked. Retarget with Service-Override of skip - In this case, the tAS is indicating that it thinks the tSM can skip the remainder of terminating application processing and proceed to contact routing. In all cases the tSM MUST decide what processing is to be applied to the service request. In this scenario, it will factor the presence of a Service-Override header with a value of skip into the decision of what to do next. It can either continue with terminating application processing as if the Service-Override header were not there or it can abort terminating processing and initiate contact routing. Retarget with Service-Override of continue - In this scenario the tAS is suggesting to the tSM that it continue with terminating processing as if the retargeting had not happened. Redirect with no Service-Override - In this scenario, the tSM is being requested to abort terminating processing and start originating processing for the redirecting user. Redirect with Service-Override of skip - In this scenario, the tSM is being requested to abort terminating and skip originating processing for the redirecting user. In this case, the tSM simply routes the request to the new request-URI. Redirect with Service-Override of continue - This scenario is equivalent to the redirect scenario with no Service-Override header. 5.4. Removal of Service-Override header In all cases the oSM and the tSM MUST remove the Service-Override header before routing the request to the next hop. Donovan Expires August 30, 2006 [Page 15] Internet-Draft The Service-Override Header February 2006 6. Security Considerations The following are security considerations that require further study with regards to the Service-Override header: o Untrusted application servers o Hi-jacked application servers 7. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, J., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06.txts (work in progress), October 2005. [5] Levy, S. and B. Byerly, "Diversion Indication in SIP", Internet- Draft http://www.softarmor.com/wgdb/docs/ draft-levy-sip-diversion-08.txt, August 2004. [6] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", Internet- Draft http://www.softarmor.com/wgdb/docs/ draft-levy-sip-diversion-08.txt, August 2004. Donovan Expires August 30, 2006 [Page 16] Internet-Draft The Service-Override Header February 2006 Author's Address Steven R. Donovan Cisco Systems 2200 E. President George Bush Turnpike Richardson, TX 75082 USA Phone: +1 972 255 0248 Email: srd@cisco.com Donovan Expires August 30, 2006 [Page 17] Internet-Draft The Service-Override Header February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Donovan Expires August 30, 2006 [Page 18]