SIPPING S. Donovan Internet-Draft C. Sivachelvan Expires: December 25, 2006 Cisco Systems June 23, 2006 The Service-State Header draft-donovan-sipping-service-override-01.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 December 25, 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-State header, is used to communicate application state between two SIP elements. Note: The name of the file will be updated to be consistent with the proposed header name in the next revision of the draft. Donovan & Sivachelvan Expires December 25, 2006 [Page 1] Internet-Draft The Service-State Header June 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 & Sivachelvan Expires December 25, 2006 [Page 2] Internet-Draft The Service-State Header June 2006 2. Introduction RFC 3261 [1] proposes a deployment architecture for SIP based network referred to as the SIP trapezoid. This model shown in the following figure, shows the relationship between the SIP clients and the SIP proxy servers involved in routing of requests between the clients. +------+ +------+ |Alice | SIP | Bob | |Domain|-----------|Domain| |Proxy | |Proxy | +------+ +------+ / \ /SIP SIP\ / \ +------+ +------+ |Alice | RTP | Bob | |Client|-------------------|Client| | | | | +------+ +------+ In this model, Alice's clients sends all SIP communication through Alice's proxy. Bob's client does the same. As a result, a SIP request from Alice's client to Bob's client flows from Alice's client through Alice's proxy, then through Bob's proxy and then to Bob's client. The proxies play a number of roles for the client. These roles are discussed in RFC 3261. Deployments of SIP based networks have extended on the SIP trapezoid model to allow for the separation between the basic routing functions of the proxies required in the basic SIP trapezoid model and applications that are involved in the delivery of SIP based services. The extended SIP trapezoid model looks as follows: Donovan & Sivachelvan Expires December 25, 2006 [Page 3] Internet-Draft The Service-State Header June 2006 +------+ +------+ |Alice | | Bob | | Appl | | Appl | |Server| |Server| +------+ +------+ | | |SIP SIP| | | +------+ +------+ |Alice | SIP | Bob | |Domain|-----------|Domain| |Proxy | |Proxy | +------+ +------+ / \ /SIP SIP\ / \ +------+ +------+ |Alice | Media | Bob | |Client|-------------------|Client| | | | | +------+ +------+ In this model, there is an application server associated with Alice and an application server associated with Bob. Service requests are optionally routed through the application server to apply application specific logic. Note that in this architecture, there can be multiple application servers for Alice and multiple for Bob. This document proposes and extension to SIP. This extension defines a mechanism for the application server to includes state in the SIP messages flowing between the proxy and the application server. This state can be used by the proxy when it is determining how to route the SIP requests after they have been handled by the application server. Donovan & Sivachelvan Expires December 25, 2006 [Page 4] Internet-Draft The Service-State Header June 2006 3. The Extended SIP Trapezoid The Extended SIP Trapezoid is a SIP deployment architecture that facilitates the separation of SIP routing functions from SIP application functions. This architecture allows application developers to focus on the application logic without the need to understand the intricacies of the SIP protocol. This model separates the processing of the proxies in the classical SIP trapezoid into two logical functions, 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 addition, the AS can be deployed as a redirect server if it fits the requirements of the application being deployed. The following figure shows the extended SIP trapezoid architecture. +------+ +------+ | | | | | oAS | | tAS | | | | | +------+ +------+ | | |SIP SIP| | | +------+ +------+ | | SIP | | | oSM |-----------| tSM | | | | | +------+ +------+ / \ /SIP SIP\ / \ +------+ +------+ | | Media | | | oUA |-------------------| tUA | | | | | +------+ +------+ The following is a description of each of the elements in the architecture: Donovan & Sivachelvan Expires December 25, 2006 [Page 5] Internet-Draft The Service-State Header June 2006 o oUA - Originating User Agent - The user agent for the client originating the service request. o oSM - Originating Server Manager - 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. o oAS - Originating Application Server - 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. o tSM - Terminating Service Manager - 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. o tAS - Terminating Application Server - An Application Server applying a 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. o tUA - Terminating User Agent - 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. 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. The SM can chose to route a service request to multiple Application Servers. This is referred to as chaining of applications o Routing of service requests between the originating SM and the terminating SM; Donovan & Sivachelvan Expires December 25, 2006 [Page 6] Internet-Draft The Service-State Header June 2006 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. This can include applying application specific routing, retargeting the request to one or more users, redirecting the request to a new user and rejecting the request. 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 Donovan & Sivachelvan Expires December 25, 2006 [Page 7] Internet-Draft The Service-State Header June 2006 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 the appropriate server for the target domain. If it had determined that the request should be routed through multiple application servers then it would have proxied the request to the next AS. 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. 3.1. Definitions Originator Identity (OID) - The identity of the originator or a 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 Target - The target of a request is the URI contained in the request-URI. 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 Donovan & Sivachelvan Expires December 25, 2006 [Page 8] Internet-Draft The Service-State Header June 2006 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 & Sivachelvan Expires December 25, 2006 [Page 9] Internet-Draft The Service-State Header June 2006 4. Interaction between the oSM and oAS In the basic case, the oAS will apply application logic to the request. The oAS can then do one of the following: o Reject the request due to application specific logic. o Redirect the request using the appropriate 300-class response. o Handle the request as a UAS. o Proxy the request back to the oSM. o Re-originate the request back to the oSM, acting as a B2BUA. In the cases where the oAS returns the request to the oSM, it can also change information contained in the request. For instance, the oSM could retarget the request, changing the address in the request- URI. 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 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. 4.1. 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 Donovan & Sivachelvan Expires December 25, 2006 [Page 10] Internet-Draft The Service-State Header June 2006 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. In order to understand the correct action to take, the oSM might need information on why the request was retargeted. There is currently no mechanism in SIP for doing so. This is one of the motivations for the extension proposed in this document. Donovan & Sivachelvan Expires December 25, 2006 [Page 11] Internet-Draft The Service-State Header June 2006 5. Interaction between tSM and tAS As with the oAS, in the basic case, the tAS will apply application logic to the request. The tAS can then do one of the following: o Reject the request due to application specific logic. o Redirect the request using the appropriate 300-class response. o Handle the request as a UAS. o Proxy the request back to the tSM. o Re-originate the request back to the tSM, acting as a B2BUA. 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 tAS. 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] Donovan & Sivachelvan Expires December 25, 2006 [Page 12] Internet-Draft The Service-State Header June 2006 could be used. Call forwarding, in its various flavors, are example services that result in redirection. Second Note: This is different from redirecting the request using a SIP defined 300-class redirection response. An application would handle the redirection directly, as discussed here, if it needs to be in the path of responses to the request or if it needs to be in the path of mid-dialog requests for requests that result in dialogs being established. Sending a 300-class response takes the AS out of the signaling path for responses and subsequent mid- dialog requests. 5.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. 5.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. This has the result of not routing the request to other tASs that would have been invoked otherwise. 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. Donovan & Sivachelvan Expires December 25, 2006 [Page 13] Internet-Draft The Service-State Header June 2006 5.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. 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 & Sivachelvan Expires December 25, 2006 [Page 14] Internet-Draft The Service-State Header June 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 | | | | | +------+ +------+ In order to understand the correct action to take, the tSM might need information on why the request was retargeted. There is currntly no mechanism in SIP for doing so. This is one of the motivations for the extension proposed in this document. 5.4. SM selection of next application One of the jobs of the SM is to determine what applications to invoke for a given service request. The selection of the initial application can be done based on the context known at the time that the service request was received. As stated previously, this can be based on the content of the service request. It can also be based on provisioned data about the user that originated the request or the user that is the target of the request. The challenge becomes determining the application that should be invoked after the first, or more generally, after any application has finished handling a request. This decision can take the original context of the service request into consideration. However, there are situations where the decision also needs to be made based on the results of application, or applications, that have already handled the request. Donovan & Sivachelvan Expires December 25, 2006 [Page 15] Internet-Draft The Service-State Header June 2006 For example, consider the case where the following is the desired application logic for a given service request: 1. Invoke application 1 2. If application 1 is successful with result of foo then invoke application 2 3. If application 1 is successful with result of bar then invoke application 3 As another example, consider the case where the following logic is the desired application logic: 1. If application 1 is not successful for reason foo then invoke application 2 2. If application 1 is not successful for reason bar then invoke appliation 3 3. If application 1 is not successful for all other reasons then reject the service request with reason xyz. One of the purposes of this document is to define a standard mechanism for the AS to communicate success or failure of an application along with result state to the SM. Donovan & Sivachelvan Expires December 25, 2006 [Page 16] Internet-Draft The Service-State Header June 2006 6. Proposed Service-State 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 took with the request. This information can then, in turn, be used by SM to determine what it should do next with the request. The extension proposed is the Service-State header. 6.1. Service-State Header Syntax The following is the proposed syntax for the Service-State header: Service-State-extension = "Service-State" HCOLON svc-params *(SEMI svc-params) svc-params = (svc-token / svc-extension) svc-token = "state" EQUAL gen-value svc-extension = token [ EQUAL gen-value ] gen-value = token / quoted-string 6.2. Use of the Service-State header The Service-State header is optionally inserted by the AS into requests and responses sent from the AS to the SM. The Service-State header can be carried in any request or response sent from the AS to SM, with the exception of the CANCEL request. The content of the state token and any semantics associated with it is outside the scope of this specification. Definition of the syntax and semantics associated with the state token is a local policy issue. It requires consistent definition between the AS and the SM. 6.3. Behavior of SM The SM can receive the Service-State header in a SIP message in the following cases: o Failure Responses - 400, 500 and 600 class responses. Donovan & Sivachelvan Expires December 25, 2006 [Page 17] Internet-Draft The Service-State Header June 2006 o Redirect Responses - 300 class responses. o Success Responses - 200 class responses. o Proxied Requests o B2BUAed Requests The action taken in each of these cases depends on the content of the state token in the Service-State header. The definition of that action is outside the scope of this specification. 6.4. Removal of Service-State header In all cases the oSM and the tSM MUST remove the Service-State header before routing the request or response to the next hop. This includes cases: o The SM routes a request to another AS. o The oSM routes a request to the tSM. o The SM routes a request to another SIP server. o The SM routes a request to the tUA. o The SM routes a response upstream. Donovan & Sivachelvan Expires December 25, 2006 [Page 18] Internet-Draft The Service-State Header June 2006 7. Security Considerations Use of the state included in the Service-State header by the SM can affect the service received by users of the system. As such, the SM should only take actions using the information in the Service-State header if the application is trusted. Note that this is not a security concern that is unique to the Service-State header. It is inherent in the Extended SIP Trapezoid deployment architecture that splits functions between the SM and the AS. The mechanism for establishing trust between the SM and the AS is outside the scope of this specification. 8. 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 & Sivachelvan Expires December 25, 2006 [Page 19] Internet-Draft The Service-State Header June 2006 Authors' Addresses Steven R. Donovan Cisco Systems 2200 E. President George Bush Turnpike Richardson, TX 75082 USA Phone: +1 972 255 0248 Email: srd@cisco.com Chelliah Sivachelvan Cisco Systems 2200 E. President George Bush Turnpike Richardson, TX 75082 USA Phone: +1 972 255 1169 Email: chelliah@cisco.com Donovan & Sivachelvan Expires December 25, 2006 [Page 20] Internet-Draft The Service-State Header June 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 & Sivachelvan Expires December 25, 2006 [Page 21]