Patent Application
20070116223
Mobile handheld multifunction devices capable of both voice and data functions have proliferated in recent years. Certain mobile devices are capable of different network type connections. Examples of these different network types include the public switched telephone network (PSTN), mobile or wireless voice networks, e.g., public local mobile networks (PLMNs), IP networks, global system for mobile general packet radio service (GSM GPRS) networks, and public wireless local area networks (PwLANs), etc. GPRS is an enhancement to the GSM mobile communications system that supports data packets. GPRS enables continuous flows of IP data packets over the system for such applications as Web browsing and file transfer.
An IP network (e.g., the Internet) is composed of nodes of computers, servers, routers, and communications links, etc. The IP network employs packet-switching technology that decomposes data (e.g., voice, web pages, e-mail messages, etc.) into IP packets. Each packet is then transmitted over an IP network to a destination identified by an IP address and reassembled at the destination. An IP transmission is completed without pre-allocating resources from point to point.
Service and Media platforms, as used in communications networks including mobile networks, ISPs, corporate webservers, advertising agencies, etc., among others, are computing devices that include processor and memory capabilities, e.g., servers and databases. Media platforms can include hardware components, such as trunk lines, switches, routers, etc. Service platforms include servers having computer executable instructions operable thereon for the delivery of web services. Service and media platforms can include software, application modules, firmware, and other computer executable instructions operable thereon to perform various tasks and functions. Modern media platforms are becoming more and more functional, or intelligent, in terms of the services they can provide in cooperation with the software tools that are provided thereon. For example, today the PSTN (SS7 network) includes service control points (SCPs) and other intelligent peripherals which can execute instructions to provide 800 number services, voice mail, and interactive voice recognition (IVR), etc. Communications networks use instant messaging (IM), location services, audio and video conferencing capabilities, etc., in addition to regular phone services.
In a communication services delivery environment, there are different top to bottom, or “stove-pipe”, type software applications and connection channels. These individual applications and channels contain their own session context. For example, applications are offered by service providers that run in their own context without the ability to share data between them. Multiple application developers can work together to integrate their applications to offer a superset of application features. However, this process requires the application developers to be involved and may not be economically feasible for a large number of services.
A web services environment has defined methods for sharing data between applications. Web services include web-based applications that dynamically interact with other web applications using open standards that include extensible markup language (XML), universal description, discovery and integration (UDDI), and simple object access protocol (SOAP). Such applications run behind the scenes, one program talking to another, server to server. Telephony systems are typically not defined in web services terms. Thus, coordinating events and context between these two domains has been an issue. While proprietary methods to coordinate events and context between web applications and telephony have been used they are not implemented in a ubiquitous fashion.
Embodiments of the present invention provide for systems and methods based on Web Services standards that allow application to be chained, i.e., linked, together using the context of one application as input to another application. One method embodiment includes defining a call control XML (ccXML) element associated with accessing a web service application. The method includes extracting a session identification (ID) from a ccXML action in a telephony session. The session ID is used to store and retrieve session context in a context repository. A web service application is invoked using the session ID to coordinate events and context between the telephony session and the web service application.
Service Delivery Platform (SDP) Embodiment
An access point 105, conducting RF communication with such various devices 102-1, 102-2, . . . , 102-N, can include a base station in a mobile network and/or a wireless router/transceiver in a wireless LAN and can be a wireless “hot-spot” such as a Bluetooth or Wi-Fi access point in a public location. Embodiments of the invention, however, are not limited to these examples. Access points 105 can provide a wireless to wireline connection for access to the Internet 121. A virtual ISP 122 can exist within an Internet connection 121 which can facilitate Internet connection with the wireless access point 105 and handle roaming access, billing, and the like. The Internet 121 can have various connections, e.g., through gateways using TCP/IP, to the PSTN 120, to the world wide web (WWW) 145, etc. The SDP platform 101 has connections to the Internet 121, the PSTN 120, and the WWW 145 and can include a gateway 150 for handling voice, data, and video traffic, etc. In some embodiments the gateway 150 can provide authentication, access, and billing for connecting to the SDP 101.
The gateway 150 can interface with a mobile portal 152 which can include a server that deploys portal services, such as login 153, management 154, and profile management 155, to a public web site or internal intranet.
As described in more detail in connection with
SDP Architecture and Service Flow Embodiment
An application on the wireless device 202 can invoke a PTT telephony session through the network provider as described in connection with
According to various embodiments, ccXML applications 206 are used to expose one or more operator services as web services through a call control web services interface 212 illustrated within the M&C profile portion of the SDP 201. As described in the copending patent application “Service Chaining”, an SDP 201 can interact with a development tool to create the SDP application 205. One example of such a development tool includes a Macromedia Flash MX as available from Macromedia, Inc. Using such a development tool, an application developer, based on access rights can build, i.e., write, applications that embed the web services that are exposed in the SDP 201. The developer also embeds in the application the ability for services that are implemented to be associated with a session ID created by a ccXML application 206 handling a telephony session. In
Execution of various initiator services 203 on the mobile device 202 can connect to and message particular agent applications, e.g., 208-1 and 208-2, illustrated within the M&C profile portion of the SDP 201. The particular agent applications act as a user endpoint in a telephony session, e.g., a called number in a cellphone call, a GPRS address in a push to talk (PTT) session, or an address in an instant messaging (IM) session. In the embodiment of
As described in the copending patent application “Service Chaining”, through a service controller of an application server in SDP 201, the BOTS can initiate a web service such as GLMS, location services, conferencing, etc, and can retrieve and store session context in a context repository 282 in association with a session ID. As described in the above applications, a BOT can provide a method to allow a standard client endpoint such as an IM endpoint to participate in a service chain without involving modification of the endpoint client, e.g., the BOT acts as a gateway from the client to the service chaining architecture.
In
The authentication and access 265 to the UDDI registry 258 can be provided in the form of program instructions that execute to perform the respective functions of authentication, access policy, and authorization. For example, these program instructions can execute to access an authentication profile 286, e.g., a customer profile, that can include such information as a mobile user's mobile identification number (MIN), a mobile user's private information, address information, present status, etc.
As noted above, various web services can be made available through the program instructions on the SDP 201 by exposing these services on the SDP and using a development tool to create programs that embed the web services into mobile device program. The program developer embeds in the mobile application the ability for services that are implemented to be associated with a session ID. As will be described in more detail in connection with
SDP Application Server Embodiment
The Internet was designed to carry data but has increasingly been used to transport voice and multimedia information. On an IP network voice or multimedia information can be digitized as data and transported over the network using the IP, also referred to as voice over IP (VoIP). The session initiation protocol (SIP), promulgated by the internet engineering task force (IETF), is intended to achieve interoperability for VoIP among different networks. The SIP standard provides a specification for communication of multimedia such as voice, data and video between terminal equipment, e.g., PCs with telephony capabilities, VoIP phones, as well as mobile wireless multifunction devices communicating over a GPRS network that can connect to the Internet. With the introduction of digital networks, the exchanges and switches of the PSTN have been upgraded to handle digital, time division multiplexed trunk traffic between the exchanges. External digital communication systems can communicate with the PSTN through a digital interface at the exchange such as a primary rate interface (PRI) which is part of the integrated services digital network (ISDN). Web applications and their associated web pages were originally written in hypertext markup language (HTML) and can be hosted on the IP network on web servers. Web pages can be called up by their URI, which is an IP address on the Internet. XML is used to extend HTML with enhanced features including customizable tags that allow for more structural specification of data than available with HTML. ccXML involves creating telephony applications in XML scripts that include XML tags indicating how a telephone call is to be processed. For example, XML scripts associated with a particular called number can be provided in a database 306 on the SDP 301.
As noted above, in an ISDN, TCP/IP is used as the protocol to transmit information. In the PSTN (SS7 network), an ISDN user part (ISUP) is used to connect and disconnect calls. Telephony or computer telephony integration (CTI) involves using a computer to control and manage a phone or telephone system. That is, IP telephony pertains to the two-way transmission of voice over a packet-switched IP network, which is part of the TCP/IP protocol suite. Telephony, as used herein, includes realtime applications over IP, including voice over instant messaging (IM) and videoconferencing. When CTI is applied to a PSTN or IP telephony network system it is implemented with a computer telephony server. The SDP described herein can include an application server capable of acting as a computer telephony server. Such a server in the SDP, e.g., 201 in
ccXML applications are provided to and operable on by a server 300 in the SDP in order to provide for call control methods described in XML documents.
Embodiments of the disclosure can be performed by software and/or firmware (i.e., computer executable instructions), hardware, application modules, and the like, executable and/or resident on the application server 300. The embodiments are not limited to any particular operating environment or to instructions written in a particular programming language. The CT modules can include a set of software modules running on a Windows NT or Unix server. Embodiments, however, are not limited to these examples. For example, the application server 300 can be implemented as a Unix machine on a card, and multiple cards can be installed on a caged backplane to form a highly scalable system.
The application server 300 illustrates four software modules listed as a session manager 310, an I/O abstraction layer 320, a computer telephony (CT) abstraction layer 330, and a telephony scripting language parser 340. The telephony scripting language parser 340 is further illustrated including a ccXML parser 342 and a generic XML parser 344. In addition, a streaming interface 350 provides a direct streaming path for media data between the I/O abstraction layer 320 and the CT abstraction layer 330. Each of these modules is designed to be a separate dynamically linked library (DLL) and perform a particular task.
The session manager 310 is responsible for creating new sessions, deleting terminated sessions, routing all actions and events to the appropriate modules and maintaining modularity between each session. The session manager 310 responds to I/O and ccXML goto requests, and other additional events as the same will be appreciated by one of ordinary skill in the art. The session manager 310 interfaces to the external network of the application server 300 via the I/O abstraction layer 320, a library (LIB) 395, and the CT abstraction layer 330. It accesses the I/O and CT layers as a set of classes and member functions that are individual DLLs, as the same is understood in object oriented programming. The session manager 310 can run as a single-threaded processor of actions and events.
As illustrated in
In operation, a telephony session begins with the reception of an asynchronous event from the CT abstraction module 330 which signals an incoming call. The session manager 310 then creates a session for this call by accessing a database (e.g. context repository 282 of
The telephony scripting language parser 340 is a separate DLL invoked through short microXML event scripts. It returns a microXML action script. A cycle of actions and events begins with the transmission of this script to the telephony scripting language parser 340 for processing. The telephony scripting language parser 340 responds to this event by returning a ccXML script of its own containing I/O and CT action requests collected from the parsing of the script. The session manager 310 now processes these action requests and then returns to parsing until the end of the session.
Each session is assigned a unique session identification (ID). The session manager 310 is accessed or invoked via a number of interface points of its DLL, as the same will be appreciated by one of ordinary skill in the art. The I/O abstraction layer 320 performs input and output operations for the application server 300. The I/O abstraction layer 320 renders transparent to the internal of the application server 300 the variety of I/O formats and protocols that might be encountered externally to the server. The I/O abstraction layer 320 is accessed or invoked via a number of interface points of its DLL.
The CT abstraction layer 330 is an abstraction layer that makes it possible for the application server 300 to communicate with several computer telephony devices and/or protocols. In one direction, the CT abstraction layer 330 receives requests for computer telephony actions from the session manager 310 and translates those requests to a CT module. In the other direction, the CT abstraction layer 330 receives user events directed to that CT module and relates them back to the session manager 310. In the embodiment of
The CT abstraction layer 330 is instantiated (i.e., in object technology, the creation of an object of a specific class) by the session manager 310. In operation, the session manager 310, XML parser 340, and CT abstraction layer 330 can cooperate via the following protocol. First, the telephony scripting language parser 340 locates a ccXML element which is associated with a telephony task. Next, the telephony scripting language parser sends this task to the session manager 310 in a microXML action string. The session manager 310 then parses the microXML action string and determines the appropriate call to the CT abstraction layer 330 along with its associated parameters. The session manager 310 now calls the CT abstraction layer 330 asynchronously and the CT abstraction layer 330 returns an event signaling the completion of the CT task and the session manager 310 resumes parsing. The CT abstraction layer 330 is accessed or invoked via a number of interface points of its DLL.
The streaming interface 350 provides a direct streaming transfer between the I/O abstraction layer 320 and the CT abstraction layer 330 when media data, such as audio or other multimedia, is involved. For example, the streaming interface facilitates the application server 300 to play audio from URIs and to record audio to URIs in a streaming manner.
The telephony scripting language parser 340 is responsible for parsing the ccXML scripts handed to it by the session manger 310. It in turn informs the session manager 310 of the described actions coded in the ccXML scripts. The generic XML parser 344 parses the ccXML scripts, which include XML scripts with embedded custom tags to extend the features and functionality of ccXML to web services and to coordinate telephony and web services, and puts them in a format that the ccXML parser 342 can expediently act on. The generic XML parser 344 employs components which enable parsing of ccXML documents into an object model, e.g., document object model (DOM) listing the parsed objects in a hierarchical tree structure.
The ccXML parser 342 maintains state per session so that each invocation of the ccXML parser 342 will continue where the previous invocation within the same session ended. The maintenance of state includes preserving the DOM for the current instance of ccXML, the node in the DOM that the parser is currently examining, and any variables that are associated with the session. The ccXML parser 342 is accessed or invoked via a number of interface points of its DLL.
According to various embodiments, the ccXML applications include the addition of embedded custom tags to extend the features and functionality of ccXML to web services and to coordinate telephony and web services applications. Upon reading this disclosure, one of ordinary skill in the art will appreciate the manner in which a program developer could write a number of ccXML tags to extend the features and functionality of ccXML to web services (exposed on the application server 300) and to coordinate telephony and web services thereon. The features and functionality of ccXML are extended to web services by using the session ID and event handling mechanisms of ccXML. The extended features and functionality of ccXML can be provided by customized tags which recognize a request for web services and can execute to retrieve an appropriate resource. By way of example and not by way of limitation, the ccXML application can execute to connect with a resource such as a service controller in an application server in the SDP in order to access and retrieve a requested web service. Example web services can include location services, conferencing services, short message service (SMS), email messaging services, etc. By extending the features and functionality of ccXML to such web services (and using a session ID for accessing session context as described more next in
ccXML Extension Embodiment
IP telephony involves one protocol for transport and another for signaling. As illustrated in
The embodiment of
The embodiment of
In various embodiments, the application server 400 includes program instructions which can execute as agents to initiate server side applications, e.g, the ccXML applications with their features and functionality extended to web services using a session ID and the event handling mechanisms of ccXML. SOAP can be used to provide access to particular web services, e.g., click to connect (C2C) service 421, provide media and bridge connections 417, etc., in response to a particular executing ccXML application 406. Further, as illustrated in the embodiment, such program instruction agents can execute instructions to store the associated session ID in a context repository 482. One example for suitable program instruction agents is described in the copending patent application “Service Chaining”.
Thus, a web service application or service requested can have its URI, and other web session information, associated with an existing session ID in the context repository and effectively add information to an existing session context. As described in “Service Chaining”, the program instruction agents on the application server 400 act as user endpoints, e.g., called partys, and initiate a service or service chain. For example, in some embodiments of the “Service Chaining” application, BOTS are used which act as end point clients (e.g., user endpoints) in a PTT or IM telephony session to extract parameters which can subsequently be used by a next application in the chain. These parameters can include session participants, presence details, phone numbers, etc. By acting as clients to the PTT or IM telephony session environment, the existing telephony applications to mobile devices do not require modification. The BOT extracts information about a telephony session and then can use the session context from the context repository 482 to invoke another application. Examples of using a session context to invoke another application are described in the copending patent application “Service Chaining”.
According to various embodiments, the extended features and functionality of ccXML can include location services, conferencing services, short message service (SMS), email messaging services, etc. By extending the features and functionality of ccXML to such web services, and using a session ID for accessing session context, the embodiments of the present disclosure can coordinate telephony and web services between the telephony and web services environment.
Embodiments Employing Session Context Based on Session ID
As described in connection with
The embodiment of
As shown in the example embodiment of
In connection with this group service, program instructions on the SDP 501 execute to associate and store information associated with the group web service, e.g., parameters such as names, URI, etc., to a session context associated with a session ID in the context repository 582. For example, the program instructions can execute to store information associated in with the group web service to a particular session context in the context repository using an interface such as JDBC. As illustrated in this example embodiment the program instructions can also execute to provide a session pointer to the URI of the group web service in order to extract parameter information therefrom.
A user could then select from among various groups and/or particular groups names provided to the SDP 505. The SDP client 505 application on the wireless device can execute to present a user of the SDP client 505 with a number of other available web services via icons on the display such as the C2C icon illustrated in
As described above, the URI-WSDL (e.g., location and access) information for this web service can be obtained through a UDDI API call to a UDDI in the SDP 501 and actual access to the C2C web service 540-1 can be provided through the WSDL and SOAP. In this example, phone calls are started and can be handled through a ccXML application. Program instructions executing on an application server of the SDP 501 can execute to provide a session pointer to the URI of the C2C web service back to the context repository 582 in order to add information to the session context based on the appropriate session ID.
In connection with this C2C web service, program instructions on the SDP 501 can execute to associate and store information associated with the C2C web service, e.g., call participants, call status, URIs, etc., to the session context associated with the session ID in the context repository 582. In this manner, the program instructions can continue to store information associated with the C2C web service, and/or other web services invoked through this methodology, to the session context in the context repository 582 based on the session ID.
Hence, embodiments disclosed herein describe providing ccXML applications, having functionality extended to web services, to a SDP. These extended functionality ccXML applications are used to form a session ID and to store session context in a context repository based on the session ID. The session ID can then be used to coordinate session context between the telephony and web services domains.
Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art will appreciate that an arrangement calculated to achieve the same techniques can be substituted for the specific embodiments shown. This disclosure is intended to cover adaptations or variations of various embodiments of the invention. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Combination of the above embodiments, and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The scope of the various embodiments of the invention includes other applications in which the above structures and methods are used. Therefore, the scope of various embodiments of the invention should be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.
In the foregoing Detailed Description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
