FIELD OF INVENTION

This invention relates to data communications in general and to WebRTC data communications in particular.

INTRODUCTION

WebRTC (Web Real Time Communications) is an emerging technology that integrates into a browser the capability for secure real time voice, video and data communications between browsers including web browsers and other devices implementing an appropriate set of real time protocols. WebRTC has the potential to have a significant impact on modes of communication, particularly in the customer-to-business space - for example between customers and customer contact centres. Customer contact centres are staffed by customer support agents who traditionally are able to interact with customers via voice or video calls. In the near future customers will be able to engage directly with a business through the use of a WebRTC communications channel. A WebRTC communications channel between the browsers of a customer and a customer support agent will enable improved interaction such as high definition voice and video, screen sharing, shared and synchronised browsing etc. When fully implemented, WebRTC effectively turns a web browser into multimedia endpoint, e.g. capable of handling voice and video calls. The term "voice call" is used in the following to indicate a voice call or a video call. WebRTC is defined in detail in "WebRTC 1 .0: Real-time Communication Between Browsers", W3C Working Draft 10 February 2015, the World Wide Web Consortium (http://www.w3.org/TR/webrtc/).

In order to support WebRTC voice calls, the customer contact centre will need to be able to accept the new WebRTC signalling and media and route the signalling and media appropriately to an available agent. To achieve this level of interaction requires that existing customer contact centres are upgraded to support this new communications capability. However, it is likely that evolution of customer contact centres to WebRTC will be gradual due to the costs in upgrading existing infrastructure. Many equipment vendors are starting to ship WebRTC Gateways that interwork WebRTC voice communications with existing Internet telephony (or VoIP) and Plain Old Telephone Service (or PSTN) based services. Figure 1 shows a communications system incorporating such a WebRTC Gateway 1 10, which enables a customer using a WebRTC capable web browser (e.g. running on customer terminal 1 12) to set up a voice call (1 14, 1 16) to a business location (e.g. customer contact centre 124) using legacy voice technology. As shown in Figure 1 , this creates an opportunity for a customer contact centre using legacy (e.g. PSTN or VoIP) voice technology to provide voice-based support to a customer using the voice-call capabilities of a WebPtTC-capable web browser, without any changes to the customer contact centre. As shown in Figure 1 , a business sets up a website (somebusiness.com) on a web server 120 to provide information on-demand to customers of the business. For example, the business website may support a customer support web application jointly running in the customer and customer support agent browsers. Customers are able to access information provided on pages of the website from a browser running on a suitable networked terminal 1 12, such as a computer with internet access. The business also sets up a customer contact centre 124 comprising one or more customer support agent workstations 130 (each workstation, for example, comprising a conventional telephone 126 and a networked terminal 128). The customer contact centre 124 provides vocal assistance and advice to customers, especially customers who are facing problems and who have not been able to find a solution on the business website.

In Figure 1 , a voice channel (1 14, 1 16) is established between a customer terminal 1 12 and a customer support agent conventional telephone 126 or softphone running on networked terminal 128 via a WebRTC Gateway 1 10. The customer terminal 1 12 runs a WebRTC capable web browser. The voice channel is established over a WebRTC link between the WebRTC capable web browser 1 12 and the WebRTC Gateway 1 10. The voice channel is established over a PSTN or Session Initiation Protocol (SIP)/VolP link 1 16 between the WebRTC Gateway 1 10 and the customer support agent telephone 126 or softphone 128. That is, voice communications from the WebRTC-enabled web browser are converted to legacy voice technologies (e.g. PSTN or VoIP) by the WebRTC Gateway and then routed to the customer contact centre over a conventional voice channel. Similarly, voice communications from the customer support agent terminal are converted to WebRTC technologies by the WebRTC Gateway and then routed to the customer WebRTC-enabled web browser. Voice connection may be established between other customer support agents and other customers over end-to-end conventional links 1 18.

A drawback with the communications system of Figure 1 is that it does not provide support for a direct data channel between agent and customer browsers. US 2014/0126708 describes at a relatively high level, how WebRTC communications can be integrated into a customer contact centre, with appropriate routing to WebRTC capable customer support agents. It describes an out-of-band application server for facilitating non-voice and non- video communications between two browsers that are both WebRTC enabled.

STATEMENT OF INVENTION

A method is provided of establishing a data communications channel between a first communications terminal device and a second communications terminal device; in which the first communications terminal device and second communications terminal device are connected via a voice or video communications connection; in which the voice or video communications connection comprises a WebRTC voice or video channel to the first communications terminal device and a non-WebRTC voice or video channel to the second communications terminal device; in which the WebRTC voice or video channel and the non- WebRTC voice or video channel are connected for voice or video communication. The method providing, via the voice or video communications connection, to the first communications terminal device a token identifying the second communications terminal device (or vice versa) and using the token in establishing a data communications channel between the first communications terminal device and the second communications terminal device.

According to an embodiment of the invention, the data communications channel is established directly between the first and second communications devices.

According to an embodiment of the invention, the WebRTC voice or video channel and the non-WebRTC voice or video channel are connected for voice or video communication via a WebRTC gateway.

According to further embodiments of the invention, the token may be provided vocally or provided by signalling.

According to further embodiments of the invention, the non-WebRTC voice channel comprises at least one of a SIP, VoIP and PSTN voice channel.

According to further embodiments of the invention, the data communications channel is a WebRTC data communications channel.

According to further embodiments of the invention, the data communications channel does not pass through the server.

A server is also provided for establishing a data communications channel between a first communications terminal device and a second communications terminal device; in which the first communications terminal device and second communications terminal device are connected via a voice or video communications connection; in which the voice or video communications connection comprises a WebRTC voice or video channel to the first communications terminal device and a non-WebRTC voice or video channel to the second communications terminal device; in which the WebRTC voice or video channel and the non- WebRTC voice or video channel are connected for voice or video communication. The server for providing, via the voice or video communications connection, to the first communications terminal device a token identifying the second communications terminal device (or vice versa) and using the token in establishing a data communications channel between the first communications terminal device and the second communications terminal device.

According to an embodiment of the invention, the server comprises:

an identity manager configured in use to provide a token for a voice or video communications connection;

a session management web server configured in use to manage registration of communications terminal devices;

a session database configured in use to holds details of active voice or video communications connections;

and a signalling server configured in use to manage data channel signalling with the first communications terminal device and the second communications terminal device to set up a data channel between the first communications terminal device and the second communications terminal device.

According to an embodiment of the invention, the processor is configured in use to receive via the voice or video communications connection, from the first communications terminal device, the token identifying the first communications terminal device.

According to an embodiment of the invention, the processor is configured in use to receive via the voice or video communications connection, from the second communications terminal device, in combination, the token identifying the first communications terminal device and a token identifying the second communications terminal device. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows schematic representation of aspects of a communications system;

Figure 2 shows schematic representations of aspects of a communications system according to embodiments of the present invention;

Figures 3, 4, 5 and 6 show sequences of actions according to embodiments of the present invention;

Figure 7 shows a block diagram of a computing device according to an embodiment of the present invention;

DESCRIPTION OF EMBODIMENTS

According to some embodiments of the invention, a customer identifier is presented to a customer support agent workstation so that the agent can initiate a data channel session with the customer. According to further embodiments of the invention, an agent identifier is presented to a customer terminal so that the customer can initiate a data channel session with the agent. In more detail, a server is provided which facilitates but does not carry data communications between a WebRTC capable browser and a legacy system such as a customer contact centre that uses PSTN or SIP/VolP voice communications. The server provides a mechanism for a WebRTC based caller easily to be identified by a customer contact centre agent and allows the agent to initiate a direct browser-to-browser data communication session - thus enhancing customer-to-agent interaction.

Figure 2, introduces a Data Channel Management Server (DCMS) 220. Features which are common to Figures 1 and 2 are given the same reference numerals and will not be described further here. DCMS 220 may comprise a computer system or a plurality of computer systems as shown in Figure 7. The DCMS 220 facilitates browser discovery and acts as a signalling intermediary between browsers. According to embodiments of the invention, the DCMS 220 provides a mechanism for notifying one or more active voice calls in an agent web browser: so allowing the agent easily to identify, e.g. from a list or view displayed in the browser, details of a customer that they are currently talking to. According to embodiments of the invention, the agent is able to establish a WebRTC data session with the customer by simply selecting a button or link from a list displayed to them.

The DCMS 220 may comprise a standalone component and could be hosted by a third party that may be supporting customer contact centres of many different organisations. According to embodiments of the invention, when DCMS 220 is integrated with a WebRTC gateway, an improved user experience may be achieved.

A WebRTC gateway will typically have an API for management and a further API for session control. The WebRTC gateway session control API provides a means for a web page to set up and tear down voice calls and data communications. The WebRTC Gateway management API 215 to DCMS 220 provides a means for DCMS 220 to manage the WebRTC Gateway, for example, the provisioning of user accounts and identities. It is through the management API 215 that the WebRTC Gateway will be able to interact with DCMS 220 to define or retrieve a presentation Calling Line Identity (CLI) associated with a customer-originated WebRTC voice call.

We now describe the invention in more detail with reference to the embodiment of Figure 2. A website (somebusiness.com on web server 120) and a customer contact centre 124- 130 are set up by a business to provide information and support to its customers (not shown). The customer contact centre is staffed by customer support agents (not shown) who can interact with customers via voice calls. Customers are also able to access information provided on the website pages from a browser running on a terminal 1 12. Customers are able to set up, from a browser, a voice call with a customer support agent via the customer contact centre. Customer terminal 1 12 is equipped with a WebRTC capable web browser that enables the customer to make voice calls using WebRTC.

As shown in Figure 2, the DCMS 220 comprises four main components: an identity manager (IDM) 222, a session management web server (SMWS) 224, a session database (SDB) 226 and a signalling server (SS) 228. Session management web server 224 manages registration of customers and agents via registration flow 230 (with customer terminal 1 12) and via registration flow 232 (with customer contact centre 124-130). Signalling server 228 manages data channel signalling via flow 234 (with customer terminal 1 12) and via flow 236 (with customer contact centre 124-130) to set up data channel 240 between customer and agent web browsers. We now describe the components of DCMS 220 in more detail. DCMS 220 may comprise a computer system as shown in Figure 7 or a plurality of computer systems as shown in Figure 7. Moreover, each component of DCMS 220 may comprise a computer system as shown in Figure 7 or a plurality of computer systems as shown in Figure 7.

The session management web server (SMWS) 224 provides a Session Management API that will be used in building a view of the somebusiness.com website for the customer client and a view of the same website for the agent client. The SMWS API could take many forms such as HyperText Markup Language (HTML) or Representational State Transfer, (REST) based. The SMWS 224 may also provide HTML based "widgets" that could be embedded directly into the somebusiness.com business website, for example for the display of pending call session tokens to agents.

A SMWS customer client API provides methods for both registration and deregistration of the customer client with the SMWS and for generation by the identity manager of a unique token for identifying the subsequent voice call session. The SMWS customer client API registration method is called by a web application running in the customer browser when the customer initiates a WebRTC voice call from the browser. The SMWS customer client API registration method will associate within the DCMS, a token (e.g. a voice call session token) with the customer client. The call session token may be supplied by the SMWS or alternatively, if the customer is logged in the website, the customer website login identity may be used. In another embodiment, the registration method will return one or more sets of credentials (including a username and password) which may be used by the customer client to authenticate with the WebRTC gateway and with the signalling server (228) prior to initiating a voice call. A SMWS customer client API deregistration method (described in more detail, below) may be called by the web application running in the customer browser when the WebRTC call is terminated. The SMWS customer client API deregistration method deregisters a customer web browsing session and releases any associated identity token. Subsequent voice calls placed during the same web browsing session will require a new registration, thus generating and registering a new voice call session token.

A SMWS agent client API supports the registration and deregistration of an agent (e.g. using an agent identity token) with the SMWS. The SMWS agent client API retrieves a list of active voice calls together with voice call session tokens that can be handled by the agent. The SMWS agent client API provides to the agent terminal a list or view of active voice calls. The agent web browser will display these active calls in the agent web page view. The agent web page may provide means to sort, filter or search this list of active voice calls to make it easier to locate a particular call session token. From the list or view, an agent is able to select a button or link to initiate a WebRTC data session with the customer that they are currently sharing a voice call. According to a further embodiment, it can be arranged that agent token used in the SMWS 224 is included in the call signalling between the agent and the customer browser e.g. a presentation CLI, SIP URI or custom SIP header. The customer browser may use this agent token as its call session token, thus providing a one-to-one mapping between the customer and agent in the SMWS. For example, where the customer client does not register a voice call session until after the voice call has been established, the customer client may register using an agent CLI or unique identifier present in the signalling from the WebRTC gateway associated with the established voice call. The DCMS now has a one-to-one mapping between the customer and agent - thus removing the requirement for the agent to visually search a list of active calls in order to identify the customer. The list may, for example, be replaced by a button to establish a data channel. This is described in more detail, below, with reference to figure 5.

Where requested by the SMWS 224, the identity manager 222 provides a unique token for identifying a voice call session. Once a voice call session is terminated, the allocated token may be returned to the identity manager 222 for reallocation. According to a further embodiment, the identity manager 222 is able to obtain or determine, as described below, the presentation CLI that the WebRTC gateway has constructed for a voice call (i.e. the CLI of the customer endpoint as seen by the agent) and is able to use all or part of this CLI as the voice call session token. This allows the agent to tie the CLI displayed in the agent telephone terminal or softphone to that in a list of active calls in an agent web browser. A number of ways exist in which the CLI can be acquired, for example the WebRTC Gateway may provide a simple Gateway Management API 215 through which the presentation CLI for a particular call session can be determined by the identity manager. According to a further example, the signalling messages generated by the WebRTC Gateway towards the customer contact centre may be routed through the identity manager 222 so that identity manager 222 can extract the CLI directly from the signalling without modification of the signalling.

The session database 226 holds details of active customer calls and their state. When SMWS customer client API registration method is called, a new entry will be created in the database containing the voice call session token. The new entry may also contain a timestamp and a domain and context token to identify the website domain (or organisation) and a context (or page) within the website. The domain and context tokens allow the system to support multiple organisations' websites. The voice call session status will initially be set to "pending" until a WebRTC data session has been established between a customer and agent, when it will change to "active'. The agent token will be undefined until either the agent initiates data channel setup or the agent token is supplied in the customer registration. A customer- or agent-initiated call termination will cause the session database entry to be removed, for example by calling the SMWS customer client API deregistration method. A timestamp may be used to facilitate searching for call sessions by an agent as well as for housekeeping i.e. deleting old sessions that for some reason haven't been removed. Table 1 shows an illustration of possible session database contents, with each row containing details of one call.

Table 1

The signalling server provides an API through which the customer and agent terminals are able to exchange WebRTC data channel signalling messages between their respective web browsers. The signalling server API provides a mechanism for each browser to specify the call session token or agent token associated with each data channel signalling flow 234, 236. The signalling server will route messages between the customer and agents browsers based on these registered tokens using the routing information (i.e. mapping between call session token and agent token) held in the session database. Both the customer and agent browsers will create a signalling flow to the signalling server. At the point where a customer initiates a WebRTC voice call to the business, the web client running in the customer browser sets up a data channel signalling flow 234 with the signalling server 228. The voice call session token is passed to signalling server 228 as part of the setup of data channel signalling flow 234. The signalling server 228 will use this voice call session token to identify the data channel connection to the customer browser, once established. The agent browser will set up a data channel signalling flow 236 with the signalling server 228. The agent token is passed to signalling server 228 as part of the setup of data channel signalling flow 236. The data channel signalling flows could be set up over HTTP using HTML Server Sent Events for example or, alternatively, using WebSockets. The signalling server API may be very simple, e.g. the API could determine that the very first piece of information received via the data channel signalling flow is an identifier specifying whether the end point is a customer or agent, together with the relevant call session or agent token.

Operation will now be described, by way of example, with reference to the flow diagrams of Figures 3, 4, 5 and 6.

Figure 3 shows download of a web application to the customer terminal. At 310, the customer uses their browser to "surf" the business web site. Customer browser sends to business website a Request Web Content message 312. Business website responds with web content 314 and a web application is downloaded into the customer browser.

Figure 4 shows high-level message flows for data channel establishment using a call session token. Referring to Figures 2 and 4, the agent browser sets up 416 a data channel signalling flow 236 between itself and the DCMS 220 signalling server 228 to assist in data channel signalling. This normally happens when an agent starts working and will be closed at the end of the shift. At some time during the agent's shift, the customer decides to call the customer contact centre using a web application running on the customer terminal 1 12. At 418 the customer selects a "contact us" button or link on a web page displayed by the web application running in the customer browser. When the "contact us" button or link is selected, the web application registers with SMWS 224 (420 Request / Register Identity Token, 422 Return Identity Token). If the customer identity is known to the web application, the customer identity may be supplied as the call session token to the SMWS 224 as part of this registration. Alternatively, if no customer identity is available, the DCMS 220 will return a unique call session token to the browser. A unique call session token is requested from the identity manager 222, if required. The customer browser may display (424) on the web page, the call session token registered with the DCMS 220. The call session token is used to identify the customer data channel signalling flow 234 for routing of messages. The customer support agent is able to view and search, via a browser on a local terminal 128, a list or view of active calls from customers to customer contact centre 124. The list of active calls may be accessible through one of a direct web interface and a web API (such as the SMWS agent client API) that can be integrated into a customer support web portal provided by the DCMS 220. On detecting change in call session state, the DCMS 220 may push (426) updates to the agent browser. Once registered with the DCMS 220, the customer browser initiates (428) a WebRTC voice call to the customer contact centre via a WebRTC gateway 1 10. The customer identifier (or username) may be passed along with the signalling and used as the call session token. WebRTC Gateway forwards (430) the call to the agent's phone 126, 128. At 432, the agent answers the incoming call and a response 434, 436 is provided to the customer browser via the WebRTC Gateway. The voice call 438 is now established.

Once the token has been returned at 422, the customer browser sets up (440) a data channel signalling flow 234 between itself and signalling server 228 to support data channel signalling. The call session token is passed to the signalling server 228, as part of this data channel signalling flow set up, for use in message routing. The call session details are stored in the DCMS session database 226 at this point. Together with the data channel signalling flow 236, set up between the agent browser and the DCMS 220 signalling server 228, an end-to-end data channel signalling flow is established between the browsers.

During the voice call, the customer support agent decides that a data session should be set up to the customer browser, for example, to allow sharing of the agent's screen or shared web browsing. According to embodiments, this is achieved using the customer call session token. Where the voice call is based on a VoIP infrastructure, then the call session token can be provided to the customer support agent through the initial call signalling (428, 430). Where the agent phone is an analogue device with caller display, the call session token can be arranged to be a genuine PSTN CLI, which can be displayed to the customer support agent on the phone display. Otherwise, the customer support agent can ask the customer to read out their call session token, as displayed in the customer browser screen. Once the customer support agent knows the call session token, the agent searches the list of calls displayed in the agent browser for an entry indicating the same call session token. When an entry indicating the correct call session token is found, the agent selects (442) an on- screen link associated with the token. Selection of the link initiates data channel signalling (444, 446), including a data channel invite, between customer and agent browsers over the previously set up data channel signalling flow 234, 236 via DCMS signalling server 228. The initial invite message 444 contains the tokens of both the agent and the customer, between whom the data channel 240 is to be established. The signalling server 228 updates the customer record in the session database 226 with the agent token before propagating 446 the invite message to the customer browser using the data channel signalling flow 234. At 448, the customer (or the web application in the customer browser, on behalf of the customer) accepts the data channel invite. The acceptance of the data channel invite is propagated (450) back to the customer support agent browser via DCMS signalling server 228. On receiving the answer message, the signalling server 228 looks up the call session token in the session database 226 to retrieve the associated agent token in order to forward the answer message 452 back to the appropriate agent at the customer contact centre, via the data channel signalling flow 236. In an alternative implementation, the customer and agent tokens are one and the same - thus removing the need for database lookups. Data channel 240 between the two browsers is then established. In this way, a direct WebRTC data session is established between the two browsers.

The data channel 240 provides a direct means of exchanging data between web browsers. The customer support web application may make use of this data exchange capability, for example, to facilitate shared browsing. In a shared browsing experience, the URL that both peers are viewing may be exchanged via the data channel and this could be followed by scrolling information as one peer scrolls the page so that the other peer's browser can then track the scrolling so as to view the same content.

On receiving the answer message 452, the agent browser initiates WebRTC out-of-band signalling exchange to establish 454 the data communications channel 240 in a new WebRTC channel between customer and agent browsers: this is separate from the channel established between the web browser and the WebRTC Gateway for the voice call. For example, the agent browser sends an invite (containing a Session Description Protocol (SDP) message) and the customer browser then responds with its own (SDP) session information. The two browsers then work out how to reach each other using Internet Connectivity Establishment (ICE) based on the information in the other browser's SDP messages. Data channel set up is complete, once a path is determined through which each browser can reach the other browser. The standard WebRTC out-of-band signalling exchange is specified by the World Wide Web Consortium (see the earlier reference).

As indicated, above, embodiments provide a mechanism for establishing, on the basis of a call between a customer and an agent, a mapping between the call and a data session between the customer and the agent. According to further embodiments, the call may be anonymous (i.e. not associated with a caller identity). To achieve a suitable mapping, an identifier for the customer is established that either the agent or the DCMS 220 can use to link a first communication channel associated with the voice call with a second communication channel associated with the browsing session. According to embodiments, there are a number of distinct ways that this can be achieved by the DCMS 220:

1 . When a customer initiates a voice call to an agent, a unique token generated by DCMS 220 is displayed in the customer web browser. DCMS 220 also provides a list of active calls to the agent, e.g. for display on a terminal accessible to the agent. Each call in the list is linked to one of the unique tokens generated by the DCMS 220. During the voice call to the agent, the customer reads out to the agent the unique token provided by the DCMS 220. The agent then uses the token to select the appropriate call from a list of active calls presented on the agent terminal and initiates 442, as described above, an outbound WebRTC data session with the customer browser.

2. As (1 ) but the customer is logged into a business website and so the unique call session token is the customer user name, which is passed in registration flows, described earlier.

3. Where a call from a customer to an agent is associated with a calling line identity (CLI), the CLI will be presented to the agent at their endpoint (e.g. analogue or mobile phone, VoIP phone, soft client, etc.) in the normal way. According to this embodiment, the CLI is used by the DCMS 220 as a unique token. The WebRTC Gateway monitors calls received from customers and directed to the customer contact centre. Where a call is associated with a CLI, the WebRTC Gateway reports this to the DCMS 220. As described, above, the DCMS 220 provides a list of active calls received by the call centre to the agent terminal but now the identifier associated with each call is that call CLI. On receiving the call, the agent looks up the CLI as presented on their endpoint, selects the appropriate call from a list of active calls presented on the agent terminal (i.e. the active call associated the CLI) and initiates 442, as described above, a WebRTC data session with the customer browser.

4. The customer contact centre software is configured such that a unique identifier for the agent is present in the signalling 434, 526 provided towards the WebRTC gateway. This unique identifier could take the form of a presentation CLI or, in the case of SIP signalling, a SIP URI or a custom header in the SIP signalling. The DCMS session database 226 maintains details of the agent in an account and has a record of the agent unique identifier. Once a voice call between customer and agent is established, the identity of the agent will be known to the customer browser by virtue of the call signalling 436, 528 from the WebRTC gateway 1 10. The call session is registered by the DCMS 220 against the agent token. Instead of providing, on the agent terminal, a list of all active calls received by the call centre, the DCMS 220 need only provide details of the current call between the agent and the customer. As there is only one active call in the list, the agent simply selects this call. As an alternative, the call list may be replaced by a button or link that the agent can select in order to establish a WebRTC data session with the appropriate customer browser.

Figure 5 shows an alternative channel set up, using an agent CLI or token. Flows 516 to 518 in Figure 5 are equivalent to flows 416 and 418 in Figure 4. Flows 520 to 530 in Figure 5 are equivalent to flows 428 to 438 in Figure 4, except that the call initiation signalling 520, 522 of Figure 5 is not relied on to provide the call session token. Unlike the flow illustrated in Figure 4, in Figure 5 registration of the customer browser with DCMS 220 - see register request with CLI (532) and response with token (534) - only occurs once the initial audio call (530) has been established. Registration results in the setting up (536) between the web client running in the customer browser and the signalling server 228 a data channel signalling flow 234 with call session token. In this way, the CLI or token for the agent can be registered with the DCMS 220 by the customer browser. Data channel signalling flow 236 between the agent browser and the signalling server 228 has previously been set up (416). SMWS 224 can then push an update (538) directly to the agent web browser with a link that identifies the customer and will be used to establish the data channel. The link may be a URL containing the call session token or it could simply be the call session token. The agent web browser will provide a link or a button on the page which when clicked will either make a HTTP request to the URL or invoke an API method passing the call session token (depending upon what type of API is provided by the signalling server 228 e.g. REST or JavaScript). Once in possession of the call session token, the customer support agent can initiate 540, by selecting the link, setting up (552) of data channel 240, from their browser. The setting up of the data channel is achieved using flows 540 to 550, which are equivalent to flows 442 to 452 in Figure 4.

As noted, above, when a WebRTC data session is terminated, it is important that the data session state held in DCMS 220 is cleared: a process referred to as "deregistering". Figure 6 shows three alternative data channel signalling flows for deregistering with the DCMS 220: one customer initiated, two agent initiated. Customer-initiated call termination is initiated (610) by the customer selecting a call termination option in the customer web browser. The web browser will close its end of the data channel by using the appropriate WebRTC API method within the browser and then will send a deregister request 612 as part of data channel signalling flow to the SMWS 224, which instructs 613 the signalling server 228 to send a command 614 to the agent browser to terminate the data channel between agent and customer browsers - again by calling the appropriate WebRTC API method. The SMWS may push changes in the active call list or the agent browser may periodically request an update of the list of active calls 616. The two types of agent termination are data channel termination and call termination. To terminate the voice call session, the customer browser issues a "hang-up" command 618 to the WebRTC Gateway, which forwards the command to the agent phone.

In the first alternative data channel signalling flow, data channel termination is initiated by the agent selecting (630) a data channel termination option in the agent web browser. The web browser sends a terminate data channel request 632 to the signalling server 228, which sends a command 634 to the customer browser to terminate the data channel between agent and customer browsers. The data channel is closed in both browsers by using the WebRTC API as described previously. Changes to the active call list are delivered (636) to the agent browser as described above in 616. With agent-initiated data channel termination, the call is intentionally kept active 638 to allow continued voice communication. In the second alternative data channel signalling flow, data channel termination is initiated by the agent ending the call in the soft client or phone 640. This initiates the delivery of a "hang up" message 642 to the WebRTC Gateway 1 10, which in turn sends a "hang up" message 644 to the customer browser. On receipt of "hang up" message 644, the customer browser will tear down the data channel and send a deregister message 646 to the SMWS 244 causing the session to be removed from the DCMS. Finally, terminate data channel messages 647 and 648 instruct the agent browser that the data channel has been closed. Changes to the active call list are delivered (650) to the agent browser as described above (with reference to 616).

Figure 7 shows a computer system 70 in accordance with the disclosed embodiments. Computer system 70 may correspond to an apparatus that includes a processor 710, memory 712, storage 714, user interface 717 and communications interface 718 and/or other components found in electronic computing devices. Computer system 70 may also include input/output devices (not shown) such as a keyboard, a pointing device and a display communicating with processor 710 via user interface module 717. Computer system 70 may also, via communications interface module 718 (which may comprise a plurality of network interfaces), be connected to or have the capability for connection to one or more communications network, such as a wired, wireless or hybrid LAN, WAN or internet (for example internet 120 of Figure 1 ).

The invention is not limited to the examples provided, above, relating to a customer browser and a customer support agent browser. References above to a customer browser apply equally to any first browser and references above to a customer support agent browser apply equally to any second browser where the first and the second browsers are each associated with a communications terminal device and the associated communications terminal devices are connected via a voice or video communications connection.