Internet Engineering Task Force J.Bjorkner, INTERNET-DRAFT H.Gustafsson Document: draft-bjorkner-sip-serviceroute-00.txt Hotsip Expires January 13 2001 September 1 2001 Service Route Header extension STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document proposes a SIP header extension to allow for a UAC or outbound proxy to determine a request path through an initial set of downstream SIP proxies, i.e. a loose route mechanism. This is useful in scenarios of distributed service execution if for example a UA is located in a visited network and want have originating services executed in the user's home network. This solution is also applicable in the scenarios required by 3GPP in conjunction with the proposed path header. 1. Conventions used in this document 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 RFC-2119 [2]. J.Bjorkner,H.Gustafsson 1 Internet Draft service route September 2001 2. Introduction Routing services located in SIP proxies could be distributed over the network in specialized SIP servers executing a particular service. This means that a call can get routed through several SIP servers during call setup to invoke the set of services that a caller is subscribing for. For example a concept of service brokers may be used to manage a set of distributed routing services for the service providers. The service broker has the knowledge of which services a user is subscribing for. The broker has the knowledge of where to execute the services and where the services are configured. Thereby a single point of configuration towards the customers can be achieved in an environment of distributed service execution. The proposed extension can also be utilized by a UAC to indicate a route path to be followed for a request. This may be useful if a user is located in a visited network and have to use an outbound proxy in that network but still wants to be able to invoke his outbound services in his outbound proxy in his home domain. Previous proposals [3] have let the SIP application server set up separate signaling legs towards the different services that a user subscribes for, and the control have been returned to the application server after each service has been executed. i.e. the services have been executed in parallel. This proposal allows for (not mandates) a model where several services can be executed in serial, and the only centralized point in the service chain is the service broker that has references to the services to be executed, but hands off the control to the service servers themselves after the initial service lookup. This model is useful in the scenario when a customer is subscribing for services from several application service providers, or in a wireless environment when he has roamed to another network but still wants to have the services he is subscribing for in the home network executed there. The routing of a SIP request through a chain of proxies without affecting the original request URI, also called loose routing, is of interest for the 3GPP work where a route set is returned in a path header in the response of a SIP registration. The proposal in this document is also applicable to solve this problem. The functionality stated above could be achieved by the introduction of a new SIP header, service-route:. The service route has almost the same semantics as the route header but with the purpose to indicate which SIP application servers to traverse in a signaling path. How it works will be described in the sections below. The main difference is that a hop caused by a service route header doesn't change the request URI of the request, as opposed for the route header. In the case of using the route header, the request URI will be replaced by the SIP URL in the route header. This allows the creation of services that have to modify the request URI before forwarding the request. J.Bjorkner,H.Gustafsson Expires March 1 2002 [2] Internet Draft service route September 2001 The concept of service route have been implemented and tested with successful results. 3. Problem Statement Routing services is a quite common service offered in communication networks. Examples of traditional routing services for telephony are 800-number, private number plans and call barring services. Those among new services, such as presence based routing services and services giving value to other communication means than voice such as gaming, video and instant messaging, could be deployed using a SIP based infrastructure in a more efficient way than traditional technology. This is one of the reasons why SIP has gained so much in popularity recently. A lot of people talk about SIP's advantages to open up the networks by allowing the service providers to integrate services from several vendors into a complete offering to the end users, either by hosting the services themselves or resell the service from application service providers. This document proposes an extension to SIP that simplifies the integration of several SIP services by using a distributed service execution model by introducing a new SIP header. The underlying model is that the end is associated with an entity in the network that has the knowledge of the different routing services that the user is subscribing for. For example could this be a special outbound proxy, called a service broker. The service broker also uses a database to keep track of which services a particular user is subscribing for. The service broker could in many ways be viewed as an ordinary SIP proxy since its basic purpose is to forward incoming SIP messages to the application servers providing the services. The proposed header extension also works without a service broker entity in the network if the execution path could be communicated out to the sip UA by some means. Those means could for example be static UA configuration or dynamic configuration using the proposed 3GPP path header. The main idea is that all originating requests will get routed through the application servers implementing the services that a user subscribes for. If a user is subscribing for several services, it is desired to be able to have those services called in serial to avoid unnecessary state keeping in the network, i.e. the original request contains necessary information for the downstream proxies to use for next hop routing decisions. The problem with this approach rises when there are several services to be executed. The service broker or UAC will forward the request to the first application in the service chain and forgets about the request. But how should this server know which application server that is next in the execution path? A first idea would be to indicate this using the route header. The problem with this approach is the semantics of the route header. A proxy is assumed to copy the SIP URI in the route header to the request URI before forwarding the request to the host indicated in the route header. This could cause J.Bjorkner,H.Gustafsson Expires March 1 2002 [3] Internet Draft service route September 2001 problems for some application servers that want to modify the URI and have that forwarded to the next hop. Either the semantics of route be broken, which seems to be a bad idea since there exist a lot of confusion already today among implementers how to use it, or an alternative solution to the problem has to be found. This document describes an alternate solution to the problem, the service-route: header. In this model, the application servers can be viewed as operators operating on the incoming SIP requests. Each operator has access to the incoming request and can perform some logic to be applied on the incoming request. Each application server can then either return a response to the incoming request upstream or modify the request URI before forwarding the request downstream to the rest of the application servers. A complete service offered to the end user is built up from a set of operators operating on the SIP request. In this model, it is also possible to allow the end user to have subscriptions of services offered by different application service providers where the user id for the service execution context is different among the different application service providers. In this situation, the user name is used for a particular application server carried as a parameter to the service-route header. 4. Definition of Service-route header Where Proxy ACK BYE CAN INV OPT REG Service-Route R ar - - - o o o A UAC or proxy that inserts the service-route header MUST also insert a proxy-require header requiring that all downstream proxies support this extension, called "service-route". Otherwise the proxy in the chain that doesn't support the extension will break the routing path. 4.1. Semantics The service-route header is used to carry information to an application server about where to route the request for the next hop, independent of the request URI of the request. The service- route header could also contain parameters to be used for service execution, such as a user-id for execution of the service. The service-route headers build up a list describing a path to be taken through several application servers, similar to the route headers. The difference is that the receiving server, not the sending server as in the case of route headers, removes the next hop server from the list. This allows us to transport parameters that could be used for service execution using those headers. A list of service-route headers could either be inserted to a request by a UAC, or by an application broker proxy that is used as an outbound proxy for a UAC. The service-route header should only be inserted by the first request in a call leg. In the case where the same path has to be J.Bjorkner,H.Gustafsson Expires March 1 2002 [4] Internet Draft service route September 2001 traversed by subsequent requests in the same call leg, those proxies MUST insert record-route headers into the first request. If it happens that a request contains both service-route headers and route headers, the route headers MUST be used for request routing. In this case the last route header points to a UAS, which MUST ignore the set of service-route headers. 4.2. Syntax The service-route header determines the path to be taken by a SIP request for routing through a set of SIP application servers. A SIP proxy with service-route support or UAC adds multiple service route headers to a request to indicate a path to be taken by the request. Since this is a loose route mechanism any proxy MAY in this route break the chain by returning a final response upstream. When a proxy with service-route support receives a request, the first of the service route headers is checked. If this matches the receiving application server, the entry is removed. It then performs some service execution, and MAY modify the request URI of the incoming request. The request is checked for any more service route headers. If such is present it then forwards the request to the host indicated in this entry without modifying the request URI. In the case of no more service route headers, the request is forwarded to the host indicated in the request URI and the proxy-require requirement for service-route SHOULD be removed. Service-Route = "Service-Route" ":" 1# (name-addr) 5. Example A UAC sends an INVITE through two service proxies. [UAC] ->[out.operator.com] ->[other.com] ->[operator.com] ->[UAS] Request sent from UAC and received in out.operator.com: INVITE sip:hegu@operator.com SIP/2.0 Via: . . . From: sip:jbj@operator.com;tag=42 To: sip:hegu@operator.com Call-ID: . . . Cseq: . . . Contact: sip:jbj@212.28.214.227 Content-Length: . . . Content-Type: application/sdp Service-Route: sip:out.operator.com, sip:other.com Proxy-Require: service-route . . . J.Bjorkner,H.Gustafsson Expires March 1 2002 [5] Internet Draft service route September 2001 Request sent from out.operator.com and received in other.com: INVITE sip:hegu@operator.com SIP/2.0 Via: . . ., . . . From: sip:jbj@operator.com;tag=42 To: sip:hegu@operator.com Call-ID: . . . Cseq: . . . Contact: sip:jbj@212.28.214.227 Content-Length: . . . Content-Type: application/sdp Service-Route: sip:other.com Proxy-Require: service-route . . . Request sent from other.com and received in operator.com: INVITE sip:hegu@operator.com SIP/2.0 Via: . . ., . . ., . . . From: sip:jbj@operator.com;tag=42 To: sip:hegu@operator.com Call-ID: . . . Cseq: . . . Contact: sip:jbj@212.28.214.227 Content-Length: . . . Content-Type: application/sdp Record-Route: sip:hegu@operator.com;maddr=other.com . . . Request sent from operator.com and received in UAS: INVITE sip:hegu@212.28.214.228 SIP/2.0 Via: . . ., . . ., . . ., . . . From: sip:jbj@operator.com;tag=42 To: sip:hegu@operator.com Call-ID: . . . Cseq: . . . Contact: sip:jbj@212.28.214.227 Content-Length: . . . Content-Type: application/sdp Record-Route: sip:hegu@operator.com;maddr=other.com . . . J.Bjorkner,H.Gustafsson Expires March 1 2002 [6] Internet Draft service route September 2001 Response sent from UAS to UAC according to the via headers. SIP/2.0 200 OK Via: . . ., . . ., . . ., . . . From: sip:jbj@operator.com;tag=42 To: sip:hegu@operator.com;tag=11 Call-ID: . . . Cseq: . . . Content-Length: . . . Content-Type: application/sdp Record-Route: sip:hegu@operator.com;maddr=other.com Contact: sip:hegu@212.28.214.228 . . . ACK sent from UAC to UAS via the other.com proxy. (Following the route): ACK sip:hegu@operator.com;maddr=other.com SIP/2.0 Via: . . . From: sip:jbj@operator.com;tag=42 To: sip:hegu@operator.com;tag=11 Call-ID: . . . Cseq: . . . Route: sip:hegu@212.28.214.228 Content-Length: . . . . . . 6. Open Issues According to RFC2543bis3 a proxy MUST NOT add a proxy-require header. What happens if a UAC that does not add proxy-require receives a 420? Even worse we would like to remove the proxy-require when all service-route headers are consumed. 10. Acknowledgments Thanks to Hisham Khartabil and Johan Liseborn, Hotsip for review and input. J.Bjorkner,H.Gustafsson Expires March 1 2002 [7] Internet Draft service route September 2001 11. Author's Addresses Jorgen Bjorkner Hotsip AB Barnhusgatan 16 SE-111 23 Stockholm Sweden Phone: +46 70 666 23 26 Email: Jorgen.Bjorkner@Hotsip.com Henrik Gustafsson Hotsip AB Barnhusgatan 16 SE-111 23 Stockholm Sweden Phone: +46 70 364 65 68 Email: Henrik.Gustafsson@Hotsip.com 12. Bibliography 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, M., et al., "SIP: Session Initiation Protocol", RFC 2543, March 1999 3 Rosenberg, J. et.al. "An Application Server Component Architecture for SIP", http://search.ietf.org/internet- drafts/draft-rosenberg-sip-app-components-01.txt J.Bjorkner,H.Gustafsson Expires March 1 2002 [8]