Computer Communications 34 (2011) 140–149

Contents lists available at ScienceDirect

Computer Communications

journal homepage: www.elsevier .com/ locate/comcom

Defining a call control interface for browser-based integrations usingrepresentational state transfer

Keith Griffin a,*, Colin Flanagan b

a Cisco, Oranmore Business Park, Oranmore, Co. Galway, Irelandb University of Limerick, Limerick, Ireland

a r t i c l e i n f o

Article history:Received 2 November 2009Received in revised form 23 March 2010Accepted 26 March 2010Available online 2 April 2010

Keywords:Open API designRESTCall controlInterfaceBrowser

0140-3664/$ - see front matter � 2010 Elsevier B.V. Adoi:10.1016/j.comcom.2010.03.029

* Corresponding author. Tel.: +353 87 650 4145.E-mail addresses: kegriffi@cisco.com (K. G

(C. Flanagan).

a b s t r a c t

While integrating telephony call control signaling into a desktop application is not a new concept, theemergence of web browser-based applications drives the need for feature parity between desktop andbrowser-based telephony call control applications. Desktop call control applications typically have theadvantage of being able to use local protocol stacks or API libraries. A browser-based application doesnot have the same capabilities by default, especially when running on a constrained device. Traditionaltelephony call control APIs and architectures do not currently lend themselves for use with web brow-ser-based applications without requiring some form of download which is not desirable. Is it possibleto design a call control interface that can be consumed in browser-based applications natively withoutrequiring additional downloads? Representational State Transfer (REST) is a resource oriented architec-tural style which, when used with HTTP as a uniform interface offers the possibility to use an existingdefined set of interfaces to manipulate state transitions for resources. We propose that the REST architec-tural style can be used with an identified interface design methodology to define an interface for tele-phony call control capable of being consumed by browser-based applications. Furthermore by utilizingexisting industry standards as an example, we suggest that existing standards can be extended to supportbrowser-based integrations using REST.

� 2010 Elsevier B.V. All rights reserved.

1. Introduction

The ability to program communications services in IP telephonyenvironments introduced new possibilities for integration systems[1]. It became possible to programmatically access communicationservices which allowed third party developers to invoke thefunctionality exposed via published interfaces on a communicationsystem. A third party developer is any developer outside of theorganization that developed the communication system and istypically interested in using or extending the functionality of thesystem within their application. In turn this allowed users of com-munication systems greater flexibility in their usage of the system.Enterprise telephony systems have been prevalent in business usesince the 1970s [2]. Using the PBX as being representative ofenterprise communication systems which have evolved throughIP telephony to Unified Communications [3–6] it can be seen thatthe provision of telephony call control interfaces such as MicrosoftTAPI, Novell TSAPI, CT-Connect and Sun’s Java Telephony API [7–10]can be used by a third party software developer to offer functional-

ll rights reserved.

riffin), colin.flanagan@ul.ie

ity not offered natively by the communication systems itself. Anexample of a third party communication integration via publishedsystem interfaces is the provision of click to call services within adesktop application. Any third party developer can use publishedcall control interfaces from a unified communications system to en-able telephony call control within an application. The benefit to theuser is that they can control incoming and outgoing calls from with-in their application rather than using the phone device directly. Insome cases unified communications vendors have implementedtheir own integrations based on their own open interfaces demon-strating that the same open interfaces can be used natively in addi-tion to third party use [11,12]. Cleary these interfaces and theapplications and feature extensions that they offer have value, how-ever the interfaces are predominantly aimed at desktop clientapplications where a local protocol stack or other local componentcan be assumed. What if integration with a web browser-basedapplication is required? Furthermore, what if the browser-basedapplication is running on a constrained device? While a browser-based application running on a computer desktop might have theresources available to work-around a given interface by supportinga local protocol stack or other downloaded component, the samecannot be assumed for a browser-based application running on aconstrained device. Representational State Transfer (REST) [13], is

K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149 141

a hybrid architectural style for distributed hypermedia systemswhich uses a constrained interface to manipulate the state of anygiven resource. In this paper, we propose that the principles of aREST based system can be used to define a telephony call controlinterface suitable for consumption in browser-based communica-tion integrations. Furthermore, we propose that this interface canbe used without requiring any other local client software compo-nent other than a HTTP capable browser. Additionally, we identifyand apply a methodology suitable for the design of such interfaces.

The paper is organised as follows. First, we present the neces-sary background and state of the art describing the problem do-main of telephony call control in browser-based integrations. Weintroduce the principles of REST in the background section. Next,we look at the interface design by reviewing an existing telephonycall control standard and outlining a methodology for REST basedinterface design, before applying this methodology to define ourproposed interface. After presenting the proposed interface design,we evaluate the interface by applying a common call control usecase. Finally, we conclude by providing the reader with an over-view of our findings and outline future work.

2. Background

2.1. Enterprise telephony call control

Computer Telephony Integration (CTI) is based on the exchangeof messages between computer and telephony systems. It is not anew concept, with implementations in the industry available sincethe 1980s. It is however an important concept in the enterprisecommunications environment and continues to be a commonlyused technology in modern deployments. While CTI covers a broadrange of specific integrations this research considers desktop basedcall control as it can be related to browser-based call control. Inthis context, CTI refers to the signalling associated with the call,hence the term call control. CTI does not imply control of the mediaassociated with the call such as the voice path or the media termi-nation of the voice-path. Later, we will define a representative sub-set of call control functionality which will be used to test theassertion that call control interfaces can be defined for use withina browser-based application. While introducing telephony integra-tion in a browser-based environment using REST is a new para-digm it does not change the features of a telephony system.Therefore, rather than creating yet another CTI interface, we iden-tify an established and accepted industry standard as a basis forthe interface design. The standard chosen is Computer SupportedTelecommunications Applications (CSTA) which is an acceptedand current industry standard [14]. CSTA defines interfaces relatedto all aspects of enterprise telephony including an interface called‘‘Call Control Services and Events”. CSTA is chosen as an example ofan independent, well formed and progressive interface. Indepen-dent, as the standard is driven by open working groups withoutsingle vendor influence. Well formed, as the standard has beenthrough three major phases of revision and progressive as the stan-dard continues to evolve and considers new forms of interface pre-sentation such as SIP-CSTA [15].

2.2. Browser-based communication integration

Having introduced the concept of a communications integrationsystem it is necessary to focus on one particular consumer of com-munication integration system interfaces which are not wellserved by current interface implementations, namely browser-based web clients. Call control CTI clients are typically installedwith all the required run-time software components to facilitatebi-directional communication between the client and server in

real-time. A study of the third party CTI client implementationspreviously identified showed that remote procedure call (RPC)[16] and remote method invocation (RMI) [17] between the clientand server are common approaches. While these approaches ap-pear to work well for installed desktop clients, a different approachbeyond the current state of the art is required for browser-basedweb clients on constrained devices. Technically it would be possi-ble to take a client side component such as a protocol stack andembed it in a web client in the form of a once off or infrequentdownload. Depending on the size and nature of the download thismay or may not be acceptable for browser-based deployment. Sev-eral factors may influence the acceptability of a component down-load ranging from IT policy to performance to security. Technicalfactors include the basic ability of a device to accept a componentdownload or handle client side call control processing. For the pur-pose of this research we introduced a technical constraint. The con-straint is that no client side download will be permitted apart fromthe browser itself. In addition to this constraint, no extensions tothe browser or browser plug-in component may be used. It is in-tended that by placing this constraint on the research that the out-put will be applicable to a range of scenarios for fixed and mobilecomputing where only a web browser is available to consume acommunications integration interface such as CTI call control. Ithas been shown that automated call handling and user settingscan be addressed via REST [18] but these synchronous operationsbased on user and device settings differ from real-time communi-cation interfaces as in the case of telephony call control. Also, somecommunications integration interface definitions like CSTA, havebeen extended to offer SOAP based Web Services [19]. While suchan approach is widely accepted for desktop browser-based envi-ronments it will break the constraint outlined above as it would in-volve the download of the Web Service Definition Language(WSDL) and/or the use of a local SOAP stack in the browser-basedclient application or as a plug into the browser. In order to workwithin our constraint the browser-based communication integra-tion mechanism chosen must work within the constraints of thebrowser itself. A safe way to do this is to work strictly within theconstraints of the standards that a web browser implements, inparticular HTTP [20], thus extending the reach of telephony callcontrol systems to clients that cannot be addressed currently.

2.3. An introduction to representational state transfer

Representational State Transfer or REST as it has become com-monly known, is a hybrid architectural style for distributed hyper-media systems. It is not dependent upon any particular protocolbut typically uses HTTP. This means that it is possible to create aREST based system that is not built upon HTTP; however, mostpractical implementations of REST are built using HTTP. REST isnot a standard however it does prescribe the use of standards,including but not limited to HTTP, URI, XML and HTML.

2.3.1. REST design principlesThe following are design principles of a REST based system.

� Stateless: Every request from client to server must contain allthe information required to execute the request and must notrely on information known to the server.� Uniform interface to support state transfer consisting of:� A constrained set of well defined operations e.g. the HTTP

methods GET, PUT, POST, DELETE.� A constrained set of content types e.g. text/xml, image/jpeg.� Client server pull interaction: consuming clients pull

representations.� Uniquely Named Resources: A URI is used to name the

resources which comprise the system [21].

142 K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149

� Layered, interconnected resource representations: resource rep-resentations are interconnected using URLs [22] enabling a cli-ent to progress through states.� Cacheable responses to promote network efficiency.

An important principle of REST is that of resources. A resource isa source of specific information which is named by a URI. Re-sources are manipulated by network components using a uniforminterface e.g. HTTP. Resulting state changes for the resource are re-turned as representations such as XML document. As REST inter-faces are by definition highly connected via URI, deeply linkedrepresentations are typically used over wide or shallow represen-tations. This means that a representation returns specifically thedata that it represents but is tightly linked to related data that anapplication might be interested in.

2.3.2. REST architectural considerationsFig. 1 shows an architecture for client – server communications

based on REST. It can be seen that the uniform interface is pre-sented by HTTP and the resource representations are shared overthis interface. The REST aware client code shown is typically partof a web page that is loaded from a web server. JavaScript is com-monly used as a client side language embedded in HTML to invokethe interface and manipulate resources. Where data is returned itis parsed and acted upon by this client side code based on the logicof the application. Later we will see how the interface is definedwith operations from the uniform interface (HTTP) and with re-sources represented as URIs. The architecture also shows how sev-eral underlying standards such as HTTP, URL, HTML and XML canbe used to support a REST based architecture.

Among the advantages of REST are the possibilities for browser-based application development as the use of HTTP for the uniforminterface prescribed by REST constrains the interface and relatedcode in the browser-based application. Other documented advan-tages include scalability enabled by a stateless model and resourceextensibility allowing for new interface definitions and content

REST Aware ClientCode

HTTP MetGET, POST, PUT

REST PayRepresentation w

HTTP Respo

REST XML Retu

HTTPClient

Fig. 1. REST based architecture for

Fig. 2. Make ca

types to be introduced without impacting existing interfaces andcontent types. The disadvantages of REST include the synchronousnature of HTTP as the uniform interface and the potential for theinterface namespace to become cumbersome as additional inter-faces and types are added.

3. Interface design

3.1. Telephony interface design

Before designing the interface it is necessary to first understandthe underlying CSTA operational model. The CSTA domain containsswitching, computing and special resource sub-domains separatedby the CSTA service boundary. Call control is contained in theswitching domain which provides a switching function that is anabstraction which allows third party applications to control and/or observe calls on devices (phones). CSTA allows for complexmodelling of devices with logical and appearance elements. Thisis necessary to cater for telephony systems which have featuressuch as multiple appearance directory numbers. This feature al-lows an appearance of a directory number to be presented on mul-tiple individual devices resulting in a call to that directory numberbeing offered to multiple devices at the same time. For the purposeof introduction to the CSTA operational model we begin with asimple call model in which a device has a single logical line asso-ciation but later expand to a more complex model. A simple callis defined as an established call between two devices shown inFig. 2 which is adapted from the CSTA specification. It is possible,as we will show later, to use the CSTA definition to create complexcall models involving well defined state transitions as shown inFig. 3. However, the simple call model involves a small numberof well recognised call states and is useful for introductory pur-poses. It is the call control commands and related call states whichform the underlying CSTA object model [23] that we focus on inorder to design a call control interface using REST. The before andafter states for the makecall service are shown in Fig. 2. The

REST Aware ServerCode

hod, DELETE

loadith URI’s

nse

rn Data

HTTPServer

client–server communication.

ll service.

Fig. 3. CSTA connection state transitions.

K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149 143

scenario shown assumes device 1 (D1) and device 2 (D2) to be inan initial null state. After a successful make call service the deviceswill be connected via a call (C1) with each device having a state ofconnected (‘C’). The connection logically represents the call.

CSTA services such as makecall and answercall are defined to beavailable in a number of styles including XML and SOAP Based WebServices [19]. Currently no definition based on REST exists, in factaccording to the literature no definition of a REST based telephonyinterface exists for any published or standard telephony interface.

3.2. Designing RESTful web services

There are several commonly known approaches to interface de-sign [24]. For RPC and service style interfaces a known design tech-nique is to break a set of system requirements into actionsidentified by verbs. Using a call control example this techniquewould suggest methods such as makecall and answercall shouldbe created. In object oriented design a known technique is to breaka set of system requirements into objects identified by nouns. Anobject is a thing and each noun gets its own class [25]. Again usingan example of a call control system consisting of phones with mul-tiple lines on which calls can be made and answered, an object ori-ented approach identifies the nouns in the requirements as theobjects in the system. Therefore system, line and call objects shouldbe created. In a resource oriented design a resource is a thing and asimilar object oriented technique can be applied as a starting point.In an object oriented design a class can expose any number ofmethods and name each method as desired. However as previouslydiscussed a constrained, uniform interface will be used to definethe methods for a RESTful web service. The term RESTful is useddescribe any service or interface that adheres to the design princi-ples of REST. When it appears that an additional method is re-quired, new kinds of resources must be defined to implement therequired functionality. In a resource oriented analysis all resourcemanipulation occurs through resources that conform to the uni-form resource.

3.2.1. Methodology to design a REST based interfaceIn a REST based system the interface primarily consists of the

resources and the uniform interface. The uniform interface is de-fined by HTTP, however the specific allowed HTTP methods mustbe chosen for each resource. A procedure was found which canbe used to resolve a given problem domain by creating resources

in a RESTFul resource oriented design [26]. The procedure whichbecomes our methodology is described as follows:

� Determine the dataset.� Split the dataset into resources.� For each resource type:

j Name the resources with URIs.j Expose a subset of the uniform interface.j Design the representations accepted by the client.j Design the representations served to the client.j Integrate into existing resources.� Determine normal operation flow.� Determine error/ exception flow.

The dataset consists of the elements of data that the service willexpose to clients or that clients will contribute to building. If a ser-vice is being exposed from an existing or legacy system the datasetis already defined. If it is a new service the dataset must be deter-mined. This involves analysing the problem domain and gatheringall possible data together for consideration. To split the datasetinto resources take any data interesting enough to be referencedby a hyperlink or by name and give it its own a resource name. Re-sources exposed by web services can be placed in three categories.

1. Predefined individual application specific resources. Most ser-vices provide few or none of this type of resource. An exampleof this type of resource is a top level directory which exposeslists of other resources.

2. Resources representing every object in a service. A service canexpose numerous objects, each with its individual resourceset. Most services expose a large number of this type ofresources. In theory a service can expose an infinite amountof this type of resource.

3. Resources representing results of a process. This type ofresource returns the result of a process or algorithm. A goodexample of this is a query service.

Resources are named as URIs. The URI should contain all scop-ing information relating to the resource. Web Service resourcesshould have a root hostname from which a path to further re-sources is defined. From the root the resources are defined. TheURI style can be defined as desired but some guidelines are usefulfor the creation of consistent, readable interfaces. Path variablesare suggested to denote hierarchy e.g./parent/child. Punctuationcharacters in path variables are suggested to avoid implying hier-archy where one does not exist e.g. a parent resource with twochild elements should be represented as parent/child1;child2rather than parent/child1/child2 which implies a hierarchy be-tween the child elements. Query variables are suggested to implyinputs to an algorithm or process e.g./search?q=cycling offers aquery parameter cycling to a search resource. The actions suitablefor each resource must be determined by choosing the methodsof the uniform interface which will be allowed for each resource.It is possible to determine appropriate actions for resources byusing simple design rules. In the case of read only resources HTTPGET and DELETE are appropriate. POST and PUT can be used whereresources are required to be updated and created. Deciding whatdata can be returned to a client and what format that data willuse such as plain text, XML or JSON amounts can be thought ofas passing a parameter. The representation describes the state ofthe resource and also links to related resource to allow an applica-tion to navigate through the required application states. Similarlythe representations served by the server to the client must bedecided. This also requires the data and the format of the data tobe determined. Once the interface methods and data representa-tions have been decided, resources should be linked to each other

Table 1Telephony commands events considered.

Telephony command Telephony event

Make call Call initiated/completedAnswercall Call answeredDropcall Call clearedHoldcall Call heldUnholdcall Call retrievedConferencecall Conference call initiated/completedTransfercall Transfer call initiated/completed

Table 2CSTA mandatory make call parameters.

Parameter name Parameter description

callingDevice Specifies the calling/originating device. Note thatthis device may be a device that represents a groupof devices. In this case the callingDevice in theservice request is different from the actual callingdevice

calledDirectoryNumber Specifies the called device

Table 3Naming resources with URI’s.

Resource URI Definition

/system/device/deviceID Capabilities of device identified by deviceID/system/device/deviceID/

callCall on device identified by deviceID

/system/call/CallID Capabilities of call identified by callID/system/call/CallID/device Device associated with call identified by callID

144 K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149

where it makes sense. This is true for both new and existing re-sources. Once resources are linked, a client can request a represen-tation of a resource which will link to subsequent resourcesallowing the application to navigate through various states. Finallythe normal operation flow can be determined which involves acombination of the previous steps. Effectively this involves deter-mining that the methods, representation and associated headersrequested by the client and representation and headers returnedfrom the server are as the interface designer expected. Severalknown exception or error conditions between the client and servermay occur. The interface must be equipped to allow an applicationto handle such cases. The standard HTTP response codes provide amechanism to inform an application of these conditions. Supple-mentary or application specific error codes may be added to theHTTP headers or the associated entity-body if one exists.

This section described a methodology to design RESTful re-source oriented services which are stateless, addressable and con-nected. It is believed that the methodology described in thissection can be used to successfully design RESTful web servicesthat follow the constraints of a resource oriented architecture. Thismethodology will be tested by applying it to the design of a RESTfulpresence web service in the following section.

3.3. Defining a telephony interface using REST

Having outlined a RESTful web service design methodology itwill now be applied to a telephony call control interface. Theresulting RESTful telephony web service design will be evaluatedlater according to the constraints of a resource oriented architec-ture. The interface features considered were those that would pro-vide a user with the typical features that consist a desktoptelephony application. The interface features allow for a simple callas previously discussed but also extend to more advanced desktoptelephony features such as consultative transfer and conference asshown in Table 1.

3.3.1. Determining the datasetFollowing the previously described methodology to define a

RESTful web service, the first action we must take is to determinethe dataset. The dataset consists of the elements of data that theservice will expose to clients. As we are using the previously de-fined CSTA telephony standard the dataset already exists. Fromanalysing the CSTA operational and object models it is clear thatthe interface will use parameters to identify and describe devicesand calls which are connected via a logical connection. The manda-tory parameters required by CSTA for a make call scenario areshown in Table 2.

3.3.2. Splitting the data set into resourcesTo split the dataset into resources any data interesting enough

to be referenced by a hyperlink or by name is given its own a re-source name. The resources in our simplified data set are devicesand calls. The call is logically modelled in CSTA by a connection.The device resource represents all devices in the system, individu-ally identified by a unique identifier and the call resource repre-

sents every call on a device, individually identified by a uniqueidentifier. A device can have state dependant capabilities such asthe ability to receive a call if the device state is null. A device canalso have calls although in our model we restrict it to a single call.A call can have capabilities such as the ability to be disconnected(return to null) if the call is in any other state other than null.

3.3.3. Resource specific interface definitionFor each resource we will name the resources with URI’s, ex-

pose a subset of the uniform interface, design the representationsaccepted by the client and design the representations served tothe client as outlined in the methodology.

3.3.3.1. Name the resources with URI’s. As query parameters are notrequired and the hierarchy between device and call is defined, pathvariables are used to name the resources as shown in Table 3.

3.3.3.2. Expose a subset of the uniform interface. The functionality re-quired to establish a call is the ability to make a call, answer a calland drop (disconnect). To make a call from a device two ap-proaches are possible. A new call resource could be created forthe device in which case a HTTP POST method can be used to posta new resource. Alternatively, an existing call resource for a devicecan exist in which case a HTTP PUT method can be used to updatethe state of the existing call resource to reflect a new call. It mayseem invalid to have a call resource linked to a device resourcewhen there is no call, however this approach is valid and may bepreferred in some integrations where the cost of a simple state up-date is less than that of posting and linking a new resource everytime a call is created. When there is no call the resource is simplyset to a state of null according to the CSTA operational model. Thesame logic can be applied to answering a call. A similar argumentcan be made for disconnecting a call. Should the call state be setback to null to reflect the disconnected call or should the entire callresource be deleted using HTTP DELETE? Again the state updateapproach is valid for disconnecting a call for the same reasons out-lined above. Maintaining the resource after the call is disconnectedhas secondary advantages such as providing call history for call de-tail records however it introduces a housekeeping overhead as dis-connected calls would accumulate on the system using thisapproach. For this reason DELETE is also available as an alternativewhere call history can be tracked by a separate module as is cur-rently the case on communication integration systems. At any gi-ven point it may be necessary to query a device or call for itscapabilities in this case a HTTP GET can be used. A summary ofthe chosen subset of the uniform interface is shown in Table 4.

Table 4Uniform interface methods.

Telephony call control action HTTP method

Make a call POST (PUT)Answer a call PUT (POST)Drop a call PUT (DELETE)Hold/unhold PUTConsult PUTConference PUTTransfer PUTGet call capabilities/state GET

Fig. 4. XML make call response representation served to a client.

Fig. 5. Sample incoming call representation served to client.

K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149 145

3.3.3.3. Design the representations accepted from the client. Repre-sentations accepted from the client include what in a service or ac-tion oriented interface would be a functional parameter. In atelephony interface this would typically include the originationand destination address for a phone call. CSTA already definesthese parameters using an XML data representation in ECMA-323[27]. This standard XML definition has already proven to have mul-tiple uses including the SOAP based web services defined in thepreviously referenced ECMA-348 and ECMA-TR/87. From analyzingthe existing specified parameters it has been found that some ofthe parameter definitions in ECMA-323 can be reused as the re-quired representations accepted from the client for the purposesof defining this interface. Specifically in the CSTA simple call modelthe parameters that must be considered are shown in Table 5.

In the simple call model there is just one call between two de-vices but more advanced features such as a conference and transfercall introduce multiple simultaneous calls between devices. As asystem assigned unique identifier for each call, callID is used to dif-ferentiate calls on a device represented by deviceID. The Connectionrepresentation is interesting. During the interface design it is theconnection state combined with the HTTP method which manipu-lates the state of the resource. For simple call transitions theECMA-323 CSTA XML definitions were found to be adequate, how-ever for more complex call transitions it was necessary to designnew connection states for consult, transfer, conference and hold.This may appear to be a deviation from CSTA but it is actually anadherence to the design principles of REST. If CSTA state operationssuch as singleStepTransfer are used it amounts to an instruction oraction in the message body. In REST terms this is known as an over-loaded POST operation as the only instruction should be in the uni-form interface (HTTP method).

3.3.3.4. Design the representations served to the client. Representa-tions served to the client consist of synchronous and asynchronoustelephony events in response to previously generated requests.Synchronous responses consist of responses to associated solicited

Table 5CSTA simple call parameters as XML representations.

CSTA parameter Description

Called directory number <calledDirectoryNumber>[calledDirectoryNumber]

</calledDirectoryNumber>Connection <connection>

[ConnectionState]</connection>

Call ID <callID>[CallID]

</calllID>Device ID <deviceID>

[DeviceID]</deviceID>

Calling device <callingDevice>[CallingDevice]

</callingDevice>

requests. An example of a CSTA XML make call response is shownin Fig. 4 which would be received by a client in response to a pre-vious request. This is an example of a suggested response to a pre-vious HTTP PUT request to update the state of a device to initiate acall.

While looking at a simple call model, asynchronous events areminimized to an incoming call alert. However when we extendthe model to include a call hold event it provides an example ofan asynchronous mid-call event in the case where a user pressesthe hold button on the physical phone device during an active callresulting in an asynchronous held event being sent to the browser-based client. According to CSTA an incoming call alert will be re-ceived by a client in the form of a delivered event. The deliveredevent will contain all relevant information relating to the incomingcall. A simplified delivered event is shown in Fig. 5.

The incoming call notification alert contains representations forthe resources involved in the incoming call. The call identifier andcalling device are all represented in the delivered event. Anotherrepresentation served to the client is the established event. This issent to the client associated with the calling device after the callhas been established (answered). The established event is notshown here as it is similar in format to the delivered event.

3.3.3.5. Determine normal operation flow. The normal operationflow must be taken into account for each combination of interfaceoperations. Considering the case of making a call it can be seenhow the normal operation flow occurs through the use of the uni-form interface to manipulate the state of the resources. Referringback to Fig. 2 we can see that the normal operation flow is for de-vice (D1) to initiate a call (C1) to device (D2). Using our RESTful APIas defined, to follow the normal operation flow results in a HTTPPUT to update the resource state of D1 to initiated. This results ina state update to D2 of alerting. If the user at D2 selects to answerthe alerting call it will result in a HTTP PUT from D2 to set its stateto connected resulting in an established call. Normal operation mes-sages are equally important to an application as error messages.Standard HTTP status codes should be used to report normal oper-ation and also for exception flow. For normal operation the 1xx–3xx HTTP status codes combined with positive CSTA XML messagebodies from the communications integration system form the basisof the normal operation flow. Fig. 4 shows an example of a HTTP

Table 6A sample of HTTP error codes relating to the RESTful telephony interface.

HTTP status code Description

403 Forbidden A given valid request was refused. The reason is (optionally) contained in the entity body. This can be used to enforce telephonysystem rules such as refusing to allow an application to delete a resource (such as another users device or calls)

405 Method not allowed The client has attempted an operation that is not allowed on a given resource. This is used to enforce feature capabilities. Forexample, a client would get a 405 if it attempted to place a call on hold if call hold is not feature supported in the given devicesconfiguration

408 Request timeout The client did not produce a request within the time that the server expected. This is especially important for the RESTful telephonyinterface, particularly with advanced features. Features that consist of multiple requests must have the requests made withinspecific timeout values. These vary and are set by the communications system

409 Conflict The request could not be completed due to a conflict with the current state of the resource. For example if a request is made to put acall on hold when it is already on hold the client will be informed of a state conflict

410 Gone The requested resource is no longer available. For example, this can occur when an operation is requested on a call but the otherparty in the call has disconnected

501 Not implemented The server does not support the request method and is not capable of supporting it for any resource503 Service unavailable The server is unable to handle the request from the client. This may be due overloading on the server. A retry-after time period may

be provided

Fig. 6. Sample HTTP error message.

146 K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149

201 Created status message which indicates to an application thatthe PUT operation it invoked to create a new resource (in this casea call) has been successful. Moreover, this simplified exampleshows the location header which contains the URI of the new callresource.

3.3.3.6. Determineerror/exception flow. As described in the previoussection, standard HTTP error codes should be used when error orexception conditions are encountered. The HTTP 4xx–5xx statuscodes relate to client and server error conditions respectively. Asour new RESTful telephony interface uses HTTP, all HTTP errorcodes are valid and should be handled by an application howeverthe following list of status codes have been particularly useful fortelephony error handling. Examples of these are shown in Table6 however it should be noted that this is just a sample that specif-ically relates to telephony and basic HTTP error codes such as 404Not Found and 500 Internal Server Error have not been added here inthe interest of brevity.

An example of a HTTP 409 Conflict error message is shown inFig. 6. A scenario leading to this error could be a browser-basedapplication attempting to put a call in a particular state e.g. on holdwhere the call is already in that (held) state.

4. Evaluation

From the interface design it is clear that the design methodol-ogy can be used to define a telephony call control interface accord-ing to the principles of REST. To evaluate the usefulness of theinterface which has been defined, the interface is applied to theuse case of a browser-based click to call scenario which ultimatelyresults in a consultative call transfer as shown in Fig. 7.

For this scenario we use a device (D1) with a phone number of091384622 calls a device (D2) with a phone number of 061202622,both are represented by browser-based communication clients.After an established connection, the first device consults and thentransfers the call to device (D3) with a phone number of051377475. The interface flow is shown in Fig. 8.

The flow of commands and events in this example of an end-to-end consultative transfer call demonstrates that it is possible to de-

fine an interface using the design principles of REST for use withinbrowser-based call control applications. This call flow is chosen asit models more than just a simple call. Moreover this call flow re-quires the interface to handle state transitions across multiple callsand devices. While it is not documented here the interface has alsobeen used to model single step and consultative conference alongwith other features. First a call is placed between the initial partiesusing a HTTP POST. This is acknowledged with a HTTP 201 Createdstatus code and message body. The CSTA events related to the callprogress are shown using XML data representations of the CSTAevents between both parties. Step seven in the call flow shows thatat some point after the initial call has been established between D1and D2, the second party (202622) initiates a consult call to an-other party D3. Again the HTTP methods and CSTA XML entitiesare used to manipulate the state of the resources which resultsin a successful call transfer before the call is disconnected. Ofcourse if error conditions are encountered they are handled as pre-viously described in Table 6 with normal operation flow being as-sisted by standard HTTP status codes with embedded CSTA XMLdata representations from the communication integration system.Notice also how the CSTA call model which assigns a new call ID toeach new call has been maintained showing how REST can be usedto support the underlying CSTA call identifier model withoutredefinition. This interface is capable of being consumed by abrowser-based client without requiring any form of download tothe browser or application and relies only on HTTP as a protocoland XML for data representations. Referring back to the CSTA statemodel in Fig. 3 it can be seen that a connected call can be put onhold but an alerting call cannot be put on hold. By querying callcapabilities a user can be informed of the options available to themat that point of the call. An improvement on the current RESTfulinterface definition would be to use the deeply linked nature ofREST to include link to a call capabilities resource. For synchronousoperations such as making a telephone call, creating an interfaceabstraction using REST is relatively straightforward, resources areidentified, resources are named with URI’s, a subset of the uniforminterface is chosen, server and client side representations aredesigned and finally normal operation and error flows are defined.However in real-time enterprise communication systems asyn-chronous events are a core and mandatory feature. A simple exam-ple of an asynchronous event is an inbound telephone call. While ithas been shown that it is possible to reuse a subset of the XMLevents defined in CSTA, a REST based system typically relies onHTTP as the underlying transport, indeed that is the case with thisinterface. This presents a challenge for a REST based communica-tions integration architecture. It has already been established bythe authors that long polling techniques such as the bayeux proto-col [28] and emerging standards such as the websockets protocol

Fig. 7. Consultative call transfer use case.

Browser Client 1 Device D1 384622

Browser Client 2 Device D2 202622

CSTA based Communication

System

Device D3377475

POST /system/device/384622/call<calledDirectoryNumber>

202622</calledDirectoryNumber>

201 Created Location: http://system/call/55<MakeCallResponse>

<callID> 55 </callID> <deviceID> 384622 </deviceID>

</callingDevice> </MakeCallResponse>

200 OK<DeliveredEvent> <connection> <callID>55</callID> <deviceID>202622</deviceID>

</connection> <callingDevice> <deviceID>384622</deviceID>

</callingDevice> </DeliveredEvent>

200 OK<EstablishedEvent> <connection> <callID>55</callID> <deviceID>384622</deviceID>

</connection> <answeringDevice> <deviceID>202622 </deviceID>

</answeringDevice> </EstablishedEvent>

PUT /system/device/202622/call<connection>

<callID>55</callID> <LocalConnectionState>

Connected </LocalConnectionState>

</connection>

PUT /system/device/202622/call<connection><callID>55</callID> <consult>consult</consult><deviceID>377475</deviceID>

</connection>

200 OK<DeliveredEvent> <transferredCall> <callID>57</callID> <deviceID>377475</deviceID>

</transferredCall></DeliveredEvent>

200 OK<consultationCall> <existingCall><callID>55</callID> <deviceID>202622</deviceID>

</existingCall><initiatedCall><callID>56</callID> <deviceID>377475</deviceID>

</initiatedCall></consultationCall>

Delivered Event

PUT /system/device/202622/call<connection><callID>55</callID> <transfer>transfer</transfer><deviceID>377475</deviceID>

</connection>

200 OK<ConnectionClearedEvent> <droppedConnection> <callID>57</callID> <deviceID>377475</deviceID>

</droppedConnection> <releasingDevice> <deviceID>384622</deviceID>

</releasingDevice> </ConnectionClearedEvent>

PUT /system/device/384622/call<connection>

<callID>57</callID> <LocalConnectionState> Null

</LocalConnectionState ></connection>

Transferred Call

200 OK

200 OK ConnectionCleared

1

23

4

6

7

8

5

9

10

1112

1415

13

Fig. 8. REST telephony interface call flow.

K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149 147

148 K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149

[29] combined with server-sent events [30] offer mechanisms tosupport asynchronous events from the web server on a communi-cations integration system to a browser-based client. Based onpractical testing and a level of industry acceptance suitable tech-niques have previously been validated by the authors as appropri-ate to support asynchronous real-time events in browser-basedapplications [31].

In a practical implementation HTML containing JavaScript istypically used to implement the application content and logic withCSS being used to style the application. In addition to the XML datarepresentations already defined by CSTA it is suggested that Java-Script Object Notation (JSON) [32] data representations should alsobe defined. Furthermore they should be defined with a one to onemapping between both representation formats in order to allowapplications to interchange formats as desired. Apart from the ben-efit of offering a choice of representations to developers JSON ap-pears to be less verbose than XML due to its smaller grammar. Itis suggested that this could offer performance benefits in real-timecommunication systems but would require further analysis andtesting in a practical implementation to be realized. It is ironic thatwe call for JSON data representations to be added to the existingCSTA representations as JSON is based on a subset of the JavaScriptprogramming language (also known as ECMAScript) [33] which isstandardised by the ECMA, the same group that standardised CSTA.

The separation of the uniquely named call-control resources(URI’s) from a constrained, uniform interface (HTTP) which is usedto manipulate the state of the resources allows for this interface tobe used in a resource oriented architecture, in line with the designprinciples of REST. Every request from the client to the server con-tains all of the information required to execute the request anddoes not rely on information known to the server, making this astateless interface in which clients pull representations from theserver. For this to be effective in a telephony call control interfacethe interface state model must support all state transitions effec-tively as instructions. The current CSTA state model contains com-prehensive events for call transfer and some of the currentlydefined underlying XML representations can be reused, howeverthe current model does not support a rich enough set of state tran-sitions in its current form and the state model shown in Fig. 3would need to be expanded to cater for REST based approachwhich uses state transitions to control the call. For example inthe consultative transfer call we see the application using HTTPPUT to put the call with callID 55 first in a consult state in stepsix and then to a transfer state in step ten. This is understandableas the CSTA model was not originally designed with REST or re-source orientation in mind. Moreover, these suggested modifica-tions would apply equally to current service oriented call controlinterfaces and not just CSTA. The introduction of these new non-instructional states into the CSTA model makes the state modelsuitable for RESTful interface definition. Currently no ubiquitoussolution exists to extend enterprise communication integrationsystem interfaces to browser-based clients where no additionaldownloaded component is required. In fact most are legacy CTI cli-ents with installed desktop components requiring RPC connectionsover TCP/IP to specific individual servers. The combination of theproposed RESTful interface along with the ability to handle syn-chronous and asynchronous events over HTTP shows how CSTA,as a representative telephony call control interface can be ex-tended to browser-based clients, including constrained devices.

5. Conclusions

The loose coupling between interface and resources in RESTmakes it suitable for creating interfaces that can be driven by statechanges. It has been possible to define a telephony call control

interface using REST. Combined with the uniform interface ofHTTP, as an almost universally adopted message transport, RESTis a suitable lightweight technology for browser-based call controlintegrations, although it requires a specialized approach in order tohandle asynchronous events to the client. From a deployment andadministrative perspective, the fact that the well known port forHTTP is generally open on enterprise firewalls makes it an accept-able interface technology. The deeply linked nature of REST allowsclient software to request only the resource that is required, whilehaving the flexibility to link to further resources in the system. Thisresults in less client side code and can result in increased networktraffic but again, due to the near universal adoption of HTTP, mostnetworks are tuned for this type of traffic. The use of the CSTAoperational model and reuse of its XML representations was usefuland demonstrates that it is not necessary to define yet another callcontrol model in order to offer RESTful telephony call control.However we also found that for CSTA to offer a resource orientedREST interface modifications are required at least to its state defi-nitions and transitions such as those proposed in this paper. Ingeneral this is true of all known telephony call control interfacesas they are not designed with resource orientation in mind. Inaddition to its suitability for use in browser-based and constrainedclients, the use of HTTP as the uniform interface for REST deliversan additional benefit in that it is not restricted to use in a browserand can of course be used by traditional desktop applications. Withthat in mind and with the potential to use REST to define similarcommunication interfaces for presence [34], instant messagingand user configuration services it is possible to see that RESTfulweb services could be used as a singular interface presentationfor unified communications services to desktop, browser and con-strained clients such as mobile devices.

In this paper we combine the principles of REST with the oper-ational model of the CSTA telephony call control standard andpresent an interface definition suitable for consumption not onlyin browser-based clients, including constrained clients but also inexisting desktop environments. Furthermore, we identify and usean existing methodology to design interfaces using REST. Finally,we propose changes to the CSTA state model that would be re-quired to implement more complex telephony call control inter-faces using REST.

6. Future work

Suggested future work for the interface design includes consid-eration for additional CSTA features. It would also be valuable toconsider the impact of alternative data representation formatssuch as JSON. Additionally, the practical implementation of theinterface in a full resource oriented model along with performanceevaluation of both the server and network under load would bevaluable although not a goal of this current research.

References

[1] J. Rosenberg, J. Lennox, H. Schulzrinne, Programming Internet telephonyservices, Internet Computing, IEEE (1999) 63–72.

[2] J. Kasson, Survey of digital PBX design, IEEE Transactions on Communications(1979) 1118–1124.

[3] B. Bhushan, H. Opderbeck, The evolution of data switching for PBX’s, IEEEJournal on Selected Areas in Communications (1985) 569–573.

[4] J.E. Coffman, Not your father’s PBX?, Queue (2004) 40–47[5] R.M. Milstead, P.S. Warwick, The digital PBX: current and future views of

applications for information management, in: International Conference onPrivate Switching Systems and Networks, 1988.

[6] M.J. Steinmann, Unified communications with SIP, Queue (2007) 50–55.[7] P. Cronin, An introduction to TSAPI and network telephony, Communications

Magazine, IEEE (1996) 48–54.[8] Envox, Envox CT Connect, 2008. Available from: <http://www.envox.com/

software/envox-ct-connect.asp>.

K. Griffin, C. Flanagan / Computer Communications 34 (2011) 140–149 149

[9] Microsoft, Telephony Application Programming Interfaces, 1993, Available from:<http://msdn.microsoft.com/en-us/library/ms734273%28VS.85%29.aspx>.

[10] SunMicrosystems, Java Telephony API (JTAPI), 2002, Available from: <http://java.sun.com/products/jtapi/>.

[11] Cisco, Cisco Unified Communications Widgets – Click to Call, 2008. Availablefrom: <http://www.cisco.com/en/US/prod/collateral/voicesw/ps6882/ps9156/at_a_glance_c45-487474.pdf>.

[12] Nortel, Nortel Unified Communications Desktop for IBM� Lotus� Notes andLotus Sametime�, 2008.

[13] R.T. Fielding, Architectural Styles and the Design of Network-based SoftwareArchitectures, Irvine, University of California, 2000.

[14] ECMA-International, Services for Computer Supported TelecommunicationsApplications (CSTA) Phase III, June 2009, ECMA International.

[15] ECMA-TR/87, Using CSTA for SIP Phone User Agents (uaCSTA), June 2004.Available from: <http://www.ecma-international.org/publications/techreports/E-TR-087.htm>.

[16] DCE-RPC, DCE-RPC 1.1 Technical Standard, 1997. Available from: <http://www.opengroup.org/pubs/catalog/c706.htm>.

[17] Microsystems, S. Remote Method Invocation (RMI), 2006. Available: <http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp>.

[18] K. Griffin, J. Rosenberg, Representational State Transfer (REST) for FeatureConfiguration in Session Initiation Protocol (SIP), 2008. Available from:<http://tools.ietf.org/html/draft-griffin-bliss-rest-00>.

[19] ECMA-348, Web Services Description Language (WSDL) for CSTA Phase III,2009. Available from: <http://www.ecma-international.org/publications/standards/Ecma-348.htm>.

[20] R. Fielding, et al. HTTP – Hypertext Transport Protocol (HTTP 1.1), RFC2616,1999. Available from: <ftp://ftp.isi.edu/in-notes/rfc2616.txt>.

[21] T. Berners-Lee, R. Fielding, L. Masinter, RFC 2396, Uniform Resource Identifiers(URI): Generic Syntax, 1998. Available from: <http://www.ietf.org/rfc/rfc2396.txt>.

[22] T. Berners-Lee, L. Masinter, McCahill M, RFC 1738 Uniform Resource Locators(URL), 1994. Available from: <http://www.ietf.org/rfc/rfc1738.txt>.

[23] ECMA-TR/88, Designing an Object Model for ECMA-269 (CSTA), June 2004.Available from: <http://www.ecma-international.org/publications/techreports/E-TR-088.htm>.

[24] K. Pugh, Interface Oriented Design, 1st ed., The Pragmatic Programmer, 2006.[25] G. Booch, Classes and Objects, in: Object Oriented Analysis and Design,

Addison-Wesley Publishing Company, 1994, pp. 81–144.[26] L. Richardson, S. Ruby, 1st ed., in: M. Loukides (Ed.), RESTful Web Services,

O’Reilly Media Inc., Sebastopol, CA, USA, 2007.[27] ECMA-323, XML Protocol for Computer Supported Telecommunications

Applications (CSTA) Phase III, June 2009. Available from: http://www.ecma-international.org/publications/standards/Ecma-323.htm.

[28] A. Russell, et al. Bayeux Protocol Draft 1.0., 2007. Available from: <http://svn.cometd.com/trunk/bayeux/bayeux.html>.

[29] I. Hickson, The Web Socket protocol, 2009. Available from: <http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44>.

[30] I. Hickson, Server-Sent Events, 2009. Available from: <http://dev.w3.org/html5/eventsource/>.

[31] K. Griffin, C. Flanagan, Evaluation of asynchronous event mechanisms forbrowser-based real-time communication integration, in: CISSE, 2009,University of Bridgeport, Connecticut, USA.

[32] D. Crockford, The Application/Json Media Type for JavaScript Object Notation(JSON), 2006. Available from: <http://www.ietf.org/rfc/rfc4627.txt>.

[33] ECMA-262, S. ECMAScript Language Specification, 2009, December 1999.Available from: <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf>.

[34] K. Griffin, C. Flanagan, Browser based communications integration usingrepresentational state transfer, in: CISSE, 2008, University of Bridgeport,Connecticut, USA.