The Telepresence Content Server

So the possible prospect of doing a greenfield install for a customer needing telepresence is here.  Now with my time at Cisco, I know telepresence fairly well and added that to my UC suite of knowledge but some of the additions required, not so much.  Recording and streaming might seem like a simple task but it is anything but that with the current documentation or lack thereof. 

See the problem is that Cisco's current documentation is slightly incorrect and out of date.  vBrick is the new partner with Cisco and their product is replacing the Show N Share.  Before, you had a TCS (Telepresence Content Server), an MXE, and then a Show N Share plus whatever else you needed on top of that.  These days, at least as of 6 months ago, vBrick REV and vBrick DME is now the standard. 

I had asked the question if TCS in itself could stream live and recorded video via a web portal.  Now regardless of what your sales rep at Cisco may say, the answer is it can do both with the limitation of up to 100 users.  So for a small environment, this would be acceptable but obviously doesn't scale well.  The next issue is you need somewhere to offload this material to anyway and that is where the DME comes in.  The other option is a Wowza server but since Cisco is now partnered with vBrick, that solution isn't really put out there but it is supported.

The vBrick DME is essentially a storage server and transcoder/transrater with the ability to feed streams to a video portal / control tower of some sort for others to view.  This device used to be a hardware device but now runs as a VM on a C220 M4 server.  So with the current picture we have a TCS which live records and streams straight to the DME server for storage and whatever else you may need to do.  Our current diagram looks like this:











As you can see, the telepresence endpoints both connect to the Cisco TCS for live recording.  A screen comes up letting them know they are about to be recorded and then they are on their way.  Everything recorded is sent straight to the DME via SIP or H.323.   Regardless of what the Cisco documentation says, SIP is completely supported on the TCS.  The documents are wrong as I sent an email to Cisco as well as on their support forums and got the "We know and are working on fixing the documentation" answer.  This is good news actually, because H.323 by itself would have made things difficult by registering to a VCS and then needing to use traversal licenses.

The next part of the equation is the REV.  Think of the REV as a YouTube portal or distribution server.  Basically, it takes the videos on the DME and makes them presentable to a wide range of people.  The basic license from what I see from vBrick starts at 1000 users.  You setup users or public access, give a link and the end user can watch a recorded or live stream.  Permissions, polling, comments, it's all there on the vBrick REV.  Statistics like browser, traffic, etc, are also all present.  The confusing part?  The REV can talk directly to the TCS if it wanted to, you just wouldn't have any mass storage.  So the diagram turns into a triangle and looks like this now:



Overall, it is a simple design actually, it's just learning the equipment and how to install it is the tricky part.  The REV luckily is easy as it is mainly cloud based.  On-premises solutions are involved and expensive and from what I was told, aren't needed unless you are a big corporation.  The final piece to the puzzle is that you will need an MCU of some sort.  The TPS or vTS (virtualized telepresence server) will let you host multipoint meetings.  This is required since the TCS is part of the meeting as it is considered an endpoint and thus the meeting would become a 3 way meeting.  Any telepresence meeting beyond just two endpoints requires an MCU of the sort. So just to tie it all together, at the bottom is the final topology.  I hope some of this information has demystified this whole situation because it sure confused me.