Internet DRAFT - draft-bjorkner-sip-serviceroute
draft-bjorkner-sip-serviceroute
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]
