Internet Engineering Task Force SIP WG
Internet Draft J. Peterson
draft-jfp-sip-servicecodes-00.txt Level(3) Communications
February 2001
Expires: August 2001
A Model for Service Invocation in SIP using ServiceCodes
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Although the Session Initiation Protocol (SIP) needs no special
mechanism to enable network services and applications, in complex
architectures, feature composition and service invocation become
unmanageable without a mechanism for specifying the services that are
associated with routes. This draft introduces distributed application
architectures that span multiple administrative domains and proposes
the use of ServiceCodes in SIP to allow service providers to compose
chains of features across application servers.
1. Introduction
The Session Initiation Protocol (SIP, [2543]) is a protocol that
allows network elements to discover one another in order to exchange
contextual information about a session (usually real-time media
transmission) they would like to share. As SIP is frequently used for
Peterson [Page 1]
Internet-Draft SIP ServiceCode Feb 2001
Internet telephony service, service providers are grappling with the
problem of offering familiar telephone features to end users. Recent
work has demonstrated that while some features are best implemented
within SIP endpoints themselves, others are more suited to
centralized implementation at nodes owned by service providers; this
has given rise to a class of SIP network elements known as
application servers (or AppServers for short).
Application servers (which are described in detail below) are
repositories of service logic to which an Internet telephony service
provider can route calls. In simple network architectures, SIP
accommodates this model of service invocation without modification.
However, as the architecture of the networks involved grows more
complex, certain problems arise which require a clarification within
signaling of which services should be executed.
To that purpose, this draft illustrates how ServiceCodes (described in
[SIP-SC]) can be used within the Request-URI of a SIP message to
denote which service an application server should execute. It also
recommends design methodologies for network implementers and authors
of applications that will facilitate feature composition and thereby
enhance user experience.
This draft is agnostic to the means by which ServiceCodes are
provisioned in the service provider network; proxy servers can be
provisioned manually with ServiceCodes associated with specific
specific routes. However, the full power of ServiceCodes is only
realized when dynamic route provisioning through a protocol like TRIP
(see [TRIP] and [TRIP-L]) is utilized.
2. Application Servers
The concept of an application server is a fairly common one in SIP.
Service logic is commonly understood to be implemented by
applications that execute on these application servers. AppServers
are not formally defined in the SIP standard; however, their behavior
often replicates that of a redirect server, a proxy/location server,
or a user agent.
An AppServer usually resides on a general purpose computer. It may
be composed of a SIP interface coupled tightly with some particular
logic, or the logic may be a modular component programmatically
segregated from the SIP interface itself. In this latter case, an
AppServer would support one or more authoring systems that provide a
framework in which modular logic can be written.
An authoring system constitutes a set of tools that allow a service
provider to create an instance of service logic that will operate on
Peterson [Page 2]
Internet-Draft SIP ServiceCode Feb 2001
an AppServer. These tools range from graphical Service Creation
Environments to scripting languages to bare-bones Application
Programming Interfaces. Common authoring systems include SIP CGI (see
[CGI]) and CPL (see [CPL]).
Deployment of AppServers is becoming common today in Internet
Telephony Service Provider (ITSP) networks; however, more commonly
SIP Application Service Providers (ASPs), who not only host
AppServers but also author applications, offer network access to
their AppServers to ITSPs. This decomposition is desirable for ITSPs
in so far as application development and management can be
outsourced, allowing for more rapid introduction of services to the
network.
3. Two Service Invocation Problems
SIP needs no special mechanism to invoke service logic stored in an
AppServer. Commonly, a SIP network element elects to route a session
to an AppServer just as it might route a session to a conventional
endpoint - the AppServer is then responsible for dealing with the
call as its services dictate. This model is adequate for
instantiating features in a simple network, but, as network
architectures become more complicated, some problems arise. Notably,
once ASPs offer an ITSP access to AppServers where features are
instantiated, service invocation becomes problematic, especially when
multiple features (a 'feature chain') may be required in the course
of routing a particular session.
Consider a case in which a proxy server in an ITSPs network has been
provisioned with a route, which we'll call R1, that points to an
AppServer in an ASP network. By 'route' we signify here a mapping
from an element extracted from a SIP INVITE message that is used to
route the call (or 'routable element' for short) to a SIP endpoint
that is the proper destination for the INVITE. So, to take a simple
example, a prefix matching route for telephone numbers (which appear
in the Request-URI of an INVITE as tel URLs) to a particular
AppServer might be represented as follows:
+17208881 -> appserver.asp.net:5060
When call arrives at the proxy server which meets R1's criteria (i.e.
it matches the prefix '+17208881'), the proxy server will forward the
INVITE to the AppServer.
A problem arises, however, when the AppServer in question manages
more than one application. The AppServer must use some criteria
(probably something similar to the routes described above) to
Peterson [Page 3]
Internet-Draft SIP ServiceCode Feb 2001
determine which applications should service any given call. What if
the ITSP wanted only one particular application operated by the ASP
to be applied to the call? One ASP might have favorable rates and
policies for, say, Local Number Portability (LNP) dips, but another
ASP is a better provider of freephone translation; if both services
need to be invoked for a single call, how can the ITSP prevent either
of the ASPs from performing both services when their respective
AppServers are handed control of the call?
Two issues arise from this example.
First, when an ITSP provisions a route in its network, it is not
possible for the ITSP to express, when applicable, which service it
is attempting to invoke. Therefore, the ASP must attempt to analyze
the routable elements within the INVITE itself, and to choose
services appropriately. This draft proposes the use of ServiceCodes
in SIP to allow the network elements of an ITSP to identify one or
more particular services which should be executed by an ASP.
Second, if multiple services are to be enacted for a single session,
there needs to be a single point of feature composition which
dictates the order in which services will be executed and identifies
the AppServers that are to be awarded the right to
perform a service for a particular session. This draft proposes a
logical 'feature proxy' function of an ITSP network that provides
such a single point of composition. In order to allow such
composition to take place, applications implemented by ASPs should be
designed with composition in mind, when possible.
4. Using ServiceCodes in SIP
No extensions to SIP are required to make use of ServiceCodes.
Rather, an optional URI parameter is proposed for use within the
Request-URI of INVITEs that bear ServiceCodes.
The parameter will use the token 'sc=', followed by the ServiceCode
in question. The format and semantics of ServiceCodes are
authoritatively described in [TRIP-SC]; in brief, ServiceCodes are
IANA-registered two-byte numbers. In SIP, ServiceCodes should be
represented in ASCII (e.g. '0' to '65535').
For example:
INVITE tel:+18775550000;sc=1 SIP/2.0
ServiceCodes can appear multiple times within the Request-URI if the
ITSP desires the invocation of more than one service.
Peterson [Page 4]
Internet-Draft SIP ServiceCode Feb 2001
INVITE tel:+18775550000;sc=1;sc=2;sc=3 SIP/2.0
5. Centralizing Feature Composition
An ITSP has a set of subscribers to whom it provides 'Internet
telephony' service. Generally, such service implies that the ITSP is
responsible for tracking the presence of subscribers (who might, for
example, be sending REGISTER messages to ITSP registrar proxies) and
subsequently routing appropriate calls to available subscribers.
'Internet telephony' service might also entail the presence of local
outbound proxies to which subscribers send their outbound SIP calls.
Services might target SIP messages associated, from the subscriber's
perspective, with either inbound or outbound calls. Therefore, any
single point of feature composition must serve as both a location
server (to which inbound messages for a subscriber are sent) and a
local outbound proxy (the target of calls from subscribers). In fact,
these two resources need only be consistent in provisioning to serve
as a point of feature composition.
The term "feature proxy" will be used in this document to denote the
logical function, in the ITSP network, of a location server and local
outbound proxy that can be provisioned with routes accompanied by
ServiceCodes.
In order for a feature proxy to compose multiple features together
effectively, the feature proxy, rather than any other element in the
ITSP or ASP network, must be solely responsible for selecting the
services that will execute and the order in which these services
resolve. This control ultimately must derive from the implementations
developed by ASPs for applications.
6. Designing Services for Service Composition
Many (if not most) services operate on session signaling; that is,
the application analyzes certain elements of an INVITE and
subsequently either sends a response message back to the originator
or, potentially, modifies the signaling and sends it to a new
destination. Some services may also require access to session media,
in which case the service must effectively terminate the call,
although it may re-originate the call if necessary.
In order for services to be composed at the feature proxy, the
general agreement between ASP and ITSP must specify that if an
AppServer does not intend to complete the call with any of the
services specified by the ITSP in the INVITE, it must return control
of the call to ITSP. An AppServer's options, then, for handling a
call are as follows:
Peterson [Page 5]
Internet-Draft SIP ServiceCode Feb 2001
o Redirect - Modifies only the Request-URI (via 3xx message)
o Spiral - Modifies arbitrary elements of the INVITE (retains idempotency)
o Terminate - Responds with either an OK or >300 code (may re-originate)
While these three alternatives may initially seem limiting, really,
these are the tools commonly used to implement applications today. The
primary distinction is that AppServers often choose to proxy the
call to a destination based on its own internal routing logic rather
than spiraling the call back to the server from which it received
the call.
It could be argued that nothing guarantees, in this sort of
architecture, that an ASP will play by the rules, as it were, and
allow features to be composed at the feature proxy. The underlying
incentive for an ASP to play by the rules is that the end user will
expect feature composition and will not put up with services that
prohibit it. If an end user subscribes to a new call-waiting service,
and because of that subscription their voicemail suddenly doesn't
work any more, then (provided there are alternatives) the end user
will most likely shop for call-waiting services elsewhere.
6.1 Redirect
Some services may need only to modify the Request-URI of an INVITE.
In these cases, a service may want to use a redirection (3xx) SIP
message to express the new Request-URI for this session.
Once an AppServer has returned a redirection for a call, it will no
longer be in the path of signaling, and no further state needs to be
kept for the call once an acknowledgment to the redirection has been
received. Redirection services thus tend to be fast and scalable.
When a redirection is sent, the new Request-URI for the INVITE is
contained in the Contact header. A service can send multiple Contact
headers, if desired; usually these Contacts will be searched in
parallel, although this is highly dependent on the ITSP network
architecture.
6.2 Spiral
If modification of headers (rather than the Request-URI) is required
for a service, then the ASP must return an INVITE to the ITSP
network, with modifications, rather than redirecting with a 302; this
practice is known as 'spiraling' the request.
If the spiraling is employed, more or less any aspect of the INVITE
Peterson [Page 6]
Internet-Draft SIP ServiceCode Feb 2001
can be modified that does interfere with idempotency (i.e. the To,
From, Call-ID, and CSeq headers) and which does not give rise to
message routing failures.
Unlike redirection, spiraling forces the AppServer to be in the path
of responses for the signaling (since the AppServer must add a Via
header). If this is desirable for the implementation of the service,
the AppServer may add itself to the Record-Route in the INVITE in
order to be in the path of new requests for the call.
Of course, when a request is spiraled, it is not possible to express
multiple route choices in a single INVITE; if the service requires
multiple choices to be explored, each choice must be sent in its own
INVITE, and the AppServer will field all responses to one such
INVITE. If a rejection is received by the AppServer it may send a new
INVITE that explores any alternative route choice for the call.
Caching of route choices is not possible when a request is spiraled.
6.3 Terminate
For a variety of services, an ASP may find it useful to terminate a
call provisionally at an AppServer which has an associated media
server. While the call is 'parked' in this fashion, the media server
may play announcements to the caller, collect tones, or perform
similar actions.
To park a call, an AppServer must return a 200 OK, providing an
ordinary termination for the call. The media characteristics in the
SDP within the 200 should reflect an available resource in the media
server which the AppServer controls.
Once the call has been parked, the service may decide to send the
call to a final destination (possibly after some interaction with the
caller through the audio channel). At this time, the service behaves
as a B2BUA (back-to-back user agent).
For the purposes of feature composition no services can follow the
invocation of a service that results in call completion. If a
complete is actually a B2BUA, and the B2BUA spins a new leg of the
call back to the feature proxy, it will be treated as a new call with
a new feature chain.
7. Associating ServiceCodes with Routes
When a feature proxy sends an INVITE with a ServiceCode, it will do
so on the basis of provisioning. As was illustrated above, an ITSP's
feature proxies will be provisioned with routes that direct calls
matching certain criteria to the ASP's AppServers. Those routes may
Peterson [Page 7]
Internet-Draft SIP ServiceCode Feb 2001
be provisioned either manually or, through a protocol like TRIP,
dynamically. If the use of ServiceCodes is desired, then a
ServiceCode corresponding to each such route must be supplied.
In the manual case, an ASP will presumably provide the ITSP with
information about available services which ITSP operations personnel
will use to configure feature proxies appropriately, including
ServiceCodes. As networks grow large and diverse, this business
practice may result in an undue amount of overhead when new services
are created. Therefore, in large networks dynamic registration of
services with ServiceCodes is recommended.
Following the example given above, the AppServer (in an ASP network)
propagates three routes associated with different ServiceCodes to the
location server (in ITSP network, which is the 'owner' of the end
user).
The location server is merely a front-end to provision the logical
feature proxy; it uses an internal policy matrix (see [TRIP-SC]) to
prioritize the routes among the total state of the feature server,
and subsequently provisions its PS with appropriate data for these
three routes.
Note that in this model, particular applications associated with an
ASP network can dynamically register and de-register at the ASP's
discretion - this ultimately is a very powerful tool for the ASP in
so far as it facilitates load balancing, maintenance, and similar
operational functions.
7. Conclusion
The interplay of ServiceCodes in SIP and TRIP ultimately allows an
extremely powerful model for service invocation. Consider that a
subscriber belonging to a particular ITSP could, through navigating a
web page or similar construct operated by an ASP, electronically
order a service that would automatically register itself with the
ITSP network via TRIP. This tools benefit all of the players in the
Internet telephony community (ITSP, ASP and subscriber) equally.
8. To Do
o Edge policies associated with ServiceCodes - ITSPs may wish to
implement particular policies at their network edges in order to
ensure that only permitted services are invoked in remote networks,
and moreover that remote networks behave in the expected fashion when
they are executing a service
o Add some diagrams
Peterson [Page 8]
Internet-Draft SIP ServiceCode Feb 2001
9. References
[2543] Handley, Schulzrinne, Schooler and Rosenberg, "Session
Initiation Protocol (SIP)", RFC2543, Internet Engineering Task Force,
March 1999
[TRIP] Rosenberg, Salama, and Squire, "Telephony Routing over IP
(TRIP)", Internet-Draft, Internet Engineering Task Force, Nov 2000
(work in progress)
[TRIP-L] Rosenberg and Salama, "Usage of TRIP in Gateways for
Exporting Phone Routes", Internet-Draft, Internet Engineering Task
Force, July 2000 (work in progress)
[TRIP-SC] Peterson, "The ServiceCode Attribute for TRIP", Internet-
Draft, Internet Engineering Task Force, Nov 2000 (work in progress)
[CGI] Lennox, Schulzrinne and Rosenberg, "Common Gateway Interface
for SIP", RFC3050, Internet Engineering Task Force, Jan 2001
[CPL] Lennox and Schulzrinne, "CPL: A Language for User Control of
Internet Telephony Services", Internet-Draft, Internet Engineering
Task Force, Nov 2000 (work in progress)
10. Author's Address
Jon Peterson
1025 Eldorado Blvd
Broomfield, CO
jon.peterson@level3.com
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Peterson [Page 9]
Internet-Draft SIP ServiceCode Feb 2001
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Peterson [Page 10]