CA2395616A1 - Session initiation protocol servlet application programming interface - Google Patents
Session initiation protocol servlet application programming interface Download PDFInfo
- Publication number
- CA2395616A1 CA2395616A1 CA002395616A CA2395616A CA2395616A1 CA 2395616 A1 CA2395616 A1 CA 2395616A1 CA 002395616 A CA002395616 A CA 002395616A CA 2395616 A CA2395616 A CA 2395616A CA 2395616 A1 CA2395616 A1 CA 2395616A1
- Authority
- CA
- Canada
- 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.)
- Abandoned
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
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 .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 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_ 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 ;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 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
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 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 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;
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);
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);
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) 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;
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 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.
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 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_ 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 ;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 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
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 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 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;
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);
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);
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) 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;
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 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.
Claims (25)
1. In a data processing apparatus, a method, comprising the steps of:
providing a Session Initiation Protocol (SIP) servlet; and running the SIP servlet to implement telephone service logic.
providing a Session Initiation Protocol (SIP) 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.
server.
3. The method of claim 1, wherein, as part of the telephone service logic, the SIP
servlet examines an SIP message.
servlet examines an SIP message.
4. The method of claim 1, wherein, as part of the telephone service logic, the SIP
servlet processes an SIP invitation.
servlet processes an SIP invitation.
5. The method of claim 1, wherein, as part of the telephone service logic, the SIP
servlet processes SIP requests.
servlet processes SIP requests.
6. The method of claim 1, wherein, as part of the telephone service logic, the SIP
servlet processes SIP responses.
servlet processes SIP 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.
11. In a computing environment, a method, comprising the steps of:
providing servlets;
providing a servlet manager for managing the servlets receiving a communication that 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.
providing servlets;
providing a servlet manager for managing the servlets receiving a communication that 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 the communication.
14. The method 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 SIP 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 naming the SIP servlet to implement telephone service logic.
providing a Session Initiation Protocol (SIP) servlet; and naming the SIP 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.
servlet examines an SIP message.
18. The medium of claim 16, wherein, as part of the telephone service logic, the SIP
servlet processes SIP requests.
servlet processes SIP 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.
15~
15~
21. An electronic device, comprising:
an interface for receiving a Session Initiations Protocol (SIP) message; and a servlet for handing the SIP message to implement telephone service logic.
an interface for receiving a Session Initiations 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 SIP
messages and wherein the device further comprises additional servlets for processing the additional SIP
messages.
messages and wherein the device further comprises additional servlets for processing the additional SIP
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.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US45742899A | 1999-12-08 | 1999-12-08 | |
| US09/457,428 | 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 |
|---|---|
| CA2395616A1 true CA2395616A1 (en) | 2001-06-28 |
Family
ID=23816689
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002395616A Abandoned CA2395616A1 (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)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8914022B2 (en) | 1992-03-06 | 2014-12-16 | Gogo Llc | System for providing high speed communications service in an airborne wireless cellular network |
| 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 |
| 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)
| 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 |
-
2000
- 2000-12-08 WO PCT/US2000/042695 patent/WO2001046822A1/en not_active Application Discontinuation
- 2000-12-08 EP EP00992885A patent/EP1240593A1/en not_active Withdrawn
- 2000-12-08 BR BR0016237-0A patent/BR0016237A/en not_active IP Right Cessation
- 2000-12-08 AU AU47149/01A patent/AU4714901A/en not_active Abandoned
- 2000-12-08 CA CA002395616A patent/CA2395616A1/en not_active Abandoned
- 2000-12-08 CN CN00818877.7A patent/CN1433547A/en active Pending
- 2000-12-08 MX MXPA02005701A patent/MXPA02005701A/en unknown
- 2000-12-08 JP JP2001547269A patent/JP2003518352A/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| BR0016237A (en) | 2002-08-27 |
| AU4714901A (en) | 2001-07-03 |
| MXPA02005701A (en) | 2002-12-13 |
| JP2003518352A (en) | 2003-06-03 |
| CN1433547A (en) | 2003-07-30 |
| WO2001046822A1 (en) | 2001-06-28 |
| EP1240593A1 (en) | 2002-09-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Rosenberg et al. | An offer/answer model with session description protocol (SDP) | |
| JP4199670B2 (en) | Communication application server for converged communication services | |
| EP1574029B1 (en) | Dynamic user state dependent processing | |
| EP1886467B1 (en) | Generating and transforming call control elements, dialog elements, and session initiation protocol messages for telephony service applications | |
| US7050861B1 (en) | Controlling a destination terminal from an originating terminal | |
| US8379544B2 (en) | Communications | |
| WO2005070115A2 (en) | Proprietary protocol for voip based features | |
| WO2011133472A1 (en) | Unified framework and method for call control and media control | |
| CA2395616A1 (en) | Session initiation protocol servlet application programming interface | |
| MXPA02005700A (en) | Telephone fraud detection and prevention. | |
| US20060161616A1 (en) | Provision of services over a common delivery platform such as a mobile telephony network | |
| EP1528713A2 (en) | Remote monitoring of graphical telecommunications terminals | |
| EP1247387B1 (en) | Improved session initiation protocol (sip) | |
| EP1681832A1 (en) | Provision of services over a common delivery platform such as a mobile telephony network | |
| US9049310B2 (en) | Data communication | |
| Kolberg et al. | Managing feature interactions between distributed SIP call control services | |
| EP1111875B1 (en) | Controlling a destination terminal from an originating terminal | |
| Rosenberg et al. | RFC3264: An Offer/Answer Model with Session Description Protocol (SDP) | |
| US20090254665A1 (en) | Trigger-Based Session Completion Using External Parties | |
| Chan et al. | Modeling IETF Session Initiation Protocol and its services in SDL | |
| Chentouf et al. | Mapping sip onto a feature interaction management language | |
| Hsieh et al. | NTP-DownloadT: a conformance test tool for secured mobile download services | |
| Kolberg et al. | Detecting Feature Interactions between SIP Call Control Services. | |
| WO2001035594A2 (en) | Telecommunications control protocol processing | |
| Chlamtac et al. | An OSA service capability server for mobile services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |