WEBRTC FOR CONTACT CENTERS

Transcription

1 WHITEPAPER WEBRTC FOR CONTACT CENTERS Solutions with Oracle Communications ABSTRACT This document describes the WebRTC Contact Center solution from Oracle Communications and Quobis, including a complete set of applications and features to help customer care departments and contact centers to take advantage of the new real-time multimedia capabilities of the web domain. 1 I 22

2 SOLUTION ARCHITECTURE The solution is composed of Quobis Sippo family (Click to Call, Web Collaborator and WebRTC Application Controller) and Oracle Communications WebRTC Session Controller (WSC) and can be integrated with existing traditional Contact Center and/or Enterprise Communications and IT infrastructure. The following diagram showcases the general architecture where the Sippo WebRTC Application Controller (or Sippo WAC) deals with the complexity of the WebRTC application management and the Oracle Communications WSC manages real-time signaling and media traffic. Fig. 1 General architecture of interconnection of Sippo WAC and Oracle Communications WSC Solution objectives Add web and mobile app-embedded voice and video channels to existing contact center. Enhance customer experience with contextualized interactions, and collaboration features such as agent chat and co-browsing. Cost savings on aget HW or softphone licensing. Easily and securely support remote agents. 2 I 22

3 SOLUTION FEATURES This section describes the different multimedia capabilities of the joint proposition. Web voice The voice interaction in a web-enabled contact center is typically realized through a Call button added to the customer application interface. Using WSC client SDKs, it is straightforward to embed audio call capabilities into web or native mobile applications. The agent side can be also a WebRTC application (Web-Web call flow) or an existing phone (Web-SIP call flow). In both cases, when there is an existing Contact Center voice infrastructure the audio call is routed from WSC through the existing ACD. Otherwise, in a Web-centric deployment, the Contact Center Web App takes the role of ACD and assigns an agent based on applicationspecific criteria like skills, time-of-day, workload, availability, etc. The solution performs audio transcoding when necessary (typically when Opus codec is used on the web side and call is routed to legacy agent device and G.711 end-to-end usage is not supported or undesirable). Web video The solution supports as well WebRTC video, which can be routed to an agent via existing Contact Center ACD (e.g. a video softphone or WebRTC agent desktop registered via SIP) or directly to WebRTC agent desktop. A media server can be used for video transcoding when needed. Video can be setup one-way or two-way (Amazon Mayday use-case where only agent can be seen, or remote troubleshooting use-case where customer wants to real time video to agent, but agent video is not enabled). An existing audio session can also be upgraded to video, as long as the agent device handling the audio session is video capable. This is the case when both audio and video are routed to a WebRTC-enabled agent device. Fig. 2 Sippo Web Collaborator running on different devices. 3 I 22

4 Chat / IM Chat is a typical feature of a web-enabled Contact Center. Sippo applications implement an instant messaging tool that allows chat and other collaboration features like link detection, icons, image and video in-chat sharing, is typing detection, etc. In addition, the Sippo WAC helps to manage a chat-as-a-service feature, with a tool to assign a specific agent and help this to manage different simultaneous sessions. Usually the Contact Center Web app itself provides the chat feature, without participation of the Oracle Communications WSC, although this element provides a Chat API in its client SDK, which can be used for interworking IM between customer and non-webrtc agent chat applications (using for example SIP SIMPLE or MSRP). The routing of the chat session to an agent must follow the same principles described previously for adding WebRTC video session, making sure the same agent is involved for all channels related to the same interaction with a specific customer. Collaboration features Screen sharing The solution supports WebRTC screen sharing. WebRTC screen sharing is based on capturing the video stream shown to the user (window, browser tab or full desktop) and sending it via a WebRTC PeerConnection. Due to Web security implications, in the current state of WebRTC standardization browser implementations either require enabling specific command-line flags or using a browser plug-in (in Chrome), or getting the web site into a browser whitelist (either via pre-registration with the browser vendor Mozilla or convincing the user to change his browser s whitelist). These limitations make it difficult to deploy WebRTC screen sharing in open web desktop environments; however it can be easier to deploy in environments where the end-user device/browser is under more control (such as Amazon s Mayday). Alternatively, non-webrtc co-browsing techniques can be used to emulate screen sharing on the Web. White board Sippo applications support a shared whiteboard that enables customer and agents to draw and paint together in realtime. This real-time collaboration features is implemented with a DataChannel connection. In addition, the agent can set a background image on the whiteboard such as an invoice or a contract document, where he can highlight the most relevant sections of the document. Form sharing There are different use-cases behind this feature like helping a customer submit a form (e.g. a financial transaction), ask the customer about the quality of the assistance after the call or help agents to get information from the user. In addition, using the WebRTC data channel, customer and agent can fill in a web form together in real time. The information is stored in a database at the Sippo WAC that can be accessible for agents or supervisors, depending on privileges. 4 I 22

5 Internally, the form is HTML and uses DOM Mutation event via Data Channel. Image sharing Quobis Sippo applications support image sharing (including different image formats). Agents can share images that will be shown in the browser of the end customer. This may be combined with the whiteboard feature to share an image of an invoice, x-ray examination or any other document and allow the agent to write on top of it (in order to better explain the contents of the document). Additionally, applications can capture the photo from the customer s own camera and transfer it via data link to the agent. This can be done by adding a send photo button on the customer web site. The agents can then ask the customer to press this button and when pressed, a high quality photo of the customer is taken and automatically sent via data link to agent s screen where agent can store it. File transfer The joint Oracle and Quobis WebRTC solution enables file transfer interactions in a couple of different ways: Quobis WAC itself provides file sharing mechanisms without using signaling and media features provided by WSC. In this case, P2P transfer is not possible and relaying files through the web server is less efficient, but allows the application to provide historic access to shared content or storing content for compliance purposes. WSC SDK provides File Transfer API, which Web Apps can leverage. Two methods are supported: using datachannel or MSRPoverWS. This latter mechanism is important when customers want to be able for their agents to interact with RCS based endpoints. Web-based announcements When a web user requests support via the WebRTC-enabled customer portal or a mobile client application, it is placed in a virtual service queue. Sippo provides a queue management service that dynamically assigns and route incoming WebRTC calls to the appropriate agents or conference room. The customer is kept waiting by playing some form of web-based announcement, which can be: Video-on-hold stream served from a media server involved in the call path. Any web resource (e.g. video served from web server or media server, picture slide show ), managed by client side JavaScript or app UI widget. CDRs and reports It is provided an administration page for the management and reporting that gets the information via an API REST in the WAC. Based on this reporting API, call information is obtained and is represented by graphs and tables filtered by date, campaign and involved agents. There are also specific reports for the campaigns and the agents, for example the conversion rate (number of successful calls). The OCWSC-SE collects data in an event detail record (EDR) for each event that occurs in a subsession for the Call, Chat, and File Transfer packages. 5 I 22

6 Each engine creates event detail records and writes them to a file, oracle.wsc.core.edr, for the sessions that it owns. An event detail record consists of a number of attributes whose values are written to the file, separated by commas. Branding All the Sippo WebRTC applications have full capacity to define ad-hoc colors, logos, user interfaces and user privileges. WUI and service API to manage branding. Languages All the Sippo WebRTC applications are fully available in the following languages: English, Spanish, Portuguese, French and Japanese. Recordings Voice recording (currently) and video recording (future) can be addressed by leveraging Oracle s Session Border Controller (and possibly Oracle s Interactive Session Recorder) in the solution design. A second option can be performed with the WSC via one of our media server partners, like Dialogic or Radisys. Sippo WAC provides the joint integration between Oracle s WSC and the selected media server. Non-WebRTC browser support Microsoft Internet Explorer (IE) provides extremely limited support for WebRTC protocols. For many enterprise customers, however, IE remains integral to their business operations. In order to allow IE to utilize WebRTC functionality, WebRTC Session Controller provides an extension leveraging the near ubiquitous Adobe Flash plug-in. This extension supports IE versions 8 through 11. In addition, the Flash extension will also work with Firefox version 33.1 and above, and Chrome version and above. The reasons to use the Flash mode with Chrome or Firefox are associated with scenarios involving IEto-Firefox or IE-to-Chrome calls. This allows the customer to avoid transcoding between flash and webrtc media format. Browser applications based on our SDK will be able to fallback to flash mode with Firefox or Chrome if they detect that one of the endpoints is IE. Sippo WebRTC applications have been tested with open-source plugins from Temasys to make possible to have the same user experience and interface from non WebRTC-native browsers like Internet Explorer or Safari. This way, users will only need to install the plugin once to access WebRTC applications in a similar way as Google Chrome or Mozilla Firefox. INTEGRATION WITH EXISTING UC AND IT ASSETS This section describes the different options to integration these WebRTC solutions with the existing assets of the contact center. 6 I 22

7 Integration with traditional contact center SIP-based integration When adding WebRTC channels to an existing Contact Center, the most natural route to take is to bridge the WebRTC signaling and media sessions into a VoIP-based Contact Center using SIP and traditional RTP media. The Oracle and Quobis solution can interwork Web to SIP signaling in flexible ways. In practice the following two models can be used in a Contact Center scenario: Web client registration: in this case the WebRTC client is registered in a SIP registrar, which enables call back and other agent-to-customer session initiation scenarios. In the case of web-enabled agents, they will be authenticated along with the web desktop login process. On the other hand, existing customers can be logged in from their WebRTC client/app and thus are assigned a well-known identity for use in signaling, while anonymous users get assigned a dynamic guest id. Web channel as SIP trunk: the solution also supports integrating the web traffic as a SIP trunk into the Contact Center, where no SIP registration is performed (except for agents). In this case, only inbound calls are supported. Web Services based integration In some environments, the existing Contact Center solution does not expose a SIP interface. This is for example the case when the Contact Center trunks are still on TDM infrastructure. However, such Contact Center deployments may expose Web Services interfaces internally, which the Oracle WebRTC solution can leverage. Using WSC s HTTP web service call-out feature or Quobis Sippo connectors, a REST (or SOAP) web service can be invoked as part of the signaling processing logic. In this type of integration, an existing Contact Center web service for creating agent tasks is invoked when the customer clicks-to-call, for example using a specific custom signaling message (using WSC s extensible client SDK) and mapping that to a server-side script in WSC triggering the WS callout. The customer application then informs the user that an agent is being contacted, and may present an estimation of time-to-service (to the end user this appears like waiting on a queue but in fact there is no need to keep a call up consuming resources). Once an agent takes this task, a session setup is triggered from the agent (either directly from the WebRTC agent application or via CTI with existing VoIP devices and infrastructure calling the web user via WSC). The RTC session is finally setup between agent and customer. 7 I 22

8 Fig. 3 Web service based integration. Adding video to legacy voice Contact Center In many deployments, existing Contact Centers support only audio and WebRTC is used to add video, data channel, etc. In these scenarios, there is typically a requirement for keeping the audio call on the same communications infrastructure, including the agent HW phone or softphone, while establishing video and other WebRTC streams towards the agent WebRTC client/app. This requires a mechanism in place to route the separate video session signaling between the same agent s browser or WebRTC App (instead of his legacy phone) and the customer. One option is to leverage existing CTI integration between the web application / agent console and the PBX or CC server, so that the agent has the required context (WebRTC routable customer id related to the ongoing voice call). The Quobis Sippo application includes a specific feature to address this challenge. The application generates a code, shown to the customer in the web page. Agent asks the customer verbally (during the voice call) for this code, which the web application uses to map the customer to the agent. Once agent submits this code to the web app, the agent initiates a video call that gets routed to this customer. Similar mechanisms can be applied when adding other WebRTC-based channels (such as screen sharing), or even other Web collaboration features (such as co-browse, white board or form sharing), and correlating them to an ongoing voice session on legacy comms infrastructure. 8 I 22

9 Fig. 4 Call forking feature that keeps the usage of the existing of the call center platform for audio Analytics and Work Force Management (WFM) As the Web-enabled Contact Center evolves to include WebRTC, additional dimensions are added to optimizations in customer interactions and workforce management. The solution can be integrated with existing CC analytics solution, providing to CC managers and supervisors the same familiar set of metrics for WebRTC voice and video channels as they have with existing CC. Additionally, Quobis Sippo solution provides a reporting API, an interface where reports and stats are available. Currently, the information available via the reporting API ranges from CDR listings, feedback lists for Click to Call scenarios and call s QoS information. WFM solutions integrated with Oracle and Quobis WebRTC solution for Contact Centers should include planning, agent training and scheduling for WebRTC-based customer interactions, such as managing agent skills and CC infrastructure for real time video support using WebRTC application interfaces. Web Centric contact center Most contact centers are willing to add WebRTC-based services as a new channel or extension to their existing platforms. They want to use their ACDs to dispatch calls to agents so then can answer calls from WebRTC click to call buttons and other incoming channels depending on demand and availability. In those scenarios where call center interconnection is not needed, Sippo Web Collaborator, working with the Sippo WAC, can manage a complete WebRTC 9 I 22

10 session. The WAC has tools to assign and dispatch calls to agents, supports different agent policies, call recording, stats and monitoring tools, forms and different multimedia capabilities to make WebRTC a reality for call centers. In addition, for scenarios where media capabilities like call recording, media transcoding, multi-party conference support, interactive video response, video announcements while waiting, etc are needed we ll introduce a specific media server. While media transcoding can be achieved by leveraging the REST API available on the WSC-SE, the remaining scenarios can be addressed by integrating Sippo WAC with the Media Server. This integration is also available using a REST API. Routing When a click to call user makes a call, Sippo WAC implements backend functionality to retrieve an available agent (that is, a callee who is connected and not in a call). This backend functionality receives the list of available agents and the session information, and this will be used to choose the agent. Different algorithms can be implemented to choose the callee (e.g.: roundrobin, first come-first served, etc.). Currently, when a click to call user makes a call to an agent and for those users with agent capability it will fetch last finished calls and last active calls. That agent and call information is submitted to Sippo WAC that will return and agent assignment, if available. On the WSC side, the WSC Signaling Engine can leverage its Lightweight Proxy Registrar feature (LWPR), which allows the endpoints to be registered internally on this platform. Apart from avoiding the need of an external SIP registrar, it also reduces the overall processing cost. Time Control Sippo WAC has a time control feature that detects the time and date and can switch off the click-to-call service or shown a custom message. This a very useful feature to avoid calls to the contact center during non working hours or weekends, preventing customer frustration. Real-time Statistics Quobis Sippo WAC through an API collects information from the different WebRTC applications running on browsers. There are three possible stats types: Call summary and call detail records. Stats submitted periodically during a call from the browsers. The applications provide a complete set of KPIs on QoS (bandwidth, codecs and rate in use, packet loss, etc). Alarms: Alarms are checked every second during a call. An alarm contains values like alarm ID, call ID, stat that generates this alarm and timestamp of this alarm, that can help system administrators to monitor the system. Engagement engine / Proactive calling Sippo Click to Call has been designed to make easier audio or video calls to contact center. Instant messaging is also supported with proactive welcoming messages to invite users to chat. As the Sippo Click to Call button is a WebRTC endpoint, can be used also to receive calls from the contact center. 10 I 22

11 Agents can make proactive calls to web visitors in those scenarios where this type of calls are not intrusive. An example is a notification to the personal agent of the customer when a recurrent user access the website. Sippo Web Collaboration could be used also as endpoint for outgoing call through PSTN for those call centers that are demanding a web client approach to avoid the need of installing anything in the device and to support all type of devices (when agents are using their own devices, teleworkers, etc). Agent availability and Estimated Wait Time Even before a user tries to contact an agent, information about agent availability can be provided on the web page. This information can be retrieved from the WAC directly (in case agents are using also a WebRTC application) or asking the API of the existing customer ACD. Then, while the user is waiting to be served, audio or video will be provided together with the possibility of sharing information about the position in the queue or estimated wait time. This type of information can also be obtained from the Contact Center ACD or from statistics Web Services exposed by the Contact Center, and conveyed to the client app. While the users are waiting they can request a callback if wait is too long. In anonymous calls user is invited to introduce the telephone number Browser detection The WSC SDK is able to seamlessly detect and apply different logic according with the browser being used. This will be transparent for the applications integrating the WSC-SDK, with the exception of scenarios where the Adobe Flash plugin is required. For this latter case, WebRTC applications can use the WSC Flash extension JavaScript function to determine whether WebRTC, Flash, or both are supported by the browser. Additionally, applications will also be able to determine whether a particular Call is Flash-based or not, handling it accordingly. Additionally to the mechanisms provided by the WSC SDK, the Sippo WebRTC Application Controller is also able analyze the HTTP requests received and depending on the browser capacities, adapt the code of the application to work with the WebRTC capacities of the browser. If the browser is not supporting WebRTC and Flash is not an option, the Sippo WAC can invite the user to install a plugin (for Internet Explorer or Safari browsers), to make the application work. It s also possible to show the application (e.g. the click to call button) when the browser is WebRTC-enabled (removing the click-to-call button if this is not going to work). Conveying customer context Context is key to enhancing the customer journey from the web into the Contact Center. The solution provides a multitude of mechanisms to convey and take actions based on customer context, including: Awareness of customer id (if logged in), which agent can use to pull info from CRM. Browsing history (pages or sections visited prior to engaging with agent) & breadcrumbs. Location, language (from web browser or client app). Form data filled prior to WebRTC interaction. 11 I 22

12 Extensible web signaling (JSON) populated by customer App. Customized SIP headers to condition routing of audio session by CC ACD. Ability to call out to IT or CC systems to populate or fetch context (e.g. REST call-out). For example, that information can be easily displayed to an agent using Sippo Web Collaborator in click-to-call use cases, like: Language: browser language or OS language if not specific browser language is configured. Location: URL where the call is issued, the webpage that originates the call. Browser: Browser information: manufacturer and version. IP: External IP of the originator, the public IP, even when the originator is behind a NAT. GeoLocation: Country code / Country name: International country code. Region code / Region name: Identifier of the state or national region. City Zip code Time Zone: Useful to route calls and assign agents. Latitude / Longitude: Geographical coordinates for geolocation. CRM integration CRM provides agents with complete visibility into customer information so they can respond more personally and efficiently to customer inquiries and provide quicker resolution. Sippo WAC exposes a service API and a sort of Sippo Connector to federate with existing CRM solutions and get the information needed to dispatch the call and provide context information to the agent. Quobis offers professional services to build connector with customer CRM and other internal systems, based on customer requirements. Quobis is positioned to deliver WebRTC applications in a very short time-to-market using the existing modules, without dealing with low-level details and focusing on the business application. Integration with customer web applications Sippo Click to Call has been designed to be inserted in existing web sites (like in contact pages of websites of companies). Sippo Click to Call has a small footprint and it s really easy to integrate in websites, intranets, CRMs or any other web application. In addition, banks, insurance companies, etc. have native applications for smartphones. These applications offer different functionalities but lack of a communication layer. Using Sippo and the WSC SDK, it is possible to add audio, video or chat to existing native mobile applications with no need to make great changes in the existing apps. 12 I 22

13 Besides the existing WebRTC applications, Quobis offers professional services to build ad-hoc applications based on customer requirements. By leveraging the existing modules, services and client libraries included in the working and tested code of sippo.js toolkit, Quobis is positioned to deliver WebRTC applications in a very short time-to-market, without dealing with low-level details and focusing on the business application. Campaign management Sippo WAC provides a way to create a user structure with a hierarchy of access permissions grouped in organizations, campaigns and agents. A campaign is associated to an organization and only users that belong to same organization have permissions to access it. Each campaign has a start date and an end date that informs if a campaign is active. The actions associated to each campaign are: create, edit, list and delete. Also, when a campaign is created/updated, a list of agents is supplied. Each agent profile is inspected to ensure that it s profile exists and belongs to same organization. Each campaign has associated two forms, one with the feedback of the agent that is displayed during the call and the other one is presented to the Click to call user at the end of the call to value the agent performance. Virtual Desktop Infrastructure Support Companies and contact center are trying to virtualize their infrastructure to reduce operational costs. Sippo Web Collaborator as a WebRTC agent tool, makes possible to access to the softclient from any device with no need to install or update anything. This reduces expenses in devices, licenses and operation. SOLUTION RELIABILITY Rehydratation WSC increases web communications reliability through application rehydration, which is the process of recovering disconnected sessions and re-establishing connections when network connectivity is interrupted. When web sessions are reconnected they are populated with the previous session s information, such as customer name, balances, and so on. In the browser environment, a user may reload the web page at any time. When the web page is reloaded, the WebRTC session is rehydrated and the session state is recreated and synchronized. The session connectivity is also maintained across networks (for example, Ethernet to Wi-Fi and Wi-Fi to 3G). WSC can also handle session transfer across WebRTC-supporting devices (for example, desktops, mobile phones, and TVs), by leveraging session transfer flows controlled by external SIP application logic. 13 I 22

14 Strict corporate firewall and HTTP proxy traversal Peer to peer communications are essential for the majority of WebRTC applications, minimizing network latencies and maximizing server-side bandwidth. Nevertheless, NAT/Firewall devices introduce serious challenges to these communications. The WSC provides Network Address Translation (NAT) traversal using Interactive Connectivity Establishment (ICE), which together with STUN and TURN, overcome these challenges. Initially, the browser uses STUN to collect all its public IPs, so that a peer-to-peer session can be establish and firewalls can be traverse. While this is helpful in a number of scenarios, there are cases where both endpoints may be behind symmetric NATs. In such scenarios STUN won t enough. On many enterprise customers (like insurance companies or banks), for example, the WSC requires to be located on a private network also behind firewalls. In such scenarios, and without proper mechanisms, the communication between endpoints and the WSC may be compromised. Having the WSC working as a TURN relay, the firewalls just need to open the ports associated with TURN and the browsers can connect with the WSC by using the external Firewall IP mapped to the WSC. This can be archived using UDP, TCP and TLS, since they are all supported by the WSC. TURN over UDP is usually the prefer choice, but in several cases UDP traffic is blocked by the firewalls. Additionally, and since some companies block all traffic except HTTP, the traffic can be encapsulated in HTTP packets and deliver to the WSC. Resilience On the signaling side, the WSC takes advantage of the Oracle Weblogic features, which allows multiple WSC-SE instances running simultaneously and working together to provide increased scalability and reliability (active/active model). The server instances that constitute a cluster can run on the same system, or be located on different systems. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing system, or you can add systems to the cluster to host the incremental server instances. In terms of data synchronization, the WSC-SE uses coherence to replicate the user s data between nodes, allowing service availability in case of a node s failure. The WSC-SE cluster is usually deployed behind a load balancer (both HTTP and SIP traffic), which lends a single IP view for the server, apart from providing service availability to the client. On the media side, a WSC-ME cluster is a collection of two WSC-ME instances, deployed in an active-standby model. Based on VRRP and a proprietary messaging protocol, both instances are able to detect failures, allowing the standby instance to take over when the active instance goes down. Contrary to the signaling engine, each WSC-ME instance requires a dedicated server (or VM), so a WSC deployment with two WSC-ME clusters results in four servers. 14 I 22

15 The WSC-SE also implements a Dynamic Round Robin algorithm for WSC-ME load balancing. This load balancing will take into account both the current state and load level associated with each WSC-ME. Sippo WAC supports high availability. We can use different web load balancers (ask to your sales representative for an updated list) when more than concurrent calls or users are active. As Sippo WACs do not deal with real time traffic, the cost in term of capacities of these balances won t be critical. In addition the Sippo WAC has a feature to balance Oracle s WSC, as each endpoint can be invited to use a different WSC (depending on defined policies), so in some scenarios the element for load balancing of WSCs is not needed. The next figure explains this architecture. Fig. 5 High availability and gateway balancing using Sippo WAC Security WSC supports different mechanism that allow securing both signaling and media. On the signaling layer, WSC supports secure WebSockets (WSS) which an HTTP proxy should allow in a transparent manner like any other HTTPS traffic. On the media layer, WSC ME supports the different security mechanism defined on the WebRTC specifications. Audio/video exchange between the browser and the WSC-ME will be secured using SRTP/DTLS, while data traffic (Datachannel) will be secured using SCTP/DTLS. The DTLS certificates can be provisioned locally or generated dynamically per session. The peer certificates are verified using the fingerprint signaled in the SDP. Finally, in case TURN is used, the packets can also be encrypted using TLS. In terms of denial of service (DoS), WSC offers DoS protection (against message floods, malformed requests, and so on) at signaling and media levels. Media DoS protection includes the following: Pools of media ports are provisioned by port ranges on each IP interface (thus giving operators full control over the available port range). 15 I 22

16 All media ports are closed when inactive. When a signaling (SIP or web-associated) session requires media ports, they are allocated from the appropriate pool. The allocated media ports are owned by and dedicated to the signaling session. Media ports attach to a specific remote peer address and are closed to other IP addresses. When Secure Real-Time Transport Protocol (SRTP) is used (for example, with WebRTC media), additional authentication steps are used to verify the authentication trailer for each SRTP packet. When released, media ports are returned to the pool and are monitored to ensure that the media ports are fully quiesced (any inactive media ports that continue to receive media traffic are put into quarantine until fully quiesced.) Media can be monitored to ensure that the actual received codec matches the signaled codec. Real-time Transport Protocol (RTP) sequence integrity can be checked and invalid packets can be discarded. On the signaling side, WebRTC Session Controller DoS protection applies to all types of WebRTC signaling methods. Among other measures, you can set the limits for maximum incoming message size, complete message timeout period, limit the number of sessions/subsessions per application/user, and number of file descriptors to help prevent denial-of-service attacks. The separation of signaling and media contributes to the overall security because a DoS attack on the signaling side does not affect the media side, and vice versa. Authentication Sippo WAC support different authentication methods as it can work as an Identity Manager but it can also federate with internal elements and thirdparties. As an example, Active directories, LDAP, Microsoft Exchange can be used for this, together with any OpenID and OAuth element like Google or Facebook. Once the user is authenticated with the Sippo WAC, this generates a token that will be validated with the Oracle WSC, as this is described in the next figure. 16 I 22

17 Fig. 6 Call flow for call authentication using tokens Fig. 7 Call flow for call authentication with IMS core Security mechanisms Authentication is not the unique concern on WebRTC security as VoIP, web and new ad-hoc WebRTC attacks are possible. The WAC includes a set of mechanism to avoid: 17 I 22

18 Denial of service attacks Distributed DoS Illegal control Websocket poisoning Cross-domain attacks This includes blacklists, whitelists, call admission policies, user policies, campaign policies, etc SOLUTION COMPONENTS Sippo WebRTC Application Controller Sippo WebRTC Application Controller (Sippo WAC, in short). is a new product category that manages WebRTC applications, providing seamless integration with existing OSS and BSS in NGN and IMS architectures. Sippo WAC is fully compliant with the 3GPP reference architecture and has been designed to interoperate with Oracle and includes a number of advanced functionalities, some of them unique in the industry, including: Multi-Browser support, including non-webrtc browsers and smartphones. Security mechanisms to avoid attacks. Internal Network Address Book and federation with 3rd parties. Web-Authentication, IMS authentication and OAuth and OpenID support. Push notifications. Gateway load balancing. Statistics and Troubleshooting tools. User, group and service provisioning and policy management via Service API. Besides our existing WebRTC applications, we offer professional services to build ad-hoc applications based on customer requirements. By leveraging the existing modules, services and client libraries included in the working and tested code of sippo.js toolkit, Quobis is positioned to deliver WebRTC applications in a very short time-to-market, without dealing with low-level details and focusing on the business application. Those high-level 40+ modules, enable us to bring rich WebRTC solutions to the market without spending efforts on low-level integration details, in a scalable and future-proof way. 18 I 22

19 Sippo Click to Call Sippo Click to Call is a WebRTC Click-to-call button that allows users to connect their websites to a business telephone network. Fig. 8 Click to Call running Sippo Click to call is a fully-featured WebRTC-enabled click-to-call button with advanced capabilities. Built for the web with our interconnection background knowledge, Sippo Click to call allows customer services of enterprises to deploy a lightweight click-to-call button without the hassle of installing any desktop application. No Java or other 3rd party drivers needed. Built on top of SIPPO WAC (APIs). Support to audio & video calls. IM with links and icons support. APIs to manage contextual information. Anonymous or authenticated calls. Tools to manage provisioning and stats. Small footprint (300kb). Available today in English, Spanish, Portuguese, Japanese and French. Sippo Web Collaborator Sippo Web Collaborator is a fully-featured WebRTC-enabled enterprise communicator with advanced capabilities. This application allows the IT manager of enterprise to deploy a lightweight web client without the hassle of installing any desktop application. In addition, it can be used by contact centers as agents tool, as it supported of the features demanded by this type of users. No Java or other 3rd party drivers needed. Built on top of Sippo WAC (APIs). Support to audio & video calls. IM with links and icons support. Presence. Collaboration: screen sharing, image sharing, co-browsing, whiteboard. 19 I 22

20 APIs to manage contextual information. Tools to manage provisioning and stats and general interconnection. Available today in English, Spanish, Portuguese, Japanese and French. Oracle Communications WebRTC Session Controller The Oracle Communications WebRTC Session Controller is a carrier-class WebRTC service enabler that lets businesses extend UC and contact center communications to any user with a Web browser or native mobile application. Based on field proven technologies from the Oracle family of enterprise communications solutions, the Oracle WebRTC Session Controller enables rapid deployment of innovative WebRTC applications that span devices and networks. The comprehensive solution includes robust signaling and media engines for interworking the Web and SIP domains and extensible software development kit (SDK) for accelerating client development. The WebRTC Session Controller consists of Signaling Engine and Media Engine components. Signaling Engine Signaling Engine sets up and tears down calls between WebRTC enabled web browsers and the IMS core. It does this by translating JSON messages to SIP and back. WebRTC Session Controller translates messages between the browser-based client applications and network elements. Browser-based client applications control the features of the services running on the network by sending and receiving messages to and from the WSC over the WebSocket protocol. WSCSE supports JsonRTC messages over WebSocket connections for communication with the WebRTC based clients. WSC supports a signaling protocol, mapping the signaling message and routing the messages based on routing profiles. WebRTC Session Controller also manages the protocol message state and ensures state replication for reliable message exchange. Media Engine WSC-ME manages the media stream of the multimedia calls that Signaling Engine sets up. It is optimized for border control and media performance. It is the element responsible for Firewall/NAT traversal, by supporting STUN/ICE/TURN procedures. WSC-ME is able to perform DTLS/SRTP termination and interwork with RTP. The WSC-ME supports the following media handling standards and specifications: Network Address Translation (NAT) traversal WebRTC Session Controller supports Interactive Connectivity Establishment (ICE) (RFC 5245), Session Traversal Utilities for NAT (STUN) (RFC 5389), and Traversal Using Relays around NAT (TURN) (RFC 5766). 20 I 22

21 Media encryption and decryption WebRTC Session Controller interoperates with clients by implementing media transport mechanisms defined in RFC 3711 (SRTP), RFC 4568 (SDP), SRTP/DTLS, and RFC 5124 (RTP SAVPF profile). Codecs WebRTC Session Controller supports the transit of all audio codecs (Opus, G.711, and isac) and video codecs (VP8) that would be used in a WebRTC application. WebRTC Session Controller supports codec reordering, removal, and insertion. Audio transcoding of the following codecs is supported: AMR, AMR-WB, G711a/u, G722-1, G723, G726-16, G726-24, G726-32, G726-40, G728, G729, GSM, ILBC, SILK, and Speex. Opus transcoding is planned for next release. Interworking function WebRTC Session Controller supports the interworking function that WebRTC applications use to communicate with deployed SIP/RTP-based voice-over-ip and video-over-ip devices, and PSTN devices in the signaling and media domains. WebRTC Session Controller supports DTLS/SRTP termination, ICE termination, and RTP/RTCP stream multiplexing. Oracle Communications WebRTC Session Controller Oracle Communications Session Border Controller is the industry-leading session border controller (SBC) for fixed line, mobile, and over-the-top (OTT) services. Based on Acme Packet OS, Oracle Communications Session Border Controller operates on Oracle's range of purpose-built hardware platforms or general-purpose servers to deliver a unique combination of performance, capacity, high availability, and manageability that has made it the most widely deployed SBC in the world. By introducing this element on the solution, it is possible to add additional features such as, amongst others, Call Recording, Lawful interception and signaling normalization. Also, and since WSC-SE is deployed as N+1, the SBC can perform SIP Load Balancing (with Registration stickiness) between the different signaling engines. Transcoding Gateway WSC supports video transcoding via integration with 3rd party transcoding gateway, such as Dialogic XMS. This integration is based on the Rest Client API feature available on the WSC, which allows asynchronous REST calls from its Groovy script. Dialogic XMS will be located behind the OCWSC-ME, and receives all traffic already unencrypted. It will play its role just for web-to-sip or sip-to-web calls, since the WSC-SE is able to detect sessions between two browsers (that don t require transcoding) and bypass Dialogic. Radisys MRF can also be integrated with the WSC, but since the current version does not support REST, the approach available is having the MRF on the SIP path following a B2BUA model for the media transcoding. 21 I 22

22 SUMMARY This document summarizes the multimedia capacities and interconnection possibilities on the usage of WebRTC solutions by contact centers and enterprises. This includes web-centric contact center and integration with legacy voice contact centers. The joint solution using the Sippo WebRTC Application Controller (including Sippo applications) and the Oracle Communications WebRTC Session Controller represents the best-in-class strategy to take advantage of the new collaboration capacities of the web domain. About Quobis Quobis is a leading european company in the delivery of carrier-class unified communication solutions with a special focus on security, interoperability and identity management for service providers and enterprises. Quobis is headquartered in Vigo (Spain) with partners throughout the world. Quobis is well-known as one of the leaders in the standarization and deployment of WebRTC technology after being involved in the industry firsts implementations and PoCs in more than 30 countries Quobis Networks SLU. All rights reserved. Quobis and Sippo are trademarks of the company. The content in this document is for informational purposes only and is subject to change by Quobis without notice. Unless specifically included in a written agreement with Quobis, Quobis has no obligation to develop or deliver any future release or upgrade or any feature, enhancement or function 22 I 22