Note: Descriptions are shown in the official language in which they were submitted.
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
SESSION INITIATION .PROTUCUL SLRVL.ET
APPLICATION PROGRAMMING INTERFACE
Technical Field
The present invention relates generally to telecommunications systems and more
particularly to a Session Initiation Protocol servlet Application Programming
Interface.
Bac6:aro~ d of the Inye~,tion
The Session Initiation Protocol (SIP) is an application layer protocol for
creatinb,
modifying and terminating communication sessions among computing systems or
other
suitable devices. SIP is defined formally in Handley et al, "SIP: Session
Initiation
Protocol," Internet Ensineering Task Forec, RFC 2543 (August 1999). Multiple
participants may participate in each session. Examples of sessions include
Int~met
multimedia conferences, Internet telephone calls and multimedia distribution
sessions.
The participants in a session may communicate via multieast, via a mesh of
unieast
relations or via a combination of multicast and unicast relations.
Conventional systems do not provide a convenient mechanism for developing
application programs that comply with SIP. A developer must custorrx develop
applications and ensure that the applications conform with the behavior
mandated by SIP
protocol. This difficulty makes application development cumbersome and
discourages the
proliferation of new applications that comply with SIP. Given the custom
nature of such
applications, maintenance of such applications may also be difficult.
Summary of the I yention
The present invention addresses the above-described limitations of
conventional
systems by facilitating the use of SIP servlets. The term "servlet; ' as used
in this context,
refers to a portion of computer codes that executes on a server to provide
desired
functionality. A servlet may be considered the server-side analoS to an
applet. In the
present invention, the servlets provide telephone services logic. In one
embodiment of the
present invention, an Application Progamming Interface (API) is defined for
Sll' servlets.
An API is a set of methods that an application may use to request and carry
out lower level
services. 'the SIP servlet API identifies interfaces and objects that a
servlet should support
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
to be a full fledged SIP servlet. The API identifies what functionality is
needed for an SIP
servlet.
In accordance with one-aspect of the present invention, an SIP scrvlet is
provided in
a data processing apparatus. The SIP servtet is run to implement telephone
service logic.
As part of the telephone services logic, the SIP scrvlct may examine,
manipulate or redirect
an SIP message, such as an SIP request or an SIP response.
In accordance with another aspect of the present invention, servlets are
provided in
a computing environment. A servlct manager is provided For managing the
servlets. A
commutucation that complies with SIP is received. The servlet manager
determines that a
selected one of the servlets is to process the communication, and the selected
servlet then
processes the communication.
In accordance with a further aspect of the present invention, an electronic
device
includes an interface for receiving an SIP message. The device also includes a
scrvlet for
handling the SIP message to implement telephone service logic.
l~ricf Dcscrintion of the Drawines
An illustrative embodiment of the present invention will be described below
relative to the follo'ving drawings.
FIGURE 1 depicts a block diagram of a first system that is suitable for
practicing
the illustrative embodiment of the present invention.
FIGURE 2 depicts a block diagram of a second system that is suitable for
practicing the illustrative embodiment.
FIGURE 3 is a flow chart illustrating the general steps performed to
implrnicnt
telephone services logic in the illustrative embodiment.
FIGURE 4 is a flow chart illustrating the steps that are performed to
implen~;ent call
screening in the illustrative embodiment_
2
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
FIGUR.Ir 5 is a flow chart illustrating the steps that are performed to
implement call
forwarding in the illustrative embodiment.
Detailed Description o;F the Invention
The illustrative embodiment sets forth an Application Programming Interface
(API)
for SIP senrlets. Developers may use this API to develop SIP sezvlets that
provide
customized behavior. The SiP servlets provide implementations of the methods
set forth
in the SIP servlet API. The SIP servlets enable users to dynamically extend
the
functionality of the server on the fly. The SIP servlets can inspect messages,
change
values of message headers, redirect messages and generally handle messages to
implement
telephone services logic. For example, the SIP serviets can be used to
implement call
forwarding, call screening and mobility services. Those skilled in the art
will appreciate
IS the SIP servlets may also be used to implement additional telephone
services logic.
The SIP servlets of the illustrative embodiment may be wzitten in a
programming
language, such as the Java programming language from Sun Microsystems, Inc.
Those
skilled in the art will appreciate that the servlets may also be written in
other appmpriatc
programming languages.
SIP (i.e., sessions entail the passing of "calls") request messages and
response
messages. These are the two exclusive types of messages used in SIP. The
response
messages respond to request messages. For example, when a first user wishes to
initiate a
session with a second user, the first user sends an INVITE request to the
second user. The
second user receives the INVITE request and responds with a response message
that
identifies whether the second user wishes to participate in the session.
Figure 1 depicts a block diagram of a first system l0 that is suitable for
practicing
the illustrative embodiment of the present invention. A user employs a user
device 12 that
is capable of communicating via SIP. The user device 12 may be a computer
system, a
cellular phone, an intelligent pager, a personal digital assistant (PDA) or
more generally,
any electronic device that is capable of participating in an SIP session. The
second user
CA 02395616 2002-06-07
WO 01/46822 PCT/C1S00/42695
;also employs a user device 14, which may be any type of component that is
capable of
participating in an S1P session (such as listed above).
In Figure 1, a SIP proxy service 16 is employed. The SIP proxy server 16 is an
intermediary program that acts both as a server and client for the purpose of
making
requests on behalf of other clients. The SIP proxy server 1G may run on a
dedicated server
computer system or may be run on a shared computer system. Requests are either
processed by the SIP proxy server 16 or passed on, a8er translation, to other
servers. The
SIP proxy server 16 interprets and, if necessary, rewrites a request before
forwarding the
request. A number of servlets 22 may be resident at the SIP proxy server 16 to
implement
telephone services logic. A servlet manager 20 is also resident at the SIP
proxy server 16.
The servlet manager 20 is responsible for receiving messages and determining
which of the
servlets 22 are to process the messages.
The system 10 of Figure 1 also includes a user agent server 18. The user agent
server 18 is a server application that contacts the user of user device 14
when an SIP
request is received. In addition, the user agent server 18 returns a response
on behalf of the
user of user device 14. A response accepts, rejects or redirects the request.
The user agent
server 18 may also have associated servlet manager 24 and servlets 26.
Figure 2 shows an alternative system 28 for practicing the illustrative
embodiment
of the present invention. This system 28 includes user devices 30 and 32.
System 28
differs front system 10 in that system 28 employs a redirect server 34 rather
than a proxy
server 16. The redirect server 34 is a server that accepts an SIP request,
maps the address
set forth in the SIP request to a new address and returns this address to a
client. Unlike the
SIP server 16, the redirect server 34 does not initiate its own SIP requests
and, in contrast
to a user agent server 18, the redirect server 34 does not accept calls. The
SIP redirect
server 34 has an associated servlet manager 36 and servlets 38.
Before discussing the details of the SIP servlet API provided by the
illustrative
embodiment, it is helpful to briefly review how the servlets may be employed.
Figure 3
provides a flow chart of an overview of the steps that may be performed using
the servlets.
In general, a servlet is provided on one of the servers (step 40 in Figure 3).
The servlet is
run alone or is conjunction with other scrvlets to implement telephone
services logic (step
4
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
42 in Figure 3). The telephone services logic may include any~of a number of
different
types of call processing approaches that are implemented in telephone systems.
Figure 4 is a flow chart illustrating the steps that are performed to realize
call
screening. Initially, a server receives an INVITE request (i.e., an
"invitation") for
initiating a session (step 44 in Figure 4). The INVITE request contains caller
information
identifying the caller that wishes to initiate the session (i.e., the "calf .
The caller
information is noted by the servlet (step 46 in Figure 4). Based upon the
caller
information, the servlct dctertnines whether to screen the call and how to
screen the call
(step 48 in Figure 4). The scrvlct may access a database or other information
source that
identifies the appropriate way to screen the call. The information in the
database, may, for
example, inform the servlet that the call is to be blocked, redirected to an
operator, directed
to a vo~cemail platform or placed in a queue.
Figure 5 is a flow chart illustrating the steps that are performed to
implement call
forwarding. Initially, a servlet receives an INVITE request (step SO in Figure
5). The
servlet accesses a database or another information source to obtain call
processing
information. In this instance, the call processing information identifies that
the call is to be
forwarded. As such, the scrvlet notes that the call has to be forwarded (step
52 in Figure
5). The IhMTL request is then forwarded to the appropriate destination (step
56 in Figure
5).
When a caller wishes to make an SIP call, the caller first locates a server
and sends
an SIP request to the server. The most common request is an INVITE request.
The SIP
request may be redirected or may trigger a train of new SIP requests by
proxies. Users can
register their locations with SIP servers. Users are located at hosts and arc
identified by
SIP URLs (Uniform Resource Locators). SIP URLs take the form of user@host,
where the
user part is a user name or telephone number and the host part is either a
domain name or a
nume~'ic network address.
As mentioned above, cacti SIP message is either a request or a response. These
messages use a generic message format as set forth in RFC 822. D. Crocker,
"Standard
For The Format Of ARfA Internet Tcxt Messages," Request For Comments 822,
Internet
1=ngincering Task Force, August 1982. The generic message format includes a
start line,
S
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
one or more header fields, and an empty line that indicates the end of the
header fields and
an optional message body.
The illustrative embodiment defines an SipServlet abstract base object class
that serves as
the central abstraction of the SipServlet API. This abstract base class
extends the
GenericService object class, wluch implements the servlet interface. The
SipServlet class
defines the default method for handling all SIP requests. This method
demultiplexes each
request and is responsible for invoking the appropriate method on the proper
instance of a
servlet. The SipServlet nbstrnot base class defines additional methods for
handling
particular types of SIP requests. These methods are automatically called by
the service
method (i.e., the servlet manager) for processing an SIP request. Objects of
the SipScrvlet
object class support two packages: javax.setvlet and servlet.sip. The
javax.scrvlet package
is a package that is defined by Sun Microsystems, Inc. of Palo Alto
California. A
"package" groups classes of objects by functionality. A "class" is a
collection of data and
methods that operate on the data. Each package groups a number of interfaces.
An
"interface" is akin to an abstract base class and provides a signature of
methods and
attributes that must be implemented by an object in order to support the
interface.
The servlct.sip pnclcnge is defined as follows.
interface Sip$ervletRequest
interface SipServletResponse
interface SipSession
interface SipBindingListener
class SipScrvlet
class URI
class SessionDescription
class MediaDescription
class SipUtils
As can be seen above, the servlct.sip package includes four interfaces: the
SipServletRequest interface, the SipServletResponse interface, the SipSession
interface
and the SipBindingListener interface. 'these Interfaces will be described in
more detail
6
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
below. In addition, the servlet.sip package specifies five object classes; the
SipServlet
object class, the URI object class, the SessionDescription object class, the
MediaDescription object class and the SipUtils object class. The SipServlet
object class
has been described above. The UIZI object class is an object that encapsulates
information
regarding SIP uniform resource identifiers. The SessionAcscription object
class holds
attributes and methods relating to particular sessions, and the
MediaDescription object
class holds attributes and methods relating to media that may be supported by
servers
during an SIP call. Lastly, the SipUtils object class is an object class that
includes a
number of utilities.
The SipServletRequest interface is more formally defined as follows.
public String getAuthType();
public String getCallld();
public long getDateHcader(String name);
public String getlleader(String name).;
public Lnumeration getHcadcrNamcsU;
public int getlntHeader (String name);
public String gctMethod();
public Stxing getPathlnfo();
public String getPathTranslated();
public String gctQucryString~;
public Stung getRemoteUser();
public String getRequestedSessionlDn;
public String getRequcstURI();
public String gctServletPath();
public SipSession getSession (boolcan create);
public SipSession gctScssion().
public boolcan isRequestedSessionIdYalid();
Tlte SipScrvlet Request interface defines an object to provide client request
information to a servlct. The getAuthType method acts authcntification type
information
from a request header. SIT' supports a number of different authentication
options. The
7
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
getCailld method obtains the calllD from the request header. The callID is a
unique
identifier of a call. The getDateHeadcr method obtains a date header field
from a request.
The getHeader method obtains a header that is specified as a parameter to the
method. The
sctF-IcaderNames method obtains names of the headers at a given request. The
getlntHeadcr method obtains an integer header. The gctMcthod method obtains a
method.
The getPathInfo method retrieves an SIP URI or other path information. The
getPathTranslatcd method obtains parameters relating to path information for a
path that
has been translated. The getQueryString method obtains a query string, and the
gctRemoteUser method gets information regarding a remote user (i.e., the
caller). The
getRequestedSessionlD method retrieves a session ID from a request. The
getRequcstURI
obtains a request URI, and the getServletPath method retrieves a path to a
servlet. The
getSession method either returns an existing session or returns a value
indicating that a
session has not yet been created and creates a session. The
isRequestedSessionIdValid
method returns a boolcan value indicating whether a session ID is valid or
not.
The SipServletResponsc interface extends the ServletResponse interface of the
java
x.set~let package. The SipServletResponse Interface is defined as follows.
public static final int TRYING;
SC
2p public static final
int SC RINGING;
public static final int CALL BECIN FORWARDED;
SC
public static final int CALL_QLTEUED;
SC
public static final int Ol~;
SC
public static final int MULTIPLE CHOICES;
SC
public static final MOVED fEI~:MANENTLY;
int SC
public static final int MOVED TEMPORARILY;
SC
public static anal int SEE OTHER;
SC
public static final int USE PROXY;
SC
public static final int ALTERNATIVE SERVICE;
SC
public static final int SC BAD REQUEST;
public static final int SC LTNAUTIIORIZED;
public static final int SC PAYMLNT_REQUIItED;
public static final int SC BAD FORBIDDEN;
8
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
public static final int SC NOT FOUND;
public static final int SC METHOD NOT ALLOWED;
public static final int SC PROXY AUTHENTICATION REQUIRED;
public static final int SC REQUEST TIMEOUT;
public static final int SC~CONFLICT;
public static final int SC GONE;
public static final int SC LENGTH REQUIRED;
public static final int SC REQUEST URI TOO LARGE;
public static final int SC REQUEST ENTITY TOO LONG;
public static final UNSUPPORTED MEDIA TYPE;
int SC
public static final int BAD EXTENSION;
SC
public static final int TEMPORA.R.LY UNABAILABLE;
SC
.public static final int CALL LEG DNE;
SC
public static final int LOOP T~ETFCTED;
SC
public static fznal TOO MANY_HOPS;
int SC
public static final int ADDRESS INCOMPLETE;
SC
public static final int AN~IGUOUS;
SC
public static final int BUSY HERE;
SC
public static final int SERVER INTERNAL~ERROR;
SC
public static final _NOT IMPLEMENTED;
int SC
public static final int BAD GATEWAY;
SC
public static firu~l int SERVICE UNAVAILABLE;
SC
public static final int GATEWAY TlluvIEOUT;
SC
public static final int VERSION NOT SUPPORTED;
SC
public static final int SC BUSY EVERYWHERE;
public static final int SC n>rCLINE;
public static final int SC DOES NOT EXIT ANYWHERE:
public static final int SC_NOT ACCF.PTAI3i,E;
public boolean containsHeader(String name);
public void sendError(int sc, String mesg) throws IOException;
public void sendError(int sc) throws IOException;
public void sendRedirect(String location) throws IOException;
puhlic void setDatcHcadcr(String name, long date);
9
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
public void setHeader(String name, String value);
public void setlntHcadcr(String name, int value);
public void setStatus (int se);
public void setStatus (int se, String sm);
As listed above, interface includes the definition of a number of constants
(i.e.,
static final variable). These constants correspond to the status codes defined
within the SIP
specification.
l0 The SipServletResponse interface also contains a number of methods. The
containsHeader method returns a Boolean value specifying whether the response
contains a
header or not. Multiple sendFrror methods are defined to generate error
alarms. The input
parameters may include just a status code or may include a status code and a
message in
String format. The sendRcdirect method causes an exception to and specifies
where a
response is to be redirected. The setDateHeader method establishes a value for
date
header, and the setHeader method establishes a value for a particular named
header. The
setlntHeader method sets a value for an integer header. The setStatus method
sets a status
code and may also include the additional parameter of a String that specifies
a status
message.
The SipSession interface contains the following methods.
public long getCreationTimeU;
public String oetId();
public long getLaStAccessedTime(J;
public int getMaxlnactivelnterval();
public Object getValue (String name);
public String [J getValueNames();
public void invalidate();
public Boolean isNew();
public void putValue(String name, Object value);
public void removeValue(String name);
public void setMaxlnactivelnterval(int interval);
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
The getCreationTime method returns the creation time for a session. The
creation
time information is retrieved from a session description object. The getId
method returns a
session ID. The gecLastAccessedTime method returns information regarding the
last time
a session was accessed. The getMaxInactivelnterval method returns the largest
period of
time for which the session has been inactive. The getValue method returns a
value for a
given named attribute. The getValuc names method returns the names of values
in a
session description object. The invalidate method invalidates the session, and
the isNew
method returns a Boolean value specifying whether the session has been newly
created or
not. The putValue method establishes a value for a given attribute. The
removeValue
method removes a value, and the setMaxlnactivelnterval method establishes a
value for the
maximum inactive interval attribute.
The SipSessionBindingListener interface is forn~lly defined as follows.
public void valueBound (SipSessionBindingEvent event);
public void valueUnbound(SipSessionBindingEvent event.
The SipSessionBindi~Listener interface extends the EventListener interface of
the
javax.secvlet package. This interface primarily causes an object to be
notified when it is
bound or unbound from a session.
As mentioned above, the servlet SIP package includes a number of objects. The
SIP servlet object is more formally defined as follows.
public SipServlet ();
protected void dolrrvite(SipServletRequest req, SipSetvletResponse resp)
throws SetvletException, IOException;
protected long getLastModified(SipServletRequest req);
protected void doAck(SipServletRequcst req, SipServletResponse resp)
throws ServletException, IOException;
protected void do'Fiye(SipServletRequest req, SirServIetRcsonse resp)
throws ServletException, IOException;
protected void doCancel(SipServletRequest req, SipServlctResponse resp)
11
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
throws ServletException, IOException;
protected void doRegister(SipServletRequest req, SipServIet.Response resp)
throws ServletException, IOException;
protected void doOptions(SipServletRequest req, SipServletResponse tesp)
$ throws ServletException, IOException;
protected void service(SipServletRequest req, SipServletResponse resp)
throws ServletException, IOException;
public void service(ServletRequest req, ServletResponse resp)
throws ServletException, IOException;
15
This object has a number of methods for handling respective types of requests.
For
example, the dolnvite method is used for handling INVITE requests. Similar
methods are
also provided for the ACK, BYE, CANCEL, REGISTER and OPTIONS request. The
service request provides a default service as has been described above.
The MediaDescription object is defined as follows:
public class MediaDescription
protected String name;
protected String address;
protected String title;
protected String connectionlnfo;
protected String bandwidthInfo;
protected String encriptionKey;
protected String duration;
protected String mediaAttributes;
public MediaDescription ();
It contains the name, address and title attributes for the media. In addition,
connection information and bandwidth information is contained therein. An
encriptionlCey
may be included in the media description object, and duration information
specifying the
12
CA 02395616 2002-06-07
WO 01/46822 PCT/US00/42695
duration of information contained in the media may also be included.
MediaAttributes
may be contained therein.
The SessionDescription object class is deFned as follows.
public class SessionAescription
protected String version;
protected String owner;
1p protected String name;
protected String sessioz~nfo
protected Strir~, URI;
,protected Suing email;
protected String phone;
protected Suing connectionlnfo;
protected String bandwidthlnfo;
protected Vector sessionAttrib;
protected String duration;
protected String schedule;
public SessionDescriptionQ;
The session description object holds description information regarding a
particular
session. The attributes include a version attribute, an owner attribute and a
name attribute.
The attributes may also conclude session information and a ITRT. Fmail
information and
phone information may also be stored as attributes. Connection information and
bandwidth information may be contained as attributes. Duration and schedule
information
may be contained as attributes and a vector of session attributes my also be
contained
therein.
While the present invention has been described with, reference to an
illustrative
embodiment thereof; those skilled in the art will appreciate that various
chances in form
and detail may be made without departing from the intended scope as defined in
the
attached claims.
13
