Wednesday, September 14, 2016

Cisco Meeting Server (CMS) Part 3 - Integrating Core and Edge

Part 1 - Making your first call to CMS
Part 2 - XMPP and CMA
Part 3 - Integrating Core and Edge

In this post, we are going to deploy a single CMS Core and a single CMS Edge.

1. Certificate for Core and Edge.  Like our previous posts in Part 1 and Part 2, I am going to use self signed cert for simplicity.

CMS Core:
pki selfsigned core

CMS Edge:
pki selfsigned edge

2. Using WinSCP or other SCP / sFTP client, to download the CMS Core certificate, in my case it is core.crt.  Copy this Core certificate to Edge using your SCP client.

In CMS Edge, create the loadbalancer service module and config the certificate for authentication.  You will need to trust your Core certificate in Edge.  In my lab it is a single NIC Edge.

CMS Edge:
loadbalancer auth edge edge.key edge.crt core.crt
loadbalancer trunk edge a:4999
loadbalancer trunk public edge a:5222 lo:5222
loadbalancer enable edge

3. In CMS Core, you are required to create a trunk.  Similarly, copy the edge certificate to core, you will need to trust the edge certificate in core. is the edge IP address.

CMS Core:
trunk create trunktoedge xmpp
trunk auth trunktoedge core.key core.crt edge.crt
trunk edge trunktoedge 4999
trunk enable trunktoedge

You can use the trunk debug trunktoedge (the tag name) to see whether the trunk is up on core.

4. There are a few service modules can be enabled on Edge.  If you want to enable SIP Edge, you will need the below command:

CMS Edge:
sipedge public a:5061
sipedge public-ip
sipedge private a:3061
sipedge certs sipedge.key sipedge.crt

5. Another service module on Edge is TURN.  To enable TURN, you will need the following command:

turn credentials admin admin
turn listen a
turn public-ip
turn enable

From the web user interface, you can enter the details under "TURN Server settings".  TURN Server Address (Server) is the intenal server IP address that the Call Bridge will use to access the TURN server.  TURN Server Address (Clients) is the public IP address assigned to the TURN server that external clients will use to access the TURN server.

6.  Finally you can enable the webbridge module on Edge, it will allow internal and external participants to join a meeting with their WebRTC capable browser.

First of all, certificate again.

CMS Edge:
pki csr webbridge
pki selfsigned webbridge

Copy your core CallBridge certificate to Edge, your webbridge service needs to trust your callbridge cert.  Then config the webbridge parameters:
webbridge listen a
webbridge certs webbridge.key webbridge.crt
webbridge trust callbridge.crt
webbridge http-redirect enable
webbridge enable

After configured, you can type "webbridge" to check your configured parameters.

Go to Configuration > General, enter your Guest account client URI, for example  The Guest Account JID domain is your domain, in my case it is

Depends on your DNS settings, you might need a few static entries on your edge, to resolve the xmpp SRV to your local loadbalancer FQDN.

dns add rr " IN A"
dns add rr " 86400 IN SRV 0 5 5269"
dns add rr " 86400 IN SRV 0 5 5222"

After all these steps, you should be able to use webbridge to join a meeting with WebRTC.

In summary, we have covered the integration between core and edge in a single split deployment, and we can enable a few service modules on edge including SIP Edge, TURN and WebBridge, for different call scenarios especially for B2B calls.

Part 1 - Making your first call to CMS
Part 2 - XMPP and CMA
Part 3 - Integrating Core and Edge

Cisco Meeting Server (CMS) Part 2 - XMPP and CMA

Part 1 - Making your first call to CMS
Part 2 - XMPP and CMA
Part 3 - Integrating Core and Edge

In our previous post - Part 1 (, we have set up the basics of CMS, and making our first call to CMS Space, as well as allowing multiparty video conference with CMS.  Now let's do something else.  XMPP is a service module that is running on CMS Core, one of its function is to allow Cisco Meeting App (CMA) to login and be one of the soft client running on PC / Mac / mobile devices.  We are going to go through a few steps and at the end of this post, you will be able to login your CMA and start to make calls.

Setting up XMPP in CMS Core

1. If you want to create a csr for your CA to sign, you can use the pki csr command.  In my lab I am using self sign cert to make it simple.

pki selfsigned xmpp

2. Configure xmpp interface, certs and domain.

xmpp listen a
xmpp certs xmpp.key xmpp.crt
xmpp domain
xmpp enable

You can check your configuration with the command xmpp status, or simply xmpp.


3. Add Callbridge to your XMPP.  You can give your callbridge a name / tag, it doesn't necessary the hostname / FQDN of your callbridge.

xmpp callbridge add cms

Remember the name of your callbridge that was entered and the secret.  If you forgot that, you can use this command to check.

xmpp callbridge list

4. Switch back to the web interface, under Configuration > General, under XMPP server settings, enter the domain, server address, call bridge name and secret that you have got from step #3.

5. Make sure you have the DNS A and SRV records are created in your internal DNS.

In my lab it is a Windows one.

Host record of my CMS core:

SRV record (_xmpp-client, _xmpp-server):

6. AD integration.  There is no option to create local users on CMS, this is my lab AD information that I've put in the CMS UI.

7. Get your Cisco Meeting App (CMA) from if you are testing with your Windows / Mac.  For mobile app you can download it from iTunes store / Google Play Store for free.

Sign in with your AD credential.  The format of the username will be username@domain

This is what you should expect after logging in:

After these steps, you are now able to login and use CMA as your client for calls.

Part 1 - Making your first call to CMS
Part 2 - XMPP and CMA
Part 3 - Integrating Core and Edge

Wednesday, August 31, 2016

Cisco Meeting Server (CMS) Part 1 - Making your first call to CMS

Part 1 - Making your first call to CMS
Part 2 - XMPP and CMA
Part 3 - Integrating Core and Edge

Cisco has rebranded the Acano solution to Cisco Meeting Server (CMS), and this post is target to help you to set basic things up and make your first call to a CMS Space and CMS IVR.

1. First of all, deploy your CMS ova with vCenter.


2.  It will spend around 10-15 minutes for the first time boot up.

3.  Login via CLI.  Default credential is admin/admin.  You are required to change your CMS admin password for the first time login.

4. You can check your interface configuration with the command "ipv4 a".  By default DHCP is enabled.

Set your static IP address with the command "ipv4 a add", in my case is the IP address of my CMS, is the default gateway.

Check your interface configuration again with the command "ipv4 a".

5.  You can config your DNS server settings with the command "dns add forwardzone .", which will forward all the DNS query (. means all domain) to my DNS server

Check your DNS configuration with the command "dns".

6. Create self-signed cert for HTTPS web admin with the command "pki selfsigned webadmin".  In this case webadmin will be the filename of your self-signed cert.

7. Config web admin interface access.

webadmin certs webadmin.key webadmin.crt
webadmin listen a 443
webadmin restart
webadmin enable

Try to access your web admin page:

Login with your admin credential:

You will see there is a warning saying that CMS is running in evaluation mode as no license is installed.

8. If you are going to enable WebBridge (accessible by the WebRTC client), we have to change the web admin listening port from 443/tcp to something else, say for example 445/tcp.

webadmin disable
webadmin listen a 445
webadmin enable

9. Copy the license file to CMS via sFTP or SCP.  In my case I used my mac built in sftp client and upload the file to CMS.

sftp admin@
put cms.lic

10. Enable and config CallBridge, which is the core components for all the audio and video call terminations.

pki selfsigned callbridge
callbridge certs callbridge.key callbridge.crt
callbridge listen a
callbridge restart

11. Login the admin page again, you should seen something similar to mine below.

12. Enable IVR, in my case my IVR number is 8224, so when you make a call to 8224, you will see the default Cisco background and listen to the default IVR prompt.  The IVR number can be configured in Configuration > General > IVR Numeric ID.

13. You can also create your Space to call in, so that you don't need to key in any Call ID by calling the IVR, by directly calling to the Space.

14.  You will need to create your SIP trunk on UCM, pointing to CMS.  In my case it is a lab environment and I am using a non-secure setting so I don't need to deal with the certs.

The destination address is your CMS address.  You will need to choose the Telepresence Conferencing SIP Profile.  No Normalization Script is required.

Extracted from the guide:

15. Config your route pattern.  In my case my pattern is 822[45].

Try to place your test call.  You should now able to call your IVR number (8224 in my case) and Space number (8225 in my case) from your UCM-registered devices.

Part 1 - Making your first call to CMS
Part 2 - XMPP and CMA
Part 3 - Integrating Core and Edge

Friday, July 29, 2016

Using Scratch to control Raspberry Pi GPIO

In the previous post, I have built my first circuit and able to control the LED light using the gpio command:

Similar control can be done via Scratch, this is the official tutorial:

This is a super simple Scratch script to illustrate this:

In this simple script, when you click the flag icon, it will set the gpio pin 17 (BCM) to 1 to switch on the LED.  When you press the spacebar on your keyboard, it will set the gpio pin 17 to 0 to switch off the LED.  With this you can incorporate the GPIO control into your own scratch script.  Give it a try!

Tuesday, July 26, 2016

The "Hello World" circuit with Raspberry - Single LED

Probably the "Hello World" of building a simple circuit with Raspberry is a single LED circuit.  So I decided to give it a try.  Not difficult frankly speaking, just to get all the ingredients together and there are plenty of goods tutorial if you spend a minute to google.

This is the official URL that you can first check it out:

The circuit that I've used is exactly the same as the one you can find from the above URL, except that the "switch" is not a physical one, I used the gpio command to control it.

This is how it looks physically.  I've connected the GPIO pin to my breadboard using the female-to-male jumper cable.  Physical pin 11 is used for +ve and physical pin 6 is the ground pin.

Check out this link about breadboard.  An other things about building a circuit.

Some holes (usually the top and bottom rows) are connected in row and some (usually the middle) are in column.  

I've followed this link and used a 330 ohm resistor.  Check your LED spec to decide the correct resistor.  My LED works fine in a 11mA current circuit so 330 ohm resistor is good for my case.

Also check out the above link for LED.  The LED should have 2 legs, the longer leg is +ve and shorter leg is -ve.

One thing that I've spent quite some time is the pinout.  The BCM and physical board pin numbering is a bit confusing.  Say for my case, I've used physical pin 11, and in BCM numbering it is pin 17.  It will spend you hours to troubleshoot if you don't get it right.

You can use the gpio readall command to print out all its number convention and other details.

Another thing is, your physical GPIO pin 11 will be providing 3.3V power and you have to change its mode to OUT.  You can do it with the gpio command below:

gpio -1 means you are referring to the physical pinout numbering.

gpio -g means you are referring to the BCM pinout numbering.

This is a python script to switch on then off the LED light instead of using the gpio command.  You can find a similar script from the link provided above.  The only difference here is I am using GPIO.BOARD which means I'm referring to the physical pin number 11.

If you want to use the BCM numbering, then you can setmode to GPIO.BCM

Hope it will save you some time from troubleshooting layer 1 problem and to build up your first circuit with Raspberry!


Thursday, July 14, 2016

Raspberry Pi Cam + Cisco Spark - Motion Detection Demo

In the previous post, I've setup a Raspberry Pi Surveillance camera with Live streaming capability, and it can also save a video file when motion is detected.

Spark integration is done too so that when motion is detected, a Spark message is posted with video files.  This is how it works:

Live streaming video from the Raspberry Pi with Camera v2

Just got my Raspberry Pi Camera v2, cannot wait to unbox and play with it.

I didn't get a good case to fit in the camera module, but it works.  :)

First of all you can start by taking a picture to make sure your camera is working fine:

raspistill -o image.jpg

To capture your first video, you can use the command raspivid:

raspivid -o video.h264

The video is in raw h.264 format.  It is fine to be played back by my omxplayer on the Raspberry, however if you want most of the other video players to play it, it will be better to convert the file into mp4.

sudo apt-get install gpac
MP4Box -fps 30 -add video.h264 video.mp4

For some application such as "motion", the motion detection and video streaming applications, it needs to recognised the video device as /dev/video0.  It is not the case by default for the Pi Camera.

To enable that, you need to run:

sudo modprobe bcm2835-v4l2

You can also put this command in /etc/rc.local so that the next reboot it will run automatically.

Motion is an open source motion detection and surveillance software which can help you to convert your Raspberry Pi into a home surveillance camera.  To start with, you can get the motion package:

sudo apt-get install motion

A few parameters under motion.conf that you can change, such as:

daemon on

which makes the motion run in background when you start the motion server.

You can also change the resolution in the conf file:
width 1280
height 720

change the following parameter to off so that you can access from host other than localhost:
stream_localhost off
webcontrol_localhost off

You can now access the stream via http::8081

And you will get a bunch of files in your home directory, make sure you have enough storage, if not probably you might need to do it off box to a NAS or whatever it is.  These files are created when motion is detected.

These are the links that I've used to aid my setup, listing all here for your reference:

Wednesday, July 13, 2016

Expressway 8.8 registration - in action

In the previous post I've shared that the latest Expressway 8.8 supports endpoint registration:

I want to give it a try therefore I have upgraded my lab Expressway C to the latest version 8.8.  First of all there is a getting started wizard, and it will let you decide what role the Expressway will play and it will customize the UI accordingly and hide those that are not needed.

New license types are introduced (Room systems, Desktop systems), and it aligns with the UCM licensing model.  You will need UCL Enhanced / CUWL for desktop systems, and Telepresence room system license for Room systems.

I've some difficulties in using the endpoint activation wizard to register it to Expressway.  However it works well when I manually do it on the codec web admin page.  Under SIP configuration:

It is now registered, it can be seen from the codec admin page:

From the Expressway admin page:

This is how it looks on the DX70 itself: