Cisco Expressway, collaborative edge and the beauty of SRND v10.0

Posted on by Admin

Related Post

Cisco Expressway, collaborative edge and the beauty of SRND v10.0

Because I have been away from the grind stone for a while and have, otherwise, been involved in a lot of non-digital work and hobbies, the introduction of Cisco Collaboration Systems SRND (mid November 2013) had gone somewhat unnoticed to me.  Time to pick some of the things in it apart.


 I would like to spent some time on posting on what Cisco has been calling “Collaborative edge” for a while. For a description of the concept of collaborative edge:


 SRND 10.x Is the first time building blocks of collaborative edge: the Cisco Expressways, are actually described on a technical/admin level.

 
Cisco Expressway mobile and remote access capabilities provide registration of Internet-based devices  to Unified CM without the use of a VPN, otherwise known as VPN-less enterprise access. (Sometimes the term mobile and Remote Access (MRA) proxy is being used rather than VPN-less.)
Either way, I think it is frikkin’ awesome, (enterprise grade whatsapp) because the Cisco community forum is full of posts of people reporting all sorts of issues with Jabber across VPN. Collaboration Edge will allow content sharing, voicemail, initiate calls, IM&P, search corporate directory, all by users outside of the enterprise. I have to mention that at the time of writing I have not had any hands on experience with Expressway, but I am excited about it none the less. I will keep using the term Expressway, but it is in fact the same software as VCS Expressway. The product name just changes when the appropriate licence is being loaded onto the server.


 The expressways will be deployed in pairs; one on the inside of the firewall and one in the DMZ

Figure 1  – Deployment of Cisco Expressway for VPN-less Access


So, of course, the trick is to provide firewall traversal, in such a way not to break the signalling payload. I have dedicated a post to NAT and firewall traversal and its intricacies around signalling, so for some back ground information, please check out that post

 http://ciscoshizzle.blogspot.com.au/2014/01/sip-firewall-traversal-and-how-does-sip.html

 Back to the actual solution, which contains the following components:

  • An Expressway-E located outside the firewall on the public network or in the DMZ, which acts as the firewall traversal server.
  • An Expressway-C or other traversal-enabled endpoint located in a private network, which acts as the firewall traversal client
The two Expressways work together to create an environment, where all connections between the two are  outbound, i.e. established from the client to the server, and thus able to successfully traverse the firewall.  The way this is done, is that the client (expressway C) initiates a connection on a certain port to the server (expressway E). This connection is kept alive by sending periodic hello’s to the server. When the traversal server receives an incoming call request from a user (who happens to be located somewhere on the internet), the server will use the open connection, to pass on the call request to the client. (who will then pass it on to CUCM).  So really, from a firewall’s point of view, the connection is still initiated from the inside.


Please note that this solution is not new. It was already used in Meeting Place to allow external participants to join meetings.


 In terms of ports that need to be opened, the following table is taken from the Cisco Expressway administration guide X8.1


 and between Expressway C to CUCM:




 a particularly good post, is one from Mike White:

 http://ciscocollab.wordpress.com/2014/01/29/deploying-collaboration-edge/

So please check this out to get some more info on certs and DNS record to bolt it all togethe