Tsahi Levent-Levi’s white paper, “Seven Reasons for WebRTC Server-Side Processing,” details a variety of WebRTC-related scenarios that necessitate a media server. Last week, I wrote about reason number six: processing of the media stream. This week, I’ll discuss reason number seven, which deals with machine interaction.
Machine interaction is not a new concept. Interactive voice response (IVR) is basically all about machine interaction. We use dual-tone multi-frequency (DTMF) signaling to connect to an auto-attendant, such as a video virtual agent. When customers connect to a video virtual agent, they are then routed around to various other self-help places. Basically, the machine is trying to do everything it can to avoid having the customer talk to a human agent, because humans tend to be pricier. Talking to a real agent is a last resort, unless the customer has premier status. None of this is new. What could be new here is if the virtual agent were able to see customers via the camera on their computers or mobile devices. The virtual agent might then use facial recognition to gauge if a customer is getting pissed off, in which case it could more quickly direct that customer to a live agent. This media processing is what I referred to in my previous blog.
In that blog, I also discussed security via a camera stream. The camera transmitting to a cellphone or laptop is another example of a machine interaction. The media server will need to enable the correct format (via transcoding) and correct signaling (via WebRTC gateway functionality) to send. It will also need to record and store the video in a compressed format.
In today’s world, we’re seeing more and more machine interactions. Some of them may not need WebRTC, but many of them will. Just remember, behind every machine interaction is a media server that is crunching the media stream. To read more examples of how WebRTC and machine interaction work together, check out Tsahi’s white paper on the seven reasons for server-side media processing.
