(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2012/0016932 A1
`(43) Pub. Date:
`Jan. 19, 2012
`de Castro, JR. et al.
`
`US 201200 16932A1
`
`(54)
`
`SYSTEMAND METHOD FOR TELEPHONY
`AND COMMUNICATION SERVICES WITH
`MESSAGE-BASED API
`
`(75)
`
`Inventors:
`
`(73)
`
`Assignee:
`
`Appl. No.:
`
`Jose Maria de Castro, JR.,
`Orlando, FL (US); Neil Stratford,
`Ely (GB); Wei Chen, Saratoga, CA
`(US); Zhiyu Liu, Beijing (CN);
`Xiaopu Zhu, Beijing (CN); Jason
`Scott Goecke, San Carlos, CA (US)
`Voxeo Corporation, Orlando, FL
`(US)
`13/187,253
`
`(21)
`(22)
`
`(63)
`
`(60)
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 5/16
`(52) U.S. Cl. ........................................................ 709/203
`
`ABSTRACT
`(57)
`A communication application server is provided with a uni
`fied framework for call control and media control. The frame
`work Supports a unified API having class objects and func
`tions conforming to a telephony object model. The class
`objects are invoked and manipulated by a finite set of com
`mands and an application program essentially issues a series
`of such commands to operate the communication application
`server. More particularly, an API server on the communica
`tion application server defining a messaging API protocol
`enables an application script to pass commands remotely to
`the communication application server to operate it. This
`allows application scripts to be processed remotely by appro
`priate Scripting engines. In this way, application scripting is
`decoupled from the operation of the communication applica
`tion server, which only needs to focus on providing basic
`communication services.
`
`Filed:
`
`Jul. 20, 2011
`
`Related U.S. Application Data
`Continuation-in-part of application No. 13/088,396,
`filed on Apr. 17, 2011.
`Provisional application No. 61/325,355, filed on Apr.
`18, 2010.
`
`
`
`10 N.
`
`210
`
`Objects-Coded
`Scripts
`
`Application Platform 100
`
`CLIENTS
`
`
`
`- RTPSIP
`
`
`
`Other
`Clients
`
`COMMUNICATION
`APPLICATION SERVER
`
`BROWSER220
`
`COMMUNICATION
`APPLICATION 300
`
`SERVER-SIDE
`COMPONENTS
`310
`
`
`
`| e BACK-END
`
`2
`30
`
`
`
`MEDIA
`SERVER
`
`SYSTEMS
`Legacy
`CRMIERP
`
`COMMUNICATION APPLICATION ENVIRONMENT
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 1 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 1 of 19
`
`US 2012/0016932 A1
`
`10 N.
`
`
`
`
`
`21 O
`
`Objects-Coded
`Scripts
`
`Application Platform 100
`
`CLIENTS
`
`
`
`RTP/SIP
`
`COMMUNICATION
`APPLICATION SERVER
`
`BROWSER 220
`
`COMMUNICATION
`APPLICATION 300
`
`SERVER-SIDE
`COMPONENTS
`310
`
`
`
`Other
`Clients
`
`2
`
`MEDIA
`SERVER
`
`RTP
`
`BACK-END
`SYSTEMS
`Legacy
`CRM/ERP
`
`COMMUNICATION APPLICATION ENVIRONMENT
`FIG. 1
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 2 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 2 of 19
`
`US 2012/0016932 A1
`
`VoIP
`Phone 22
`
`APPLICATION
`SERVER
`
`
`
`
`
`CALL Server
`FIG. 2A
`
`Media (direct)
`
`APPLICATION
`SERVER200
`
`CALL another Endpoint
`FIG. 2B
`
`APPLICATION
`SERVER200
`
`CALL Conference
`FIG. 2C
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 3 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 3 of 19
`
`US 2012/0016932 A1
`
`COMMUNICATION APPLICATION 300
`
`
`
`SERVER-SIDE COMPONENTS 31
`
`Call Control
`Objects
`
`SIP Servlets
`
`SIP Servlet
`Cal COntrol API
`(e.g. JSR 289)
`
`SIP Servlet
`Container
`
`Media Control
`Objects
`
`Media Control AP
`(e.g. JSR 309)
`
`FIG. 3A (PRIOR ART)
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 4 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 4 of 19
`
`US 2012/0016932 A1
`
`
`
``N / ( US )
`
`S.
`
`
`
`(Zs) (Gs) (Gs) (ºs)
`
`
`
`
`
`
`
`
`
`005 NOILVOITddV NOI LVOINT INWOO
`
`
`
`
`
`
`
`(Zs) (Gs) (Gs) (ºs)
`
`
`
`
`
`
`
``N /(Zs) (Gs) (Gs) (ps)
`
`
`
`
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 5 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 5 of 19
`
`US 2012/0016932 A1
`
`SERVER-SIDE COMPONENTS 31
`
`
`
`COMMUNICATION APPLICATION 300
`
`m sm em em em em em em m em m em m sm em?e--
`
`Application components built from high-level
`Communication objects
`
`UNIFIED COMMUNICATION FRAMEWORK 400
`
`422
`High-level Communication class objects constructed
`from low-level objects of SIP Servlet and Media
`Control APIs with their events linked by the
`requirement of each media object model
`
`Unified CaCOntrol & Media COntrol AP
`420
`
`Call Control AP
`SIP Servlet/USR 289
`
`Media Control AP
`USR 309
`
`FIG. 4
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 6 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 6 of 19
`
`US 2012/0016932 A1
`
`SERVER-SIDE COMPONENTS
`
`
`
`COMMUNICATION APPLICATION 300
`
`450
`
`Observer (Unified Event Listener)
`
`Unified Signal and
`Media Events
`
`UNIFIED COMMUNICATION FRAMEWORK 400
`
`Unified Framework AP 420
`
`446
`
`332
`
`Media Event
`Listener
`
`SIP Servlet
`
`SignalEvents
`
`Media Events
`
`Call Control AP
`SIP Servlet/USR 289
`
`Media Control API
`USR 309
`
`F.G. 5
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 7 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 7 of 19
`
`US 2012/0016932 A1
`
`
`
`UNIFIED COMMUNICATION APPLICATION 300
`
`Observer 450
`
`G)State("Initial")
`MylnviteHandler(InviteEvent)
`
`GState("Connected")
`MyByeHandler(InviteEvent)
`
`OState("Connected")
`MyPlayerHandler(Output.Com
`pleteEvent)
`
`Only programmed Events is
`sent to the Application
`
`UNIFIED COMMUNICATION FRAMEWORK 400
`
`Event(EventType, State)
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 8 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 8 of 19
`
`US 2012/0016932 A1
`
`<<interface>>
`Observer
`
`
`
`
`
`<<interface>>
`Application
`
`+ init(ctX: ApplicationContext): void
`+ destroy() : void
`
`APPLICATION OBJECT
`
`FIG. 7
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 9 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 9 of 19
`
`US 2012/0016932 A1
`
`
`
`a-interface>>
`Participant
`
`+ getAddress(): Endpoint
`+ join(other: Participant, type : JoinType, direction: Direction): Joint
`+ unjoin(other: Participant): void
`+ getParticipants(): Participant
`+ getParticipants(direction: Direction) : Participant
`+ disconnect() : void
`+ gebtfediaObject() : MediaObject
`
`<<interface>>
`MultiStream Participant
`
`+ getJoinableStream(Value : StreamType) : JoinableStream
`+ getJoinableStream() : JoinableStream
`
`a Cinterfacedd
`Call
`
`+join(): Joint
`+ join(direction: Direction): Joint
`+join(other: CallabieEndpoint, type : JoinType, direction: Direction): Joint
`+join(other: CaiiabieEndpoint, type : JoinType, direction: Direction,
`headers : Map<String,String>): Joint
`+ isSupervised () : boolean
`setSupervised(Supervised boolean): void
`+ getMediaService(reinvite : boolean): MediaService
`+ getMediaService() : MediaService
`+ getCallState(): State
`+ getPeers(): Call)
`+ mute() : void
`+ unmute() : void
`+ hold(): void
`+ unhold () : void
`
`CALL OBJECT
`
`FIG. 8
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 10 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 10 of 19
`
`US 2012/0016932 A1
`
`
`
`
`
`<<interface.>
`Participant
`
`+ getAddress(): Endpoint
`+ join(other: Participant, type : JoinType, direction: Direction): Joint
`+ unjoin(other: Participant): void
`+ getParticipants(): Participant
`+ getParticipants(direction: Direction) : Participant
`+ disconnect(): void
`+gebtfediaObject() : MediaObject
`
`<<interface>>
`MultiStream Participant
`
`+ getJoinableStream (value : StreamType) : JoinableStream
`+ getJoinableStream() : JoinableStream
`
`
`
`
`
`<<Interfaced
`Mixer
`
`+ getMediaService() : MediaService
`
`<<interface>>
`Conference
`
`
`
`+ getMaxSeats(): int
`+getOccupiedSeats(): int
`
`MIXER OBJECT
`
`FIG. 9
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 11 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 11 of 19
`
`US 2012/0016932 A1
`
`
`
`<<interface>>
`MediaService
`
`+ output(text: String): Output
`+ output(media URL):Output
`+ Output(Output : Output.Command): Output
`+ prompt(text: String, grammar: String, repeat: int): Prompt
`+ prompt(media LIRL, grammar: String, repeat: int): Prompt
`+ prompt(output: OutputCommand, input: inputCommand, repeat: int):
`Prompt
`+ input(grammar: String): input
`+ input(input . InputCommana). Input
`+ record(recording : URL): Recording
`+ record(Command: RecordCommand): Recording
`+ getMediaGroup() : MediaGroup
`
`<<Interface>>
`MediaServiceFactor
`
`+ create(parent : EventSource, Session : MediaSession) : MediaService
`
`MEDIA SERVICE OBJECT
`
`FIG 10
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 12 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 12 of 19
`
`US 2012/0016932 A1
`
`EVENT
`
`EVENT <EventSOUrCed
`
`JoinCompletevent
`
`
`
`
`
`+ JoinCompleteEvent(source EventSource, p : Participant)
`+ getSource() : EventSource
`+ getParticipant() : Participant
`
`Media Event
`- serialVersionUID . long = -8340424.75008111087L
`+ MediaEvent(source: EventSource)
`+ getSource() : EventSource
`
`SignalEvent
`- serialVersionUID. long = -4.0478233568017450591
`+ SignalEvent(source: EventSource)
`+ getState(): EventState
`+ accept() : void
`#setState(state : EventState): void
`#checkState() : void
`
`Gueue Event
`
`+ QueueEvent(source: EventSource)
`
`EVENT DIAGRAM
`FIG. 11
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 13 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 13 of 19
`
`US 2012/0016932 A1
`
`
`
`
`
`
`
`OO
`
`OO
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 14 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 14 of 19
`
`US 2012/0016932 A1
`
`App
`Clients
`
`
`
`
`
`
`
`
`
`HTTP
`DN/Name
`
`
`
`DIRO(DN)/
`DNS(Name)
`
`Platform
`N
`
`App IP Addr
`HTTP
`DIR1 (DN)/DNS(Name)
`
`
`
`Application Platform having App Servers Providing
`Communication Services while Processing Application Scripts
`F.G. 13
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 15 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 15 of 19
`
`US 2012/0016932 A1
`
`
`
`
`
`
`
`AppServer
`IP Addr
`
`14
`
`IRO(DN)/
`DNS(Name)
`
`309 API 5. FWOrk API
`
`
`
`ERVICE DOMAIN 201
`
`COMMUNICATION API GATEWAY 500
`ApplD App ServerlD
`...
`- 520
`
`
`
`
`
`
`
`
`
`CUSTOMERIDEVELOPER DOMAIN 601
`
`
`
`
`
`AP Client 1
`
`CUSTFWOrk 1
`App Script 1
`
`
`
`AP Client K
`
`CUSTFWOrk K
`App Script k
`
`Application Servers Providing Communication Services while exchanging
`Command Messages with Remote Application Scripts
`F.G. 14
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 16 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 16 of 19
`
`US 2012/0016932 A1
`
`APP SERVER MODULES 250
`
`
`
`VOIP PhOneS/ClientS
`
`SIP/RTP
`
`ADMIN 280
`
`CALL 8 MEDIA DRIVERS 350, 360
`
`282
`
`Monitorin
`Itoring
`
`284
`
`StatistiCS
`
`CALL
`MANAGER
`2
`260
`
`ACTORS 270
`272-1
`Msg Queue 1
`
`27O-1
`Call ACtOr 1
`
`272-2
`
`270-2
`
`Msg Queue 2
`
`Call ACtor 2
`
`286
`
`OOS
`
`Call ID
`Registry
`
`Billin
`9
`
`272-f
`
`270-f
`
`Msg Queue i
`
`Call ACtor i
`
`COMMUNICATION APP
`FRAMEWORK 400
`
`AP SERVER 450
`
`XMPP
`
`AP Clients via
`Communication AP Gateway
`
`FIG. 15
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 17 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 17 of 19
`
`US 2012/0016932 A1
`
`Call ID
`
`GUID
`
`Server IP Address
`
`FIG. 16
`
`
`
`AP SERVER 450
`
`Unified AP
`
`Validator
`
`ParSer
`
`Actor LOCatOr
`
`XMPP Server
`
`XMPP
`
`AP Clients via
`Communication AP Gateway
`
`FIG. 17
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 18 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 18 of 19
`
`US 2012/0016932 A1
`
`SERVICE DOMAIN
`
`XMPP
`
`COMMUNICATION API GATEWAY 500
`
`520
`
`ReSOurCe LOad Balancer
`
`530
`
`XMPP Server
`
`40 5
`
`XMPP
`
`FIG. 18
`
`USER DOMAIN
`
`
`
`Registry 520
`SERVICE DOMAIN
`
`App
`ServerD
`
`App Server
`Properties/
`Status
`
`USER DOMAIN
`
`App
`Properties/
`Status
`
`F.G. 19
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 19 of 35
`
`

`

`Patent Application Publication
`
`Jan. 19, 2012 Sheet 19 of 19
`
`US 2012/0016932 A1
`
`
`
`Deploying an application server on a network for providing telephony and 700
`Communication Services,
`
`Providing a communication framework at the application server for the
`telephony and communication services, the Communication framework 702
`providing an API with a set of class objects for unified call control and
`media control, so that the API allows programmatic access to the
`telephony and communication services by an API client on the network
`
`Providing at the application server a messaging API server, the
`messaging API server having a predefined messaging protocol for the
`AP
`
`Receiving into the application server commands issued by the API client
`for invoking and manipulating the class objects relative to a call, the
`Commands being packaged as messages Conforming to the predefined
`messaging protocol for the AP
`
`Parsing the messages according to the predefined messaging protocol
`for the API to obtain the Commands
`
`Executing in the application server the commands to the call in the order
`the COmmands become available
`
`704
`O
`
`710
`
`712
`
`720
`
`FIG. 20
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 20 of 35
`
`

`

`US 2012/001 6932 A1
`
`Jan. 19, 2012
`
`SYSTEMAND METHOD FOR TELEPHONY
`AND COMMUNICATION SERVICES WITH
`MESSAGE-BASED API
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`0001. This application is a continuation-in-part of U.S.
`Application No. 13/088,396 filed on Apr. 17, 2011, which
`claims the benefit of U.S. Provisional Patent Application No.
`61/325,355 filed on Apr. 18, 2010.
`
`BACKGROUND OF THE INVENTION
`0002 The present invention relates to telecommunication
`and a networked computer telephony System, and more par
`ticularly to a system and method for providing a telephony
`enabled service via a message-based API interface.
`0003. Two major telecommunication networks have
`evolved worldwide. The first is a network of telephone sys
`tems in the form of the Public Switched Telephone System
`(PSTN). This network was initially designed to carry voice
`communication, but later also adapted to transport data. The
`second is a network of computer systems in the form of the
`Internet. The Internet has been designed to carry data but also
`increasingly being used to transport Voice and multimedia
`information. Computers implementing telephony applica
`tions have been integrated into both of these telecommunica
`tion networks to provide enhanced communication services.
`For example on the PSTN, computer telephony integration
`has provided more functions and control to the POTS (Plain
`Old Telephone Services). On the Internet, computers are
`themselves terminal equipment for Voice communication as
`well as serving as intelligent routers and controllers for a host
`of terminal equipment.
`0004. The Internet is a worldwide network of IP networks
`communicating under TCP/IP (Transmission Control Proto
`col/Internet Protocol) suite. Specifically, voice and other mul
`timedia information are transported on the Internet under the
`VoIP (Voice-over-IP) protocol.
`0005. The integration of the PSTN and the IP networks
`allows for greater facility in automation of voice applications
`by leveraging the inherent routing flexibility and computing
`accessibility in the IP networks.
`0006 An example platform for easy deployment of tele
`phony applications is described in U.S. Pat. No. 6,922,411,
`which entire disclosure is incorporated herein by reference.
`Essentially, a networked telephony System allows users to
`deploy on the Internet computer telephony applications asso
`ciated with designated telephone numbers. The telephony
`application is easily created by a user in XML (Extended
`Markup Language) with predefined telephony XML tags
`(e.g. VoiceXML) and easily deployed on a website. The tele
`phony XML tags include those for call control and media
`manipulation. A call to anyone of these designated telephone
`numbers may originate from anyone of the networked tele
`phone system such as the PSTN (Public Switched Telephone
`System), a wireless network, or the Internet. The call is
`received by an application gateway center (AGC) installed on
`the Internet. Analogous to a web browser, the AGC provides
`facility for retrieving the associated XML application from its
`website and processing the call accordingly.
`0007. This type of telephony platform allows very power
`ful yet simple telephony applications to be built and deployed
`on the Internet. The following are some examples of the
`
`telephony applications deployed on this platform. A “Follow
`me, find me’ application sequentially calls a series of tele
`phone numbers as specified by a user until one of the numbers
`answers and then connects the call. Otherwise, it does some
`thing else such as takes a message or sends e-mail or sends the
`call to a call center, etc. In another example, a Telephonic
`Polling application looks up from a database the telephone
`numbers of a population to be polled. It then calls the numbers
`in parallel, limited only by the maximum number of concur
`rent sessions Supported, and plays a series of interactive Voice
`prompts/messages in response to the called party's responses
`and records the result in a database, etc. In another example,
`a Help Desk application plays a series of interactive Voice
`prompts/messages in response to the called party's responses
`and possibly connects the call to a live agent as one option,
`etc. In yet another example, a Stock or Bank Transactions
`application plays a series of interactive Voice prompts/mes
`sages in response to the called party's responses and conducts
`appropriate transactions with a backend database or web
`application, etc.
`0008. The latter examples are generally referred to as self
`help applications. In the Voice context, a self-help application
`is referred to as IVR. IVR refers to Interactive Voice Response
`and is a technology that automates interaction with telephone
`callers. Enterprises are increasingly turning to IVR to reduce
`the cost of common sales, service, collections, inquiry and
`Support calls to and from their company.
`0009 IVR solutions enable users using voice as a medium
`or other form of inputs through a voice channel to retrieve
`information including bank balances, flight schedules, prod
`uct details, order status, movie show times, and more from
`any telephone. Additionally, IVR solutions are increasingly
`used to place outbound calls to deliver or gather information
`for appointments, past due bills, and other time critical events
`and activities.
`0010 FIG. 1 illustrates schematically a communication
`application environment. The communication application
`environment 10 includes one or more client interacting with a
`communication application server 200 in an application plat
`form 100. The application platform 100 hosts an application
`specified by an application script 210 coded in object-ori
`ented software. The communication application server 200
`includes a browser 220 for interpreting and executing the
`application script 210. The execution of the application script
`invokes one or more server-side components 310 in the appli
`cation server 200. Among the clients and the communication
`server, these components 310 provide services for call con
`trol, media control with one or more media server 230 and
`interactions with back-end systems 240 such as databases,
`and business logic and legacy systems such as CRM (Cus
`tomer Relationship Management) and ERP (Enterprise
`Resource Planning). One example of the platform is to hostan
`IVR application which interacts with Voice, text messaging
`and other clients in a multi-channel environment.
`0011. The communication application platform provides a
`third-party call control between any numbers of clients 20,
`22, 30. The application script 210 defines the communication
`application 300 and directs how a call is to be handled. For
`example, when a user makes a call through a voice client Such
`as a handset 20 or a VoIP phone 22 to the IVR, the voice
`application script 210 associated with the call number is
`retrieved. The browser 220 executes or renders the retrieved
`voice application script to allow the user to interact with the
`voice application 300.
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 21 of 35
`
`

`

`US 2012/001 6932 A1
`
`Jan. 19, 2012
`
`0012 Communication of Multimedia information among
`endpoints and a third-party call controller generally require
`call control and media control.
`0013 FIG. 2A to FIG. 2C illustrate various call scenarios
`among a number of clients such as VoIP phones 22 or end
`points and a communication application server 200.
`0014 FIG. 2A illustrates a client in the form of a VoIP
`phone calling the communication application server. For
`example, the communication application server 200 hosts an
`IVR and the VoIP phone 22 calls the IVR. Call signaling and
`media are exchanged between the VoIP phone 22 and the
`application server 200.
`0015 FIG. 2B illustrates a first VoIP phone calling a sec
`ond VoIP phone. As a third-party call controller, the applica
`tion server 200 controls the call between the first and second
`phones. A call connection is established between the first
`phone 22-1 and the application server 200. Another call con
`nection is established between the second phone 22-2 and the
`application server 200. The two calls are then joined at the
`application server to allow the first phone to talk to the second
`phone. In this scenario, media can be handled in one of two
`modes. In the bridged mode, media exchanged between the
`two phones are routed through the application server. In the
`direct mode, the media is exchanged directly between the two
`phones.
`0016 FIG. 2C illustrates three phones in conference. In
`this scenario, each phone establishes a call to the application
`server. The three calls are then joined or mixed at the appli
`cation server to provide a conference facility.
`0017 For call control, a number of protocol standards
`have been put forward for interoperability. For example, the
`H.323 standard is a protocol standard recommended by the
`ITU (International Telecommunication Union) for signaling
`and call control of IP telephony.
`0018. An increasingly popular alternative to the H.323
`standard for call control is SIP (“Session Initiation Proto
`col.) SIP is an IETF (Internet Engineering Task Force) pro
`tocol for signaling and call control of IP telephony and mul
`timedia communication between two or more endpoints. It is
`text-based and more web-centric and is a comparatively sim
`pler and more light-weight alternative to H.323.
`0019. In the traditional web paradigm, a user agent in the
`form of a client machine running a web browser makes a
`request to a web server. The web server returns a response to
`the request. The communication is taking place under the
`HTTP (Hypertext Transfer Protocol). Specifically, the web
`browser requests a web resource Such as a web page as speci
`fied by an URL from a web server. Typically the web server
`responds by returning the requested web page. The web page
`may contain text content with embedded instructions for the
`browser to render the text in the web page. In more sophisti
`cated applications, a web page is often generated dynamically
`by employing server-side programs and may incorporate con
`tent as queried results from backend databases. Thus, Some of
`the content are not hard-coded on the web page but are gen
`erated and rendered dynamically by the web server. The
`server-side programs may also serve to post data from the
`client to the backend databases.
`0020 Traditionally, these server-side programs are imple
`mented as Scripts conforming to the CGI protocol (Common
`Gateway Interface). The CGIs are code modules that perform
`the task on the web server to generate and render dynamic
`content or perform other backend functions.
`
`However, CGI has several disadvantages. First, it is
`0021
`not very portable, as different web serving machines with
`different processors and operating systems may require their
`own versions of Scripts. Secondly, it does not use the server
`resource efficiently. The different GCIs are run in a different
`process context than the server which starts them. There is the
`overhead of creating a new process for each request and the
`different processes do not have access to a common set of
`SWC CSOCCS.
`0022. The JAVATM servlet model addresses the disadvan
`tages of the CGI. Servlets are modules written in the highly
`portable JAVATM programming language as they run in the
`same virtual JAVA machine, which is independent of the
`processor hardware or the operating system. In the objected
`oriented Java programming language, the HTTP requests are
`parsed and made to interact with software objects modeled on
`the real objects that operate with the application. Similarly,
`the responses are made to conform with the HTTP protocol
`before being sent to the requester. Servlets runs in a multi
`tread environment in the Java server and allows each request
`to be handled by a separate tread. Also one instance of the Java
`Scripts need be loaded into the processor memory as com
`pared to CGI where contemporaneous requests require mul
`tiple copies of the CGI scripts to be loaded. The original
`servlets conform to the HTTP protocol and may be regarded
`as “HTTP servlets”. The servlet model provides a set of API
`(Application Programming Interface) that is implemented by
`loading a corresponding servlet container in the application
`server. The servlet model enables developers to rapidly
`develop applications and to port them to different servers and
`be able to run them efficiently. It is widely used in web
`applications and is based on open standards.
`0023 The API is an abstraction that describes an interface
`for the interaction with a set of functions used by the compo
`nents. It is a list containing the description of a set of functions
`that is included in a library and that address a specific prob
`lem. In the current context of Java object oriented languages,
`it comprises a description of a set of Java class definitions and
`extension class definitions with a set of behaviors associated
`with the classes. The API can be conceived as the totality of all
`the methods publicly exposed by the classes (the class inter
`face). This means that the API prescribes the methods by
`which one handles the objects derived from the class defini
`tions.
`0024 For call control, a SIP servlet has been developed
`and established as a standard to handle requests under the SIP
`protocol, just as the HTTP servlet handles requests under the
`HTTP protocol.
`0025 FIG. 3A illustrates an existing implementation of
`the call control objects of the server-side components of the
`communication application shown FIG. 1 being implemented
`as SIP servlets. The call control objects are in the form of SIP
`servlets 320. This is possible through the implementation of a
`SIP servlet container 340 and a SIP servlet call control API
`350.
`(0026. The SIP Servlet Specification (JSR 289) is a con
`tainer based approach (modeled on the HTTP servlet para
`digm) to developing communication applications utilizing
`the Session Initiation Protocol (SIP) protocol. A SIP servlet is
`a Java programming language server-side component that
`perform SIP signaling. SIP servlets are managed by a SIP
`servlet container, which typically is part of a SIP-enabled
`application server. SIP servlets interact with clients by
`responding to incoming SIP requests and returning corre
`
`Ex. 1008
`CISCO SYSTEMS, INC. / Page 22 of 35
`
`

`

`US 2012/001 6932 A1
`
`Jan. 19, 2012
`
`sponding SIP responses. SIP servlets are built of the generic
`servlet API provided by the Java Servlet Specification which
`is established as an open standard by the Java Community
`Process (SM) Program through the Java Specification
`Request (JSR) process.
`0027. Using a SIP servlet (JSR 289) for call control is to
`leverage the benefits of the servlet model. It also provides a
`Java API independent of underlying media server control
`protocols.
`0028 U.S. Pat. No. 7,865,607 B2 discloses a servlet
`model for media rich applications. The SIP servlet for call
`control is augmented by a media control API. However, the
`media control API is custom and does not conform to the
`servlet model.
`0029. For media control, media control objects are being
`supported by a standards-based media control API, JSR 309
`as shown in FIG.3A. Thus, media server specifics are handled
`by a JSR 309 Driver, allowing an application developer to
`program using the JSR 309 API, independent of the media
`server vendor. In this way, the applications can work with
`different media servers that are deployed by different opera
`tors and service providers.
`0030 Thus, an application developer can develop compo
`nents of a communication application in terms of low level
`call control objects and API in the form of a SIP Servlet based
`on the open standards JSR 289 and interms of low level media
`control objects and API in the form of the open standards JSR
`309.
`0031 One disadvantage of working with low level and
`generic objects and their APIs is that the developer has to
`repeatedly deal with low level details even if many of these
`details are irrelevant when the object being modeled is in
`certain states.
`0032 FIG. 3B illustrates how the existing implementation
`of the application has to deal with every event under the
`standard call control and media control API shown in FIG.
`3A. For example, the SIP servlet receives a BYE request to
`end a call. It examines what state it is in to act according. In
`the case when it is still in a “CONNECTED' state, it will call
`the doBYE method to end the connection and perform related
`call teardown and cleanup tasks. However, a user may decide
`to hang up a call even before the call connection is estab
`lished. In that case, it is not even in the “CONNECTED' state
`and therefore given the state, there was no need for the servlet
`to receive the BYE request and to perform any call teardown
`tasks. Nevertheless, in the current implementation, every time
`the BYE request is received, the servlet will have to check
`against its state and act accordingly. Thus, the added burden
`of checking and dealing with irrelevant requests becomes part
`of the application code. The same is true for the media events
`and the application has to furnish the logic and additional
`codes to deal with events which may not be applicable to the
`Current State.
`0033. It is desirable for an application to be developed
`without having to deal with details irrelevant to the object
`model being dealt with. Furthermore, it is desirable to have a
`systematic and uniform way of working with call control and
`media control events, without having to deal with their low
`level details in the application so as to have Succinct and
`efficient codes.
`0034 FIG. 1 shows a server architecture in which the
`Script processing or Scripting is performed by the server that
`is also executing the resultant execution codes. The scripting
`
`is language- and protocol-specific, such as for example, pro
`cessing a script written in the Java or JavaScript language.
`0035 However, increasingly users and application devel
`opers are using other light-weight protocols and languages to
`code the application scripts. These include Ruby, Python,
`Groovy and PHP. With a growing range of languages and
`protocols, it is difficult for a hosting facility to provide com
`patible browsers for each of the possible programming lan
`guages and protocols.
`0036) Even if a large number of browsers is supported, the
`resultant execution codes from these different browsers will
`all run in the same Java virtual machine of the application
`server. Without a standard protocol to the unified API, the
`different Scripts running in the same virtual machine may
`contend with each other, resulting in poor performance,
`memory leaks and, worst still, object collisions. Also, having
`to Support a wide set of possible scripts make resource pro
`visioning and budgeting in the communication platform dif
`ficult and indefinite.
`0037 Thus, there is a need to provide a more flexible
`arrangement for telephony services and communication
`application deployment to be driven by scripts coded with a
`variety of user-preferred programming languages and proto
`cols without the above-mentioned disadvantages.
`
`SUMMARY AND OBJECTS OF THE
`INVENTION
`0038 According to a general aspect of the invention, a
`communication application server is provided with a unified
`framework for call control and media control. The framework
`Supports a unified API having class objects and functions
`conforming to a telephony object model. The class objects are
`invoked and manipulated by a finite set of commands and an
`application program essentially issues a series of Such com
`mands to operate the communication application server.
`More particularly, an API server on the communication appli
`cat