In the last five years collaboration technologies have completely changed the landscape of consumer and enterprise communications. Team Messaging, PBXs, and video conferencing systems all exist and reign supreme in the enterprise realm. But there has always been one major gap that exists between consumer and enterprise technology and their ability to interoperate. On the enterprise side, many of them have high end telepresence systems for collaborating B2B, but consumers don’t have these tools.

Enterprises use telepresence; consumers use apps like use facetime and skype but none of these interoperate easily, if at all. This is where developer driven solutions come into play. These custom solutions make it easier to provide the same high end, enterprise experiences to your customers and vertical markets.

Cisco and others have long tried this with Jabber Guest, Lync Guest, and all the meeting on demand services like WebEx. All these experiences are sub-par, expensive, and hard to implement into a truly consumer friendly experience. So, how do we fix this? Cisco has been hard at work on a new cloud platform name Cisco Spark which has a pretty large portfolio now; team messaging, video, PBX as a service… but they are starting to wrap this into SDK’s for the major platforms. Now you can embed the spark experience into any platform you like on a pay-by-use model.


A huge part of this vision is the adoption of WebRTC over the past few years. I want to give a bit of a history so people understand how this changed things. We have been talking webRTC for about ten years now. For those that don’t know, it’s real-time voice and video in web-browsers without having to install any plugins. The idea is it would spread these technologies way faster, when this stuff started we mostly all used flash. Over time browsers added native video playback to many common formats and now we are nearly there on the WebRTC front. Two things have killed widespread adoption:

  • Video codec wars (H.264 vs. VP8). This never got solved 100 percent but they have a working solution. Instead the WebRTC consortium agreed all browsers would support both. Cisco also helped by paying the H.264 royalty for anyone who wants to use H.264. Firefox and Chrome support both.
  • Safari has no WebRTC support on desktop or iOS, but both have moved into the development phase and is finally being tracked on the Safari webpage. All things point to WebRTC for safari in 2017 which will drastically change adoption.The best way to understand is to see an example in action. Today we are going to look at how Cloverhound is using Cisco technology to power a new virtual court platform which allows people to attend court hearings over video and audio remotely instead of going into a physical court location.

We’ve all likely been to court before for a speeding ticket. Generally, you get a timeslot like 8:30-9AM on Tuesday. You go into court, wait in a lobby with or without your attorney, eventually a clerk calls you up, and you talk to the judge for 4 minutes. He confirms you’re an idiot and gives you a $250 fine and you go on your way. What if we could do that from home? Let’s look at a court system a little and see why this may not be a popular idea:

  • Technology Barrier – As we mentioned above most consumers and businesses don’t have the same type of technology. There are courts doing audio only call-ins for some types of hearings but this is typically done for special cases. To do video, we would need to have the same technology end-to-end to be able to easily communicate between attorney or claimant to judge.As I mentioned before, most court systems will allow a special case for an audio conference hearing, but they are generally manually arranged. They don’t do this at volume because of complexity. Most of this is because the conferencing system has no awareness of the judge’s case scheduled or the courtroom schedule, so it takes a clerk’s manual intervention to get the judge and attorney or claimant on the line together.
  • Scheduling – Many of the cases have multiple parties. They have a claimant, a defendant, attorney for both sides, and witnesses. It’s hard to coordinate everyone to be on audio or to log-in remotely, so you need something that makes it a hybrid experience.
  • Adoption and Ease-of-Access – Going to court may not be an easy experience overall but you generally know what to expect and it’s pretty straight-forward. You get your court information, find the room, see the judge in person, ask your questions, and you’re done. Things have to be ridiculously easy to access and adopt if you want people to utilize them. Video conferencing equipment is not ridiculously easy for the average person to utilize.

Purpose built applications

This is a pretty good use case to see vast differences. If you google about virtual court hearings, there are a sparse few product options out there. Unfortunately, they are mostly for audio only and they require new business process, new technology to be installed, and to be hosted by a vendor in the courthouse. What are our options for doing something to help people come to court remotely:

  • We could take look at writing an intelligent IVR but it would inevitably take a high level of integration work into the court case management system and it only would support audio.

We could setup remote kiosk type solutions that are more conveniently located and easier to get to than the courthouses.
We could ask attorneys to invest in some video equipment. But they would need to have the same equipment as their judges and typically within government it can be a mash up of products and equipment.
We could try and do something over a WebEx but this would take a bunch of scheduling up front with all parties and probably pretty slow.
We could accept that there is no great fit and build something purpose built.

We are going to go with the last option. Let’s look at what we need to make a virtual court system and some very simple rules about how a court runs:

• Judge can only be in one hearing or case at a time. This would imply the system needs a presence system to know who is in what case and not let other cases be started. It also implies we are going to need a queueing system or waiting room (acd?).
• Case management integration. We are going to need to know the case schedule, location of court houses, who’s going to be expected, and which courtroom they are taking place in.
• Courts close for inclement weather and emergencies. Judges get sick, change schedules, and trade cases. Clerks manage all this. There can’t be any loss in flexibility for the court system to run.
• Generally, courts have a goal that the outcome of a case should be the same as the last case with the same rule-set. If I had a property dispute in 1898 and the laws and circumstances haven’t changed then the outcome should be the same in 2005. Does technology change this in any way? If it does it’s out of the court system.

Lastly, what are we trying to gain from this? The court must be interested in technology for a reason.

• More cases processed equals a quicker time to resolution and therefore better justice for constituents.
• More time for clerks to focus on court duties rather than organizing people.
• More efficient resources (less clerks and less judges using overtime)
• Better experience for constituents. After all, the court systems are working for us, the people. This also includes attorneys.
• All these generally add up to savings for the courts and thus for the tax-payers. This is a win-win all around.

So, we agree if we can have faster, cheaper, and easier to navigate case processing then all parties involved are overall happier. That’s a win, win, win, win situation.

Designing the application

Now that we have some basic ideas there will be two types of users using this platform:

1. Judges and clerks – The folks running the cases for the court
2. Attorneys, claimants, defendants, and witnesses – Folks participating in the cases.

The goal is to give Judges and Clerks visibility of all their cases. They need to see who is available for a case (either over the phone, video, or in person), which cases are ready, and have the ability to start the cases. For all other users, the goal is to make joining the case remotely as easy as possible. It should be impossible to make mistakes and should require minimal effort.

The goal is that the consumers are just going to join over WebRTC using their PC or Cloverhound Virtual Court mobile application, both powered by Spark. We are going to focus on the PC for this blog.

For this to work the judge needs equipment in the courtroom and we are going to recommend a Cisco Spark Board. This could be an MX unit or even a DX-80 on the judge’s podium. Each judge will also have a CMR account, we are recommending a Spark M3 license, which gives Spark and a CMR to each judge. CMR will do a few things in the courtroom:

• Allow for WebEx powered meeting of up-to 25 participants. These record both audio and video.
• WebEx allows for call-in users to use the WebEx app and mobile app as well as Spark, offering a good middle ground for now.
• WebEx support CCA (Cloud Connected Audio) for high volumes of audio.

Let’s look at a very simple diagram of your average courtroom:


In this courtroom design we’ve put a DX-80 on the podium and we have it connected to a second TV to mirror the display out to the rest of the courtroom. You will find with courts they all have very specific requirements and often lots of legacy A/V technology to make it happen.

The judges have their CMR and video endpoints in the court room. Both they and the consumers are going to enter on a purpose-built web portal that is going to bring together all of the things we talked about earlier incorporating the following:

• Syncing with the case management system to have visibility into the upcoming hearings, which judge will be presiding over a case, and where and when it’s being held.
• Implement a simple login process for attorneys, claimants, and witnesses to use the portal and get into a hearing.
• Implement a presence system and dashboard system so that judges can see when people are logged into the portal.
• Implement a court management system to be used for clerks to manage both attendance and emergency messaging around hearings.
• Implement a queueing or waiting room system tied to the presence which allows for cases to be called when they are ready.
• Integrate with SSO / Office 365 for authentications and security of the judges and clerks.

There you have it, we are ready to build a purpose-built web-portal that encompasses all of the above. A solution for our vertical, rather than trying to adopt technology that will likely not work for every situation the courts would encounter.

Next, we’ll take a look at what our team has come up with.

The Application: Consumers Users

First off is the main login page for all consumers. You can see we ask for only three required fields. Providing an email is optional in the fourth field and used for outreach after the hearings. We also show them where they can find this information on their physical notice. (Note: This is a real app that is in use)

Next, they will be asked to pick what role they are (attorney, claimant, witness). We are going to choose claimant.

After choosing their role, we give them an attestation around whether their attorney will be attending. This helps drive the logic on the judge’s dashboard around when the hearing is ready to call (i.e., when all needed participants are present). This logic is completely customizable per client.

From here the participant is placed into their waiting room. There is nothing left to do other than wait for their hearing to start.

When the hearing starts the participant will automatically be dialed into the judge’s WebEx CMR with the Cisco Spark SDK and their video will appear with no intervention. Your hearing has started (pretend I’m a judge).

The Application: Enterprise Users

As we have already talked about, the experience for a consumer is different than a judge. The judge has CMR, they have enterprise logins, and they have video end points. Let’s look at the experience designed for them:

First off, the Judges and Clerks have a different login that is powered by SSO with ADFS / Office 365. Their login screen is much simpler, since all it needs to do is kick-off the oauth process. WebEx is also SSO integrated so it all flows together smoothly.

Once the user clicks login, they are redirected to their organization SSO page as such.

It is important to note, we have configured AD in the background to give a custom AD role to both judges and to clerks. This provides access and authorization. If someone in the org tried to login without either role they are denied. If they have the judge’s role they are redirected to the judge’s dashboard, and likewise for clerks.

If we are a judge we are redirected to our dashboard showing our hearings for the day (sortable by AM and PM) and the presence and readiness of each hearing. This dashboard is real-time (you don’t need to refresh to get presence updates).

If we are a clerk, we get the administration dashboard that allows us to send messages to each user / hearing or district. We can also add attendance for “in-person” or “by phone” users in the portal. Lastly they can see all locations and hearings for all districts.

When a judge calls a hearing the WebEx CMR is launched automatically with the correct user of the CMR. Once the CMR is up, the consumer browsers are notified to have spark call in. One-click, nothing else needed. Once the CMR is loaded all the judge does is click ‘Call My Video System’ to connect to their DX-80 in their courtroom.

At this point, everyone is connected and the hearing takes place! As you can see rather than taking a bunch of off the shelf components, we built something specific to the task that is much easier to use than anything existing on the market for this vertical.

Here is a video of all this in action now that you know what you’re looking at –

Technology Stack Used

I’m guessing people may be interested in the tools we used. In no particular order, some of the frameworks involved:

• Rails 5 with Action Cable and web sockets
• Sidekiq for service workers
• React and bourbon for front end
• Mobile applications written in React-Native
• Time…. Lots of time

To the future: The next step

The court system itself is in use in one state and soon variations of it will be in use in others. We are planning to host a SaaS platform later this year but let’s look at some of the overarching (non-vertical) platform capabilities we have:

• Presence platform that works on all major browsers and mobile.
• Video queueing platform (kind of?). It’s an interesting take on it.
• Mobile and desktop versions of the system.
• SSO / Office 365 integration.
• API standard for loading data into our platform.

Here is the good news, lots of other use cases for this technology exists. Basically, anywhere that services consumers and has a waiting room.

• Telehealth or eHealth visit – Imagine the doctor’s office has one room named the ‘Virtual Patient Room’ that just has a spark board in it that is loaded with the patient data (x-rays, past patient history, etc.) and the patient is waiting on video when the doctor arrives in the room. The portal is integrated to HER / EMR so that while the patient is logging in remotely and waiting for the doctor, they are filling out their medical forms as normal, and has access to all their patient information on demand.
• Financial Advisory / Banking – As we have seen with the ability at some ATMs to speak directly to a customer service representative by video, soon this capability will become common place from your house. Being able to service consumer banking, financial advisor, or stock trades over video will bring enterprise and consumers closer together creating more transactions and deeper trust.
• Education – Tutoring accessibility will never be the same as when video and scheduling for tutors is available right from Schools LMS systems (Moodle, Blackboard, Canvas). Imagine teaching remote / hybrid classes seamless integrated into these learning tools.

Integrating collaboration into vertical specific applications will be the catalyst for the next decade of change within our industry. It will prove to be the next leap the industries sees as we leave the days of trading out copper for IP as our main ballgame.

Portals and technology like this that fit a specific business need will be where Cloverhound focuses in the coming years, and so should you.

– Chad