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

Abstract

(57) [Summary] In the present invention, a servlet provides telephone service logic. In one embodiment of the present invention, an application program interface (API) is defined for a SIP servlet. An API is a set of methods used by applications to request and perform lower level services. The SIP Servlet API identifies the interfaces and objects that the servlet must support to be a fully developed SIP servlet. The API identifies the required functionality for a SIP servlet.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to telecommunications systems, and more particularly to session initiation protocol servlet application programming interfaces.

[0002]

[Prior Art and Problems to be Solved by the Invention]

Session Initiation Protocol (SIP) is an application layer protocol for creating, modifying and terminating communication sessions between computing systems or other suitable devices. SIP is Handley et al, “SIP: Se
ssion Initiation Protocol, ”Internet Engineering Task Force, RFC 2543 (A
ugust 1999). Multiple participants may participate in each session. Examples of sessions include internet multimedia conferences, internet telephone calls and multimedia distribution sessions. Participants in the session may communicate via multicast, via a mesh in a unicast relationship, or via a combination of multicast and unicast relationships.

Conventional systems do not provide a convenient mechanism for developing SIP compliant application programs. The developer must make the application custom-built and ensure that the application "follows the behavior dictated by the SIP protocol." This reluctantly complicates application development and hinders the growth of new SIP-compliant applications. Given the attention nature of such applications, maintenance of such applications may also be difficult.

[0004]

The present invention addresses the above limitations of conventional systems by facilitating the use of SIP Servlets. The term "servlet", as used in this context, refers to a piece of computer code that executes on a server to provide the desired functionality. Servlets may be considered server side similar to applets. In the present invention, the servlet provides the telephone service logic.
In one embodiment of the invention, an application program interface (API
) Is defined for the SIP Servlet. APIs are a set of methods that applications use to request and perform lower level services.
The SIP Servlet API identifies the interfaces and objects that a servlet must support in order to be a fully developed SIP Servlet. API
Identifies the functionality required for the SIP Servlet.

According to one feature of the invention, the SIP Servlet is provided in a data processing device. The SIP Servlet is executed to implement the telephone service logic. As part of the telephone service logic, SIP Servlets
SIP messages such as SIP responses may be inspected or treated or redirected.

According to another feature of the invention, a servlet is provided in a computing environment. A servlet manager is provided to manage the servlets. Communication according to SIP is received. The servlet manager determines that "the selected one of the servlets should handle the communication", and the selected servlet handles the communication.

According to a further feature of the invention, the electronic device comprises an interface for receiving SIP messages. The device also comprises a servlet for handling SIP messages to implement the telephony service logic.

[0008]

DETAILED DESCRIPTION OF THE INVENTION   Illustrative embodiments of the invention are described below with reference to the accompanying drawings.

The illustrative embodiment defines an application programming interface (API) for SIP Servlets. Developers may use this API to develop SIP Servlets that provide customized behavior.
The SIP Servlet provides the implementation of the methods previously defined in the SIP Servlet API. SIP Servlets allow users to quickly and dynamically extend the functionality of a server. The SIP Servlet can inspect the message, change the value of the message header, redirect the message, and perform general processing on the message to implement the telephone service logic. For example, SIP Servlets can be used to fulfill call transmission, call screening, and mobile services. Those skilled in the art will appreciate that "SIP Servlet may also be used to implement additional telephony service logic."

The SIP servlet of the illustrative embodiment may be written in a programming language such as Sun Microsystems, Inc®'s Java® programming language. Those skilled in the art will understand that "servlets may also be written in other suitable programming languages".

SIP (ie, a session involves passing a “call”) requests a message and a response message. These are two exclusive types of messages used in SIP. The response message responds to the request message. For example, when the first user wants to initiate a session with the 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 identifying "whether the second user wants to join the session".

FIG. 1 illustrates a first system 10 suitable for carrying out an illustrative embodiment of the invention.
Draw a block diagram of. User device that allows users to communicate via SIP 1
Use 2. The user device 12 may be a computer system or a cellular phone or an intelligent pager or a personal digital assistant (PDA) or (
(More generally) any electronic device capable of participating in a SIP session.
The second user also uses the user device 14. User device 14
May be any type of component (as listed above) that can participate in a SIP session.

In FIG. 1, the SIP proxy server 16 is used. SIP proxy server 16 is an intermediate program that acts as a server and client to make requests on behalf of other clients. SIP proxy server 16 may run on a dedicated server computer system or may run on a shared computer system. The request is processed by the SIP proxy server 16, or
Or it is sent (after conversion) to another server. The SIP server 16 interprets the request and rewrites (if necessary) before sending the request. Multiple servlets 22 may reside on the SIP proxy server 16 to implement the telephone service logic. The serverlet manager 20 also resides in the SIP proxy server 16. The servlet manager 20 is responsible for receiving the message and determining "which servlet 22 should process the message."

The system 10 of FIG. 1 also includes a user agent server 18. User agent server 18 is a server application that contacts the user of user device 14 when a SIP request is received. In addition, the user agent server 18 returns a response on behalf of the user of the user device 14. The response accepts, rejects, or redirects the request. User agent server 18 may also have an associated servlet manager 24 and servlet 26.

FIG. 2 illustrates another system 28 for implementing the illustrative embodiment of the present invention. The system 28 comprises user devices 30 and 32. System 28 differs from system 10 in that "system 28 uses redirect server 34, rather than proxy server 16." The redirect server 34 is a server, which accepts the SIP request and maps the address previously defined in the SIP request to a new address, and
Return this address to the client. Unlike SIP server 16, redirect server 34 does not initiate its own SIP request, and, in contrast to user agent server 18, redirect server 34 does not accept calls. SIP redirect server 34 has an associated servlet manager 36 and servlet 38.

Before discussing the details of the SIP Servlet API provided by the illustrative embodiment, it is helpful to briefly review how the servlet is used. FIG. 3 provides a flow chart outlining the steps performed using a servlet. Generally, the servlet is provided at one of the servers (step 40 in Figure 3). The servlet is executed alone or with other servlets to implement the telephone service logic (step 42 of FIG. 3). Telephone service logic may comprise any of a number of different types of call processing approaches implemented in telephone systems.

FIG. 4 is a flow chart illustrating the steps performed to implement call screening. First, the server receives an INVITE request (ie, "invitation") to initiate a session (step 44 in Figure 4). The INVITE request includes cellular information that identifies the calling party who wants to initiate a session (or "call"). Caller information is written down by the servlet (
Step 46 of FIG. 4). Based on the caller information, the servlet determines "whether to screen the call" and "how to screen the call" (step 48 in FIG. 4). The servlet may access a database or other source of information that identifies the appropriate method for screening the call.
The information in the database may be, for example, "call should be blocked" or "call should be redirected to operator" or "call should be sent to voicemail platform". Alternatively, it may inform the server that the call should be placed in a queue.

FIG. 5 is a flow chart illustrating the steps performed to complete a call transmission. First, the servlet receives an INVITE request (step 50 in Figure 5). The servlet accesses a database or other source of information to obtain call processing information. In this case, the call processing information identifies that "the call should be sent". In such a case, the servlet notes that "the call must be sent" (step 52 in Figure 5). And in
The VITE request is sent to the appropriate destination (step 56 in Figure 5).

When a caller wants to make a SIP call, the caller first locates the server and sends a SIP request to the server. The most common request is the INVITE request. The SIP request may be redirected or may trigger a string of new SIP requests by the proxy. The user can register his location in the SIP server. Users are located on hosts and are identified by SIP URLs (Uniform Resource Locators). SIP
The URL takes the form of user @ host. Here, the user part is a user name or a telephone number, and the host part is a domain name or a numerical network address.

As mentioned above, each SIP message is either a request or a response. These messages use a common message format. The format is RF
C 822. D. Crocker “Standard For The Format Of ARPA Internet Text Messages
, ”Request For Comments 822, Internet Engineering Task Force, August 198
It is specified in 2. The general message format comprises a start line, one or more header fields, and an empty line. The empty line indicates the end of the header field and the optional message body.

The illustrative embodiment is a SipSer that serves as the central extractor for the SipServlet API.
vlet abstract base object class
Is defined. This abstract base class extends the GenericService object class. GenericService object class implements the servlet interface. The SipServlet class defines a default method for handling all SIP requests. This method is responsible for demultiplexing each request and invoking the appropriate method at the servlet's appropriate time. The SipServlet abstract base class defines additional methods for handling SIP requests of a given type. These methods are automatically invoked by the service method (ie, servlet manager) for handling SIP requests. Objects of the SipServlet object class support two packages (javax.servlet or servlet.sip). javax.servle
The t package is a package defined by Sun Microsystems, Inc. of Palo Alto California. A "package" groups object classes by function. A "class" is a collection of data and methods that operate on that data. Each package groups a number of interfaces. An "interface" is similar to an abstract base class and provides a signature of methods and attributes that must be implemented by an object to support the interface.

[0022]   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 comprises four interfaces: SipServletRequest interface, SipServletResponse interface, SipSession interface and SipBindingListener interface. These interfaces are described in more detail below.
In addition, the servlet.sip package specifies five object classes (SipServlet object class, URI object class, SessionDescription object class, MediaDescription object class, and SipUtils object class). The SipServlet object class was previously described. The URI object class is an object that encloses information about SIP uniform resource identifiers. The SessionDescription object class holds attributes and methods for a given session, and the MediaDescription object class holds attributes and methods for media supported by the server during a SIP call. Finally, the SipUtils object class is an object class that contains a number of utilities.

More formally, the SipServletRequest interface is defined as follows. public String getAuthType (); public String getCallId (); public long getDateHeader (String name); public String getHeader (String name); public Enumeration getHeaderNames (); public int getIntHeader (String name); public String getMethod (); public String getPathInfo (); public String getPathTranslated (); public String getQueryString (); public String getRemoteUser (); public String getRequestedSessionID (); public String getRequestURI (); public String getServletPath (); public SipSession getSession (boolean create); public SipSession getSession (); public boolean isRequestedSessionIdValid ();

The SipServletRequest interface defines an object for providing client request information to a servlet. The getAuthType method acquires ratification type information from the request header. SIP supports a number of different ratification options. The getCallId method acquires the callID from the request header. callID is the unique identifier of the call. The getDateHeader method fetches the date header field from the request. The getHeader method gets the header specified as a parameter to the method. The getHeaderNames method gets the names of the headers in a given request. The getIntHeader method gets an integer header. The getMethod method gets the method. getPathInfo is a SIP URL
Or search for other route information. getPathTranslated obtains a parameter regarding route information for the moved route. The getQueryString method gets the query string and getRemoteUser gets the information about the remote user (ie, the caller). The getRequestedSessionID method retrieves the session ID from the request. getRequestURI gets the request URI, and getServl
The etPath method finds the route to the servlet. The getSession method either returns an existing session, or returns a value indicating that the session has not yet been created and creates the session. The isRequestedSessionIdValid method returns a Boolean value indicating "whether the session ID is valid".

The SipServletResponse interface is the Servlet of the javax.servlet package.
Extend the Response interface. SipServletResponse interface is defined as follows. public static final int SC_TRYING; public static final int SC_RINGING; public static final int SC_CALL_BEGIN_FORWARDED; public static final int SC_CALL_QUEUED; public static final int SC_OK; public static final int SC_MULTIPLE_CHOICES; public static final int SC_MOVED_PERMANENTLY_ARI staticMOVED_PERMANENTLY; public static final int final int 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 SC_UNAUTHORIZED; public static final int SC_PAYMENT_REQUIRED; public static final int SC_BAD_FORBIDDER_ publicNOT final 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_public_R EQUEST_ENTITY_TOO_LONG; public static final int SC_UNSUPPORTED_MEDIA_TYPE; public static final int SC_BAD_EXTENSION; public static final int SC_TEMPORARLY_UNABAILABLE; public static final int SC_CALL_LEG_static_public final SCOP static final int SC_BUSY_HERE; public static final int SC_SERVER_INTERNAL_ERROR; public static final int SC_NOT_IMPLEMENTED; public static final int SC_BAD_GATEWAY; public static final int SC_SERVICE_UNAVAILABLE; public static final int SC_GATEWAY_TIMEOUT; public static final int SC_VERSION_static_NOT_SUPPORTED int SC_DECLINE; public static final int SC_DOES_NOT_EXIT_ANYWHERE; public static final int SC_NOT_ACCEPTABLE; 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; public void setDateHeader (String name, long date); public void setHeader (String name, String value); public void setIntHeader (String name, int value); public void setStatus ( int sc); public void setStatus (int sc, String sm);

As listed above, the interface comprises a definition of a number of constants (ie, final variables that do not change). These constants correspond to status codes defined within the SIP specification.

The SipServletResponse interface also comprises a number of methods. contai
The nsHeader method returns a Boolean value that specifies "whether the response has a header". Multiple sendError methods are defined to generate error alarms. The input parameters may comprise only the status code or the status code and message in string format. The sendRedirect method causes the exception to be redirected and specifies where the response should be redirected. The setDateHeader method establishes a value for a date header, and the setHeader method establishes a value for a given named header. The setIntHeader method sets the value for the integer header. The setStatus method may comprise an additional parameter of the string that sets the status code and specifies the status message.

[0029]   The SipSession interface has the following methods.   public long getCreationTime ();   public String getId ();   public long getLastAccessedTime ();   public int getMaxInactiveInterval ();   public Object getValue (String name);   public String [] getValueNames ();   public void invalidate ();   public boolean isNew ();   public void putValue (String name, Object value);   public void removeValue (String name);   public void setMaxInactiveInterval (int interval);

The getCreationTime method returns the creation time for the session. Generation time information is retrieved from the session description object. getId method is session I
Returns D. The getLastAccessedTime method returns information about the last time the session was accessed. The getMaxInactiveInterval method returns the longest period of time the session has been inactive. The getValue method returns the value for a given named attribute. The getValueNames method returns the names of the values in the session description object. The invalidate method invalidates the session, and the isNew method returns a Boolean value specifying "whether the session was newly created". The putValue method establishes a value for a given attribute. The removeValue method removes the value and the setMaxInactiveInterval method establishes the value for the maximum inactive interval attribute.

The SipSessionBindingListener interface is formally defined as follows. public void valueBound (SipSessionBindingEvent event); public void valueUnbound (SipSessionBindingEvent event

The SipSessionBindingListener interface is in the javax.servlet package.
Extend the EventListener interface. This interface is mainly
Causes an object to be notified when it comes to or comes from a session.

As mentioned above, the Servlet SIP Package comprises a number of objects. The SIP Servlet object is more formally defined as: public SipServlet (); protected void doInvite (SipServletRequest req, SipServletResponse resp
) throws ServletException, IOException; protected long getLastModified (SipServletRequest req); protected void doAck (SipServletRequest req, SipServletResponse resp) t
hrows ServletException, IOException; protected void doBye (SipServletRequest req, SipServletResponse resp) t
hrows ServletException, IOException; protected void doCancel (SipServletRequest req, SipServletResponse resp
) throws ServletException, IOException; protected void doRegister (SipServletRequest req, SipServletResponse re
sp) throws ServletException, IOException; protected void doOptions (SipServletRequest req, SipServletResponse res
p) throws ServletException, IOException; protected void service (SipServletRequest req, SipServletResponse resp) throws ServletException, IOException; public void service (SipServletRequest req, SipServletResponse resp) th
rows ServletException, IOException;

This object has a number of ways to handle individual types of requests. For example, the doInvite method is used to handle INVITE requests. Similar methods are provided for ACK, BYE, CANCEL, REGISTER and OPTION requests. The service request provides the default service as described above.

[0035]   The MediaDescription object is defined as follows.   public class MediaDescription   protected String name;   protected String address;   protected String title;   protected String connectionInfo;   protected String bandwidthInfo;   protected String encriptionKey;   protected String duration;   protected String mediaAttributes;   public MediaDescription ();

The MediaDescription object contains the name, address and title attributes for the media. In addition, connection information and bandwidth information are included therein. The encriptionKey may be included in the media description object, and
Duration information specifying the duration of the information contained in the media may also be included. Media Attributes may be included there.

[0037]   SessionDescription object class is defined as follows.   public class SessionDescription   protected String version;   protected String owner;   protected String name;   protected String sessionInfo;   protected String URI;   protected String email;   protected String phone;   protected String connectionInfo;   protected String bandwidthInfo;   protected Vector sessionAttrib;   protected String duration;   protected String schedule;   public SessionDescription ();

The session description object holds description information about a given session. Attributes include version attributes, owner attributes, and name attributes. Attributes are also session information and URI
To judge. Email information and phone information may also be stored as attributes. Connection information and bandwidth information may also be included as attributes. Duration and schedule information may also be included as attributes, and a vector of session attributes may also be included therein.

Although the present invention has been described with reference to illustrative embodiments of the invention, “various changes in shape and detail depart from the intended scope as defined in the claims. One of ordinary skill in the art will understand that "can be done without."

[Brief description of drawings]

FIG. 1 is a block diagram of a first system suitable for implementing an illustrative embodiment of the invention.

FIG. 2 is a block diagram of a second system suitable for carrying out an illustrative embodiment of the invention.

FIG. 3 is a flow chart illustrating the general steps performed to implement telephone service logic in an illustrative embodiment of the invention.

FIG. 4 is a flow chart illustrating steps performed to implement call screening in an illustrative embodiment of the invention.

FIG. 5 is a flow chart illustrating steps performed to effect call transmission in an illustrative embodiment of the invention.

[Explanation of symbols]

  12, 14 ... User device   16 ... SIP proxy server   18 ... User agent server   20, 24 ... Servlet manager   22, 26 ... Servlet   30, 32 ... User device   34 ... SIP redirect server   36 ... Servlet manager   38 ... Servlet

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW

Claims (25)

[Claims] 1. A method in a data processing apparatus, comprising:   Providing a Session Initiation Protocol (SIP) Servlet,   Steps to execute a SIP Servlet to implement the telephone service logic   To have   A method characterized by the following. 2. The data processing device is a SIP server   The method according to claim 1, wherein: 3. The method of claim 1, wherein a SIP Servlet inspects SIP messages as part of the telephone service logic. 4. The method of claim 1, wherein a SIP Servlet handles SIP invitations as part of the telephone service logic. 5. The method of claim 1, wherein a SIP Servlet handles SIP requests as part of the telephone service logic. 6. The method of claim 1, wherein a SIP Servlet handles the SIP response as part of the telephone service logic. 7. The method of claim 1, wherein the data processing device is part of a network supporting Internet Protocol (IP). 8. The data processing device is part of the Internet.   The method according to claim 1, wherein: 9. The telephone service logic is call transmission logic.   The method according to claim 1, wherein: 10. The telephone service logic is call screening logic.   The method according to claim 1, wherein: 11. A method in a computing environment, comprising: providing a servlet; providing a servlet manager to manage the servlet; receiving communication according to Session Initiation Protocol (SIP); A method comprising: determining with a servlet manager that one of the selected ones should handle communication; and processing the communication with the selected servlet. 12. The method of claim 11, wherein the step of processing the communication comprises sending the communication to a destination. 13. The method of claim 11, wherein the step of processing the communication comprises modifying the communication. 14. The method of claim 11, wherein the step of processing the communication comprises handling a SIP request. 15. The method of claim 11, wherein the step of processing the communication comprises handling a SIP response. 16. A method of performing by a data processing device to perform a method comprising: providing a Session Initiation Protocol (SIP) Servlet; and executing a SIP Servlet to implement telephone service logic. A medium characterized by holding instructions for. 17. The medium of claim 16, wherein the SIP Servlet inspects SIP messages as part of the telephone service logic. 18. The medium of claim 16, wherein a SIP Servlet handles SIP requests as part of the telephone service logic. 19. The telephone service logic is call transmission logic.   The medium according to claim 16, characterized in that 20. The telephone service logic is call screening logic.   The medium according to claim 16, characterized in that 21. An electronic device comprising an interface for receiving Session Initiation Protocol (SIP) messages and a servlet for handling SIP messages to implement telephone service logic. 22. The device is a computer system.   22. The device according to claim 21, characterized in that 23. Additional servlets to provide additional telephony service logic   Is further equipped with   22. The device according to claim 21, characterized in that 24. The device of claim 21, wherein the device receives an additional SIP message, and the device further comprises an additional servlet for processing the additional SIP message. 25. The apparatus of claim 24, wherein the apparatus further comprises, for each additional SIP message, a servlet manager that determines which servlet should process the message.