Sending a Video Representation
Another way to co-browse is for an application to grab a screenshot, or some defined portion thereof, at some specified rate, and convert these images into a compressed video stream. In such a scenario, the application typically only sends the changes in the screen images between screen grabs. This is how Webex, Microsoft Skype for Business, and many other tools like them work. Use of these tools often requires a license or subscription. WebRTC, a free tool built into some browsers, is an alternative. However, it too has some challenges when used for co-browsing.
For example, screen sharing, via WebRTC’s data channel, can hog resources. The device on which WebRTC is running sends video at 30 frames per second, with a separate stream sent to each participant. So, screen sharing via WebRTC can consume a computer’s CPU resources. While contact center screen sharing will typically only be between two parties, the agent and the customer, the bandwidth for sending WebRTC-based HD video begins to become onerous for contact centers with hundreds or thousands of agents.
In addition, WebRTC still doesn’t work seamlessly across all Web browsers. While all major browser vendors have announced WebRTC support, you still regularly come across disclaimers like, “works with FireFox version xx and above” or “works only with Chrome version xx and above.” Microsoft Edge has some Object Real-time Communications (
ORTC) capabilities that sort of work with WebRTC, but last I checked the Edge browser’s data channel didn’t work.
Rendering Using the DOM Elements
A third way to share a Web page is to use an application that sends the actual DOM elements (HTML, CSS scripts, etc.) from the customer’s Web page to the agent for full-fidelity viewing. This is the most accurate way of sharing a Web page or app screen with an agent because the fonts remain crisp and the images maintain their quality, with 100% compatibility across any browser in use. If an agent marks up the screen, the annotations get inserted into the HTML code and are displayed perfectly on the customer’s side.
While this sounds simple and rather elegant, the reality is that screen sharing using the DOM elements is really difficult to do well. The reason is that any screen sharing tool that uses this method must accommodate everything the browser does; otherwise, the pages may not display correctly. Furthermore, the screen sharing solution needs to understand all HTML versions because the agent cannot determine which browser and version of that browser a customer is using.
Screen sharing using the DOM method has some significant advantages:
- It’s computationally efficient.
- It’s bandwidth efficient.
- Web pages display properly, with no artifacts or distortions.
- Annotation works properly.
- It’s 100% compatible with any browser.
However, DOM-based screen sharing can have a significant downside: the use of a proxy server. To simplify the process, some screen sharing using DOM methodology require a proxy server to render the shared DOM elements. However, a proxy server is going to be bad for many customer service organizations because:
- Customer login information gets lost, which means the customer must reenter credentials.
- Proxy server use can present compliance risks, potentially allowing a man-in-the-middle attack.
- Tracking cookies placed on a proxy server could contain information the contact center organization or the end user’s company may want to remain private.
Click below to continue to Page 3
