Is there any way to get the candidate in over telepresence before the VP of Finance leaves for Hong Kong later today? Well, you know that the quality of Skype is just not up to snuff and FaceTime on an iPad, in front of a panel of six, just won’t go well. What’s a good solution to get someone on consumer-grade gear into the enterprise-grade video conferencing room without completely sacrificing quality?
Good news! Cisco recently announced order-ability for its new Cisco Jabber Guest, one of two prongs built to support the firm’s Web Real-Time Communication (WebRTC) solution set. With Jabber Guest, Cisco’s “Pervasive Video” strategy of enabling video “from browser to the boardroom” and “in every pocket” really starts to take full form.
What is Cisco Jabber Guest?
This basic functionality, where every browser/phone/tablet is a video endpoint, and a little imagination opens up a lot of possibilities:
- Video-enabled contact center for consumer-to-business high-touch support. Financial services where high-wealth clients can get access to their personal advisors directly from a website or app.
- Kiosk-based video “remote expert” access for high-value products or services. An iPad-based retail kiosk could give a shopper access to a product expert at a remote store.
- Telemedicine. Remote consultation, nurse-call lines, remote translation services, all from apps or web browsers.
- Consumer-to-business sales. A real-estate agent could put a link on a business card giving another channel for a buyer to reach them.
- Business-to-business communication. Video conference to suppliers or employees of another company without worrying about compatible equipment.
- Recruiting. Bring remote candidates into enterprise-grade video rooms or conferences without compromising quality.
Put another way, think Amazon’s “Mayday” for everyone, in every website or app, for every purpose.
The Cisco Jabber Guest solution uses client-server architecture to provide services. On the back-end, the solution uses the Cisco Jabber Guest server in concert with Cisco Expressway-C/-E (or Cisco VCS-C/-E). Jabber Guest server sits in the LAN with Expressway-C, while Expressway-E sits in the DMZ to provide firewall traversal (in concert with Expressway-C).
The Jabber Guest Server
The Jabber Guest server maintains a database of URLs, mapping these URLs to SIP destinations, including such information as:
- SIP destination (a SIP URI, e.g. firstname.lastname@example.org)
- Display name (in Jabber Guest client UI)
- Caller name (for caller ID)
- Caller SIP alias
- State (always “Active” or a specified window of time)
When users in their browsers perform call control actions (call/dial, hold, mute, etc.), Jabber Guest server provides HTTP-to-SIP call signaling inter-working, translating clicks to SIP messages. For example, when a user clicks “call,” Jabber Guest server sends a SIP INVITE message to Expressway-C, which then routes the call off into the enterprise’s unified communications system (e.g. Cisco Unified Communications Manager).
Jabber Guest server also maintains some configuration information. This includes call control parameters such as the Expressway-C server information for call routing and TURN credential generation along with the Expressway-E server information for clients to use for ICE/TURN services.
The solution, as mentioned, depends on Expressway-C/-E. The Expressway-C/-E establishes a “unified communications zone” relationship which facilitates both firewall traversal for media as well as a web reverse proxy functionality to give external users access to the Jabber Guest server services.
When a user clicks a link to launch a Jabber Guest session, their HTTPS web traffic lands first on the Expressway-E, which securely reverse-proxies the HTTPS traffic to the Expressway-C, which in turn securely reverse-proxies it to the Jabber Guest server. The web reverse proxy functionality operates much like a Microsoft TMG or Apache and is limited to proxy only the Jabber Guest server(s) and specific URL paths.
The eagle-eyed may have noted the “WebRTC-like” statement in the prior section. In this first release of Jabber Guest, the application makes use of a web browser plugin (and offers an SDK with the same functionality for iOS) to perform audio/video services. The plugin architecture does offer some advantages including (for the moment) widespread compatibility – Jabber Guest supports Internet Explorer, Safari, Mozilla Firefox, Chrome and other browsers. However, some browsers plan to drop the legacy plugin architecture in favor of HTML5 and “native” WebRTC capabilities. Cisco plans to add such support in a future release.
Today users must load the plugin, based on Cisco’s Performance Video Engine or PVE technology – initially from the old Cisco/Tandberg Movi client – in order to use Cisco Jabber Guest. The client’s web browser performs call signaling based on user actions such as clicking “call” (with JGS interworking HTTP to SIP call signaling), while the plugin uses PVE features for ICE, which itself uses Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN).
How it Works
First things first, a link URL must be provisioned in Jabber Guest (either manually or via API) with a SIP destination and other parameters. A user can then access the link (click it on a web page, an email signature block or elsewhere).
As the page load processes, Jabber Guest server first validates that the link exists and is active, then generates TURN credentials for the client on-the-fly, and uses the Expressway-C API to place them in the Expressway-C database. It then returns the web page, including various bits of configuration for the Jabber Guest client such as the “Display Name” to show in the browser, TURN server information and TURN credentials (along with the HTML of the page itself).
After loading the Jabber Guest web page, the user’s web browser launches the plugin (or is offered the plugin download). The plugin immediately attempts to establish a TURN connection to Expressway-E (using Jabber Guest server supplied information), even before the user clicks “call,” and alerts the user if the connection fails. The connection uses the supplied credentials, which Expressway-E validates with Expressway-C (which Jabber Guest previously configured via API on-the-fly).
The user then may proceed to click “call” to initiate a session. This sends HTTP call signaling to Jabber Guest, which in turn will initiate a SIP call to Expressway-C, which in turn routes the call into the enterprise unified communications architecture. The SIP signaling includes the link’s configured Caller Name and Caller SIP alias, as well as Session Description Protocol (SDP) information with the TURN address and ports for media (in other words Expressway-E). Expressway-C engages a Back-to-Back User Agent (B2BUA) to allow it to re-originate the call and terminate media from the TURN server (Expressway-E). If the called party answers, Expressway-C and Expressway-E negotiate to allow firewall traversal for media, connecting media for the Jabber Guest client and the called party.
What Does it Cost?
As with any solution, price is paramount.
Cisco offers the Jabber Guest server, and use of the client plugin, as a $0 line item attached to an active Cisco Unified Communications user-based licensing support contract (UCL or CUWL). Cisco offers the Expressway-C and Expressway-E as a $0 line item under the same model.
In other words, if you are already a Cisco UC customer, the server software portion of Cisco’s WebRTC party is “Bring Your Own Compute” (BYOC).
Every concurrent Jabber Guest session consumes Expressway Rich Media Session (RMS) licensing, one (1) license each on Expressway-C and Expressway-E, two (2) RMS licenses total per call session. Each one (1) RMS license costs $750 list price, so each full session (consuming two (2) RMS licenses) costs $1500 list price. Each RMS license also carries a $60 support service (ESW) and $75 software subscription (UCSS) charge, for $135/yr. total support contract charges (multi-year discounts are available).
The Jabber Guest Server requires 2vCPU @ 2.50GHz, 4GB of RAM and 100GB of disk space. Cisco offers the software as a packaged, pre-installed OVA, using 64-bit CentOS 6.5 Linux as the base OS.
I conducted multiple deployments during the beta trial but almost all used the same basic topology: a Jabber Guest server on the LAN, an Expressway-C in the LAN and an Expressway-E in the DMZ (single NIC with public IP, no NAT). Expressway-C used search rules to route incoming calls to a CUCM SIP trunk, which in turn routed calls to endpoints.
The Jabber Guest SDK for web and iOS offers a lot of potential – easy to understand, easy to integrate into existing sites and applications. Without much effort, I was able to add Jabber Guest features to some basic demonstration websites (a healthcare portal, a customer service web page, a financial portal). The iOS SDK also integrated easily to several existing applications. These SDKs can truly unlock the potential of Cisco Jabber Guest, though they require someone with the skills to use them effectively.
I also made much use of the Jabber Guest server provisioning API – this proved much faster than pointing-and-clicking my way through the admin interface, and allowed me to write some scripts to periodically synchronize with Cisco Unified Communications Manager.
The most useful basic script simply dumped the Directory URI of every CUCM user, created a corresponding Jabber Guest link, and emailed the link to the user (after passing it through the Goo.gl URL shortening service for ease-of-use). The script used set comparisons to automatically remove links for deleted users.
The provisioning API also integrated easily to demonstration websites to allow on-the-fly link creation, with time-limited links for applications such as scheduled video conferences.
An exciting new product in an exciting space! Cisco Jabber Guest lays a solid WebRTC foundation for customers to leverage in many interesting ways. Enterprises will find Jabber Guest’s basic functionality quite useful, but the true power comes with leveraging the SDKs and provisioning API to build additional functionality into existing or new applications.
Cisco also set the price point well, making the software itself $0 (Bring Your Own Compute!) and putting the incremental cost on a per-session basis. The solution scales cleanly and efficiently as well.
A few minor quibbles for this “1.0” product (despite being released as “Cisco Jabber Guest 10.0”):
- The deployment model for Expressway-E with NAT and dual interfaces leaves a bit to be desired. The call signaling flows pass between the LAN and the DMZ in a manner that necessitates a pinhole in the firewall (a minor security issue).
- Not a Cisco Jabber Guest Server issue per-se, but the Expressway web reverse proxy feature offers Cisco Jabber Guest services on TCP port 9443. This necessitates a firewall PAT of TCP port 443 (the standard HTTPS port) to TCP port 9443 on the Expressway, even if Expressway uses a public IP address, making for some ASA firewall configuration “fun-time.”
- The admin interface’s 1.0-ness shows in the lack of administrator access authentication integrations and web GUI bulk provisioning tools, among other minor quibbles.
- The mind boggles a bit at the decision to use CentOS. Yet another Linux operating system flavor for Cisco to support.
- The mind boggles further at the lack of a native backup function. Every other Cisco product, from routers and switches to Cisco Unified Communications Manager, offers a method to perform a backup. VMware snapshot features are not a valid substitute.
There’s only a few “uglies,” and hopefully Cisco will quickly address them in future releases:
- This product cries out for a direct integration to Cisco Unified Communications Manager (self-provisioned Jabber Guest links?) and TelePresence Management Suite (auto-generated per-conference Jabber Guest links?), among other products. When will Cisco learn to bring the full package in the first release of their products?
- Lack of an Android SDK. Cisco dropped it in the rush to market; hopefully it will show up quickly.
- Lack of HTML5 and “native” browser WebRTC support. Mozilla and Chrome both support these features, disappointing on some level that Cisco dodged with the plugin composed of repackaged Movi technology.
- Lack of Jabber Guest content presentation and co-browsing support. There’s little doubt Cisco could not easily implement these features based on the plugin architecture. But their lack hurts the ultimate utility of the product relative to competitors. Without these features, Jabber Guest cannot provide the full Amazon Mayday-like experience.