EP1240593A1 - Session initiation protocol servlet application programming interface - Google Patents

Session initiation protocol servlet application programming interface

Info

Publication number
EP1240593A1
EP1240593A1 EP00992885A EP00992885A EP1240593A1 EP 1240593 A1 EP1240593 A1 EP 1240593A1 EP 00992885 A EP00992885 A EP 00992885A EP 00992885 A EP00992885 A EP 00992885A EP 1240593 A1 EP1240593 A1 EP 1240593A1
Authority
EP
European Patent Office
Prior art keywords
sip
servlet
telephone service
service logic
servlets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00992885A
Other languages
German (de)
French (fr)
Inventor
Deo Ajay
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verizon Business Global LLC
Original Assignee
MCI Worldcom Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by MCI Worldcom Inc filed Critical MCI Worldcom Inc
Publication of EP1240593A1 publication Critical patent/EP1240593A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Definitions

  • the present invention relates generally to telecommunications systems and more particularly to a Session Initiation Protocol servlet Application Programming Interface.
  • Session Initiation Protocol is an application layer protocol for creating, 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 Engineering Task Force, RFC 2543 (March 1999). Multiple participants may participate in each session. Examples of sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution sessions.
  • the participants in a session may communicate via multicast, via a mesh of unicast relations or via a combination of multicast and unicast relations.
  • the present invention addresses the above-described limitations of conventional systems by facilitating ⁇ e use of SIP servlets.
  • servlet refers to a portion of computer codes that executes on a server to provide desired functionality.
  • a servlet may be considered the server-side analog to an applet.
  • the servlets provide telephone services logic.
  • an Application Programming Interface is defined for SIP servlets.
  • An API is a set of methods that an application may use to request and carry out lower level services.
  • the SIP servlel API identifies interfaces and objects that a servlet should support to be a full fledged SIP servlet.
  • the API identifies what functionality is needed for an SIP servlet.
  • an SIP servlet is provided in a data processing apparatus.
  • the SIP servlet is run to implement telephone service logic.
  • the SIP servlet may examine, manipulate or redirect an SIP message, such as an SIP request or an SIP response.
  • servlets are provided in a computing environment.
  • a servlet manager is provided for managing the servlets.
  • a communication that complies with SD? 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.
  • an electronic device includes an interface for receiving an SIP message.
  • the device also includes a servlet for handling the SIP message to implement telephone service logic.
  • 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 implement telephone services logic in the illustrative embodiment.
  • FIGURE 4 is a flow chart illustrating the steps that are performed to implement call screening in the illustrative embodiment.
  • FIGURE 5 is a flow chart illustrating the steps that are performed to implement call forwarding in the illustrative embodiment.
  • the illustrative embodiment sets forth an Application Programming Interface (API) for SIP servlets. Developers may use this API to develop SIP servlets 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.
  • the SIP servlets can be used to implement call forwarding, call screening and mobility services. Those skilled in the art will appreciate the SIP servlets may also be used to implement additional telephone services logic.
  • the SIP servlets of the illustrative embodiment may be written 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 appropriate programming languages.
  • SIP Session 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.
  • FIG. 1 depicts a block diagram of a first system 10 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.
  • PDA personal digital assistant
  • the second user also employs a user device 14, which may be any type of component that is capable of participating in an SIP session (such as listed above).
  • 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 16 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, after 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 SEP 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.
  • 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.
  • FIG. 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 from 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.
  • Figure 3 provides a flow chart of an overview of the steps that may be performed using the servlets.
  • a servlet is provided on one of the servers (step 40 in Figure 3).
  • the servlet is run alone or in conjunction with other servlets to implement telephone services logic (step 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.
  • FIG 4 is a flow chart illustrating the steps that are performed to realize call screening.
  • 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 "call").
  • the caller information is noted by the servlet (step 46 in Figure 4).
  • the servlet determines whether to screen the call and how to screen the call (step 48 in Figure 4).
  • the servlet 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 voiccmail platform or placed in a queue. •
  • FIG 5 is a flow chart illustrating the steps that are performed to implement call forwarding.
  • a servlet receives an INVITE request (step 50 in Figure 5).
  • the servlet accesses a database or another information source to obtain call processing information.
  • the call processing information identifies that the call is to be forwarded.
  • the servlet notes that the call has to be forwarded (step 52 in Figure 5).
  • the ENNITE request is then forwarded to the appropriate destination (step 56 in Figure 5).
  • SIP URLs Uniform Resource Locators
  • each 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 ART A Internet Text Messages," Request For Comments 822, Internet Engineering Task Force, August 1 82.
  • the generic message format includes a start line, 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
  • 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 abstract 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 SipServlet object class support two packages: javax.servlet 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 servlet.sip package is defined as follows.
  • the servlet.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 below.
  • the servlet.sip package specifies five object classes: the SipServlet object class, the URI object class, the ScssionDescription object class, the MediaDescription object class and the SipUtils object class.
  • the SipServlet object class has been described above.
  • the URI object class is an object that encapsulates information regarding SIP uniform resource identifiers.
  • the ScssionDescription object class holds attributes and methods relating to particular sessions
  • the MediaDescription object class holds attributes and methods relating to media that may be supported by servers during an SIP call.
  • the SipUtils object cla ⁇ s is an object class that includes a number of utilities.
  • the SipServletRequest interface is more formally defined as follows.
  • the SipServlet Request interface defines an object to provide client request information to a servlet.
  • the getAuthType method gets authcntification type information from a request header. SIP supports a number of different authentication options.
  • the getCallld method obtains the calUD from the request header.
  • the calllD 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 gctHcaderNames method obtains names of the headers at a given request.
  • the getlntHeadcT method obtains an integer header.
  • the gctMclhod method obtains a method.
  • the getPathlnfo method retrieves an SIP URI or other path information.
  • the getPathTranslatcd method obtains parameters relating to path information for a path mat has been translated.
  • the getQueryString method obtains a query string, and the getRemoteUser method gets information regarding a remote user (i.e., the caller).
  • the getRequestedSessionlD method retrieves a session ID from a request.
  • the getRequestURI obtains a request URI, and the getServletPath method retrieves a path to a servlet.
  • the getSession method cither returns an existing session or returns a value indicating that a session has not yet been created and creates a session.
  • the isRequestedSessionldValid method returns a boolean value indicating whether ⁇ session ID is valid or not.
  • the SipServletResponse interface extends the ServletResponse interface of the Java ⁇ .servlet package.
  • the SipServletResponse Interface is defined as follows.
  • public boolean containsFfeader(String name); public void sendError(int sc, String mesg) throws lOException; public void sendError(int sc) throws lOException; public void sendRedircct(String location) throws lOException; public void setDatcHcadcr(String name, long date); public void setHeader(String name, String value); public void setIntHcadcr(String name, int value); public void setStatus (int sc); public void setStatus (int sc. String s );
  • 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.
  • 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 sendF.rrnr 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 m ⁇ diod 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.
  • the getCreationTime method returns the creation time for a session.
  • the creation time information is retrieved from a session description object.
  • the gelid method returns a session ID.
  • the getLastAccessedTime 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 getValue 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 setMaxInactivelnterval method establishes a value for the maximum inactive interval attribute.
  • the SipSessionBindingListener interface is formally defined as follows.
  • the SipSessionBindingListener interface extends the EventListener interface of the javax.servlet package. This interface primarily causes an object to be notified when it is bound or unbound from a session.
  • the servlet SIP package includes a number of objects.
  • the SIP servlet object is more formally defined as follows.
  • SipServlet public SipServlet (); protected void doInvite(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected long getLastModified(SipServletRequest req); protected void doAck(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void doBye(SipServletReques req, SipServletRcsonse resp) throws ServletException, lOException; protected void doCancel(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void doRegister(SipS ⁇ rvletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void doOptions(SipServlet
  • This object has a number of methods for handling respective types of requests.
  • the dolnvite method is used for handling INVTTE 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:
  • It contains the name, address and title attributes for the media.
  • connection information and bandwidth information is contained therein.
  • An encriptionKey may be included in the media description object, and duration information specifying the duration of information contained in the media may also be included.
  • MediaAttributes may be contained therein.
  • the SessionDescrip ⁇ on object class is defined as follows.
  • 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 URT.
  • Email 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Communication Control (AREA)

Abstract

An Application Program Interface (API) is provided for Session Initiation Protocol (SIP) (16) servlets (22, 26). This API sets forth critical functionality that is required for servlets in order to handle messages that comply with SIP. The servlets may implement telephone services logic, such as call forwarding, call screening and mobility services.

Description

SESSION INITIATION PROTOCOL SERVLET 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.
Background of the Invention
The Session Initiation Protocol (SIP) is an application layer protocol for creating, 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 Engineering Task Force, RFC 2543 (August 1999). Multiple participants may participate in each session. Examples of sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution sessions. The participants in a session may communicate via multicast, via a mesh of unicast 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 custom 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 ay also be difficult.
Summary of the Invention
The present invention addresses the above-described limitations of conventional systems by facilitating ύ\e 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 analog to an applet. In the present invention, the servlets provide telephone services logic. In one embodiment of the present invention, an Application Programming Interface (API) is defined for SIP servlets. An API is a set of methods that an application may use to request and carry out lower level services. The SIP servlel API identifies interfaces and objects that a servlet should support 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 servlet is provided in a data processing apparatus. The SIP servlet is run to implement telephone service logic. As part of the telephone services logic, the SIP servlet 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 servlet manager is provided for managing the servlets. A communication that complies with SD? 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 servlet for handling the SIP message to implement telephone service logic.
Brief Description of the Drawings
An illustrative embodiment of the present invention will be described below relative to the following 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 implement telephone services logic in the illustrative embodiment.
FIGURE 4 is a flow chart illustrating the steps that are performed to implement call screening in the illustrative embodiment. FIGURE 5 is a flow chart illustrating the steps that are performed to implement call forwarding in the illustrative embodiment.
Detailed Description of the Invention
The illustrative embodiment sets forth an Application Programming Interface (API) for SIP servlets. Developers may use this API to develop SIP servlets 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 servlets can be used to implement call forwarding, call screening and mobility services. Those skilled in the art will appreciate the SIP servlets may also be used to implement additional telephone services logic.
The SIP servlets of the illustrative embodiment may be written 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 appropriate 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 10 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 also employs a user device 14, which may be any type of component that is capable of participating in an SIP session (such as listed above).
In Figure I, 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 16 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, after 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 SEP 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 from 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 in conjunction with other servlets to implement telephone services logic (step 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 "call"). The caller information is noted by the servlet (step 46 in Figure 4). Based upon the caller information, the servlet determines whether to screen the call and how to screen the call (step 48 in Figure 4). The servlet 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 voiccmail 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 50 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 servlet notes that the call has to be forwarded (step 52 in Figure 5). The ENNITE 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 ENNITE 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 cither a domain name or a numeric network address.
As mentioned above, each 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 ART A Internet Text Messages," Request For Comments 822, Internet Engineering Task Force, August 1 82. The generic message format includes a start line, 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, which 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 abstract 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 SipServlet object class support two packages: javax.servlet 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 servlet.sip package is defined as follows.
interface SipServletRequest interface SipServletResponse interface SipSession interface SipBindingListener
class SipServlet class URI class SessionDescription class MediaDescription class SipUtils
As can be seen above, the servlet.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 below. In addition, the servlet.sip package specifies five object classes: the SipServlet object class, the URI object class, the ScssionDescription object class, the MediaDescription object class and the SipUtils object class. The SipServlet object class has been described above. The URI object class is an object that encapsulates information regarding SIP uniform resource identifiers. The ScssionDescription 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 claβs is an object class that includes a number of utilities.
The SipServletRequest interface is more formally defined as follows.
public String getAuthType(); public String getCallldO; public long getDatcHcadcr(String name); public String getHeader(String name); public Enumeration getHcadcrNamcsϋ; public int getlntHeader (String name); public String gctMcthod(); public String getPathlnfoO; public String getPathTranslated(); public String gctQucryStringO; public String getRemoteUser(); public String getRequestedSessionlDO; public String getRequcstURI(); public String gctServletPath(); public SipSession getSession (boolean create); public SipSession gctScssion(). public boolean isRcquestedSessionIdValid();
The SipServlet Request interface defines an object to provide client request information to a servlet. The getAuthType method gets authcntification type information from a request header. SIP supports a number of different authentication options. The getCallld method obtains the calUD from the request header. The calllD 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 gctHcaderNames method obtains names of the headers at a given request. The getlntHeadcT method obtains an integer header. The gctMclhod method obtains a method. The getPathlnfo method retrieves an SIP URI or other path information. The getPathTranslatcd method obtains parameters relating to path information for a path mat has been translated. The getQueryString method obtains a query string, and the getRemoteUser method gets information regarding a remote user (i.e., the caller). The getRequestedSessionlD method retrieves a session ID from a request. The getRequestURI obtains a request URI, and the getServletPath method retrieves a path to a servlet. The getSession method cither returns an existing session or returns a value indicating that a session has not yet been created and creates a session. The isRequestedSessionldValid method returns a boolean value indicating whether α session ID is valid or not.
The SipServletResponse interface extends the ServletResponse interface of the Java χ.servlet package. The SipServletResponse Interface is defined as follows.
public static final nt SC_TRYING; public static final nt SC_RINGING; public static final nt SC_CALL_BEGIN_FORWARDED; public static final nt SC_CALL_QUEUED; public static final nt SC_OK; public static final nt SC_MULTIPLE_CHOICES; public static final nt SC_MOVED_PERMANENTLY; public static final nt SC_MOVED_TEMPORARILY; public static final nt SC_SEE_OTHER; public static final int SC_USE_PROXY; public static final int SC_ALTERNATIVE_SERVICE;
public static final int SC_BAD_REQUEST; public static final int SCJ NAUTIIORIZED; public static final int SC_P YMΗNT_REQU1RED; public static final int SC_BAD_FORBIDDEN; public static final nt SC_NOT_FOUND; public static final nt SC_METHOD_NOT_ALLOWED; public static final nt SC_PROXY_AUTHENTICATION_REQUIRED; public static final nt SC_R£QUEST_TIMEOUT; public static final nt SC ZONFLICT; public static final nt SC_GONE; public static final nt SC_LENGTH_REQUIRED; public static final nt SC_REQUEST_URI_TOO_LARGE; public static final nt SC_REQUEST_ENTπΥ_TOO_LONG; public static final nt SC_UNSUPPORTED_MEDIA_TYPE; public static final nt SC JBADJΞXTENSION; public static final nt SC TEMPORARLY JNABAILABLE; .public static final nt SC_CALL_LEG_DNE; public static filial int SC_LOOP_DETECTED; public static final nt SC_TOO_MANY_HOPS; public static final nt SC_ADDRESS_INCOMPLETE; public static final nt SC_AMBIGUOUS; public static final nt SC_BUSY_HERE; public static final nt SC_SERVERjπsrTERNALJERROR; public static final nt SC_NOT_IMPLEMENTED; public static final nt SC_BAD_GATEWAY; public static final nt SC_SERVICE_UNAVAILABLE; public static final nt SC_GATEWAY_TIMEOUT; public static final int SC_VERSION_NOT_SUPPORTED; public static final nt SC_BUSY_EVERYWHERE; public static final int SC_DECLINE; public static final int SC_DOES_NOT_EXIT_ANYWHERE; public static final int SC_NOT_ACCEPTABΪ.E;
public boolean containsFfeader(String name); public void sendError(int sc, String mesg) throws lOException; public void sendError(int sc) throws lOException; public void sendRedircct(String location) throws lOException; public void setDatcHcadcr(String name, long date); public void setHeader(String name, String value); public void setIntHcadcr(String name, int value); public void setStatus (int sc); public void setStatus (int sc. String s );
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.
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 sendF.rrnr 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 mεdiod 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 getCreationTime(); public String getld(); public long getLastAccesscdTimcO; public int getMaxInactiveInterval(); public Object getValue (String name); public String [] getValueNa esQ; public void invalidatc(); public boolean isNewQ; public void putValue(String name, Object value); public void removeValue(String name); public void setMax!nactivelnterval(int interval); The getCreationTime method returns the creation time for a session. The creation time information is retrieved from a session description object. The gelid method returns a session ID. The getLastAccessedTime 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 getValue 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 setMaxInactivelnterval method establishes a value for the maximum inactive interval attribute.
The SipSessionBindingListener interface is formally defined as follows.
public void valueBound (SipSessionBindingEvent event); public void va!ueUnbound(SipSessionBindingEvent event.
The SipSessionBindingListener interface extends the EventListener interface of the javax.servlet 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 doInvite(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected long getLastModified(SipServletRequest req); protected void doAck(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void doBye(SipServletReques req, SipServletRcsonse resp) throws ServletException, lOException; protected void doCancel(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void doRegister(SipSεrvletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void doOptions(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; protected void service(SipServletRequest req, SipServletResponse resp) throws ServletException, lOException; public void service(ServletRequest req, ServletResponse resp) throws ServletException, lOException;
This object has a number of methods for handling respective types of requests. For example, the dolnvite method is used for handling INVTTE 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 bandwidthlnfo; 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 encriptionKey may be included in the media description object, and duration information specifying the duration of information contained in the media may also be included. MediaAttributes may be contained therein.
The SessionDescripύon object class is defined as follows.
public class SessionDescription
protected String version; protected String owner; protected String name; protected String sessionlnfo protected String URI;
.protected String email; protected String phone; protected String connectionlnfo; protected String bandwidthlnfo; protected Vector sessionAttrib; protected String duration; protected String schedule;
public SessionDescriptionO;
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 URT. Email 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 changes in form and detail may be made without departing from the intended scope as defined in the attached claims.

Claims

Claims
1. In a data processing apparatus, a method, comprising the steps of: providing a Session Initiation Protocol (STP) servlet; and running the SIP servlet to implement telephone service logic.
2. The method of claim 1 , wherein the data processing apparatus is an SIP server.
3. The method of claim 1, wherein, as part of the telephone service logic, the SIP servlet examines an SIP message.
4. The method of claim 1, wherein, as part of the telephone service logic, the SIP scrvleLprocesses an SIP invitation.
5. The method of claim I , wherein, as part of the telephone service logic, the STP servlet processes SIP requests.
6. The method of claim I, wherein, as part of the telephone service logic, the SEP servlet processes SEP responses.
7. The method of claim 1, wherein the data processing apparatus is part of a network that supports the Internet Protocol (IP).
8. The method of claim 1 , wherein the data processing apparatus is part of the Internet.
9. The method of claim 1, wherein the telephone service logic is call forwarding logic.
10. The method of claim 1, wherein the telephone service logic is call screening logic.
1 1. In a computing environment, a method, comprising the steps of: providing servlets; providing a servlet manager for managing the servlets receiving a communication mat complies with the Session Initiation Protocol (SIP); with the servlet manager, determining that a selected one of the servlets is to process the communication; and processing the communication with the selected servlet.
12. The method of claim 11, wherein the step of processing the communication comprises forwarding the communication to a destination.
13. The method of clam 11 , wherein the step of processing the communication comprises modifying die communication.
14. .The metliod of claim 11, wherein the step of processing the communication comprises handling SIP requests.
15. The method of claim 11, wherein the step of processing the communication comprises handling SEP responses.
16. A medium holding instructions for execution by a data processing apparatus to perform a method, comprising the steps of: providing a Session Initiation Protocol (SIP) servlet; and running the SEP servlet to implement telephone service logic.
17. The medium of claim 16, wherein, as part of the telephone service logic, the SIP servlet examines an SIP message.
18. The medium of claim 16, wherein, as part of the telephone service logic, the SEP servlet processes SEP requests.
19. The medium of claim 16, wherein the telephone service logic is call forwarding logic.
20. The medium of claim 16, wherein the telephone service logic is call screening logic.
1. An electronic device, comprising: an interface for receiving a Session Initiation Protocol (SIP) message; and a servlet for handing the SIP message to implement telephone service logic.
22. The device of claim 21, wherein the device is a computer system.
23. The device of claim 21, further comprising additional servlets for providing additional telephone service logic.
24. The device of claim 21 , wherein the device receives additional SEP messages and wherein the device further comprises additional servlets for processing the additional SEP messages.
25. The device of claim 24, wherein the device further comprises a servlet manager for determining, for each of the additional SIP messages, which of the servlets is to process the message.
EP00992885A 1999-12-08 2000-12-08 Session initiation protocol servlet application programming interface Withdrawn EP1240593A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US457428 1989-12-27
US45742899A 1999-12-08 1999-12-08
PCT/US2000/042695 WO2001046822A1 (en) 1999-12-08 2000-12-08 Session initiation protocol servlet application programming interface

Publications (1)

Publication Number Publication Date
EP1240593A1 true EP1240593A1 (en) 2002-09-18

Family

ID=23816689

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00992885A Withdrawn EP1240593A1 (en) 1999-12-08 2000-12-08 Session initiation protocol servlet application programming interface

Country Status (8)

Country Link
EP (1) EP1240593A1 (en)
JP (1) JP2003518352A (en)
CN (1) CN1433547A (en)
AU (1) AU4714901A (en)
BR (1) BR0016237A (en)
CA (1) CA2395616A1 (en)
MX (1) MXPA02005701A (en)
WO (1) WO2001046822A1 (en)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8145208B2 (en) 2006-10-31 2012-03-27 Gogo Llc Air-to-ground cellular communication network terrestrial base station having multi-dimensional sectors with alternating radio frequency polarizations
US7113780B2 (en) 1992-03-06 2006-09-26 Aircell, Inc. System for integrating an airborne wireless cellular network with terrestrial wireless cellular networks and the public switched telephone network
US8914022B2 (en) 1992-03-06 2014-12-16 Gogo Llc System for providing high speed communications service in an airborne wireless cellular network
US8452276B2 (en) 2000-10-11 2013-05-28 Gogo Llc Differentiated services code point mirroring for wireless communications
EP1368975A1 (en) 2001-03-09 2003-12-10 Ayman L.L.C. Universal point of contact identifier system and method
US7251254B2 (en) 2003-09-03 2007-07-31 At&T Corp. Telecommunication network system and method in communication services using session initiation protocol
WO2005055549A1 (en) * 2003-12-01 2005-06-16 France Telecom System for providing services in response to a communications session message
US20060047840A1 (en) * 2004-08-31 2006-03-02 Peter Postmus Method and session initiation protocol (SIP) server for the exchange of end-point capabilities
US7532617B2 (en) 2005-02-24 2009-05-12 International Business Machines Corporation Method and apparatus for session initiation protocol application design, development, execution and integration
JP4515358B2 (en) * 2005-08-30 2010-07-28 株式会社エヌ・ティ・ティ・ドコモ Communication control device and communication control method

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5944781A (en) * 1996-05-30 1999-08-31 Sun Microsystems, Inc. Persistent executable object system and method
US5928323A (en) * 1996-05-30 1999-07-27 Sun Microsystems, Inc. Apparatus and method for dynamically generating information with server-side software objects

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0146822A1 *

Also Published As

Publication number Publication date
MXPA02005701A (en) 2002-12-13
CN1433547A (en) 2003-07-30
BR0016237A (en) 2002-08-27
CA2395616A1 (en) 2001-06-28
AU4714901A (en) 2001-07-03
JP2003518352A (en) 2003-06-03
WO2001046822A1 (en) 2001-06-28

Similar Documents

Publication Publication Date Title
US7849190B2 (en) Internet protocol based service architecture
JP4199670B2 (en) Communication application server for converged communication services
US8379544B2 (en) Communications
EP2561439B1 (en) Unified framework and method for call control and media control
JP2002544608A (en) A distributed system for establishing intelligent sessions between anonymous users over various networks
WO2005070115A2 (en) Proprietary protocol for voip based features
CN101322385A (en) Load balancing and failover of distributed media resources in a media server
WO2008118658A1 (en) Method and apparatus for management of an application ensemble
MXPA02005700A (en) Telephone fraud detection and prevention.
WO2001046822A1 (en) Session initiation protocol servlet application programming interface
JP2009518909A (en) In a complex service delivery system, voice access for a session starts from a visual access channel for that session
TWI459213B (en) Pulling information from information sources via refer requests
CN1874610B (en) Method and system for debugging telephone call
US7953799B2 (en) Service control device and method
EP1528713A2 (en) Remote monitoring of graphical telecommunications terminals
EP1247387B1 (en) Improved session initiation protocol (sip)
Kolberg et al. Managing feature interactions between distributed SIP call control services
US9049310B2 (en) Data communication
JP5453525B2 (en) Graphical user interface for a terminal having a visual display of call progress
US20090254665A1 (en) Trigger-Based Session Completion Using External Parties
Chentouf et al. Experimenting with feature interaction management in SIP environment
Chentouf et al. Mapping sip onto a feature interaction management language
WO2001035594A2 (en) Telecommunications control protocol processing
Cortes et al. Narnia: A virtual machine for multimedia communication services
O’Doherty et al. JAIN SIP Tutorial

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020708

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050701