Planet Collab

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Before yesterdayCisco UC

Cisco Meeting Server – Part 8: Call Bridge Groups

By ben

Call Bridge groups allows call bridges that are clustered to load balance in/outgoing calls, apply the smarts behind load sharing resources. We then link services or functions to the Call Bridge Groups. (as seen is later steps)

1. Using the an API Tool like POSTMAN, create a Call Bridge Group, and store the Call Bridge Group ID somewhere on your PC for later use. The command to use is POST https://172.18.27.24:445/api/v1/callbridgegroups.
2. Collect the Call Bridge IDs that will be members of the Call Bridge Group using the GET cmd.

cms-cbg-1

3. Modify the Call Bridges to add the Call Bridge Group ID

PUT -> api/v1/callbridges/call_bridge_id/
BODY – > callBridgeGroup = call_bridge_group_id

cms-cbg-2

4. Next we enable load balancing for the Call Bridge Group.

PUT -> api/v1/callbridgegroups/callbridgegroup_id
BODY -> loadbalancingEnabled = true
BODY -> loadbalancOutgoingCalls = true

cms-cbg-3

Cisco Meeting Server – Part 7: Call Bridge Cluster

By ben

Call Bridges operate as a single entity when clustered, scaling available resources. A prerequisite is to have a fully configured and functioning Database cluster. (Read PART 5 of this blog series).

Two cluster types exist. Peer to peer and via Call Control. Most efficient method is Peer-to-Peer. Where Call bridges route media directly between themselves and not via a call control server (CUCM).

Steps to Configure a Call Bridge Cluster

1. Log into Web Admin of each Call Bridge CMS Server. Navigate to Configuration -> Cluster. Enter a unique name for the Call Bridge. Eg CMS_01 (must not contain spaces).
2. On the first Call Bridge, go to Configuration -> Cluster and add All Cluster nodes into table using the above Unique Node Names. Do not enter the “Peer Link SIP Domain” field. Also ensure the Address is https://fqdn:445 (webAdmin Port). Ensure this address is DNS resolvable!

cms-cb-cluster-1

Another key factor to this configuration is the dial plan. For inter-peer calls.. (between Call Bridges in a Call bridge Cluster), a route must exist for the IP Address for peer members. There is a required when the “Peer Link SIP Domain” is left blank for the Call bridge Cluster.

*If you do not configure these outbound rules, you will see an error “remote media link to call bridge CALLBRIDGE failed for call”.

The impact will see a single video conference that is split between two CMS Call bridges.. Thus the conference participants will only see other participants on that same Call Bridge Host.

cms-cb-cluster-2

Cisco Meeting Server – Part 6: Call Bridges

By ben

Now we move onto creating the call bridges within our CMS Architecture. Call Bridges are the work horses.. These guys mix the media streams for conference participants. We will cluster the call bridges in the next step, for now lets setup the base services for the call bridges.

First is to upload the key an certificate files from the above ‘Certificates’ step via SFTP. I name the cert files for the call bridges “callbridge.key” “callbridge.cer”.

The certificate files will be shared among the call bridge servers.. So be sure to upload to each call bridge.

Select the interface for the Call Bridge to listen on. (Typical deployments will have interface ‘a’ selected)

Commands are:

callbridge listen a
callbridge certs callbridge.key callbridge.cer chain.cer
callbridge restart

cms_callbridge_1

*Repeat all Call Bridges

The base call bridge service has now been setup for each call bridge.

Cisco Meeting Server – Part 5: Database Cluster

By ben

As with any cluster, there is a master/slave relationship and there is no difference with CMS DB Clustering. We first need to initialise the DB Master, followed then by connecting all DB slaves. Remember.. The CMS DB Cluster must have an ‘odd’ number of members.. Another note to make about cluster members is the Call Bridge doesn’t have to be operational.. Hence DB Cluster members can be on general/standard VMs with typical resource usage such as CPU and Memory.. No need to allocate huge amounts of resources to DB Cluster members.. One example I can give is to have a 2 node Call Bridge Group configured linking to a 3 node DB Cluster.

Configuration steps starting with the CMS Database Master

Attach certificates to the database cluster.. We have already provides CSRs and have signed certificates from previous steps.

From the console enter:

database cluster certs dbserver.key dbserver.cer dbclient.key dbclient.cer chain.cer
cms_database_1

database cluster localnode a (We are specifying the CMS network interface for the DB to use)

database cluster initialize
cms_database_2

database cluster status
cms_database_3

Now Join each of the Slave Database Servers to the database cluster

Upload via SFTP the below certificate files

- Dbserver.key
- Dbserver.cer
- Dbclient.key
- Dbclient.cer

The above files were generated under the Certificates section. These files will be shared among CMS Servers.

Validate the certificate files on the CMS Server via the ‘pki list’ command
cms_database_4

database cluster certs dbserver.key dbserver.cer dbclient.key dbclient.cer chain.cer
cms_database_5

database cluster localnode a

database cluster join cms_hostname.com.au (this is the DB Master’s hostname)
cms_database_6

Database cluster status
cms_database_7

Repeat for each Slave Database Server. Note: Do not have an equal number of Database Servers in the cluster, must have odd number count. Example Cluster of 3 or 5 not 2 or 4.

Cisco Meeting Server – Part 4: Web Admin Configuration

By ben

We are now is a position to start configuring the Core functions of CMS. One of which is the Web Admin to give us access to the GUI.

Ensure, you have copied the webadmin.key from the CMS 1 host to the remaining CMS Hosts. Then also copy the webadmin.cer and chain certificate to all CMS Servers.

From the console enter the below.

webadmin listen a 445 (This allows the 1st Interface to listen of port 445 for the Web Administration portal. We keep this portal off port 443, as we will configure a Web Bridge later for internal webrtc clients.)
webadmin certs keyfile function_certificate cert_bundle (example: webadmin certs webadmin.key webadmin.cer chain.cer
webadmin enable

The CMS server will cross check the Key file matches the Certificate file, and then ensure the Chain Certificate is the actual signing CA Authority.

To validate the webadmin service.. Enter webadmin status.

Now browse to the https://cms1server.example.com.au:445

Cisco Meeting Server – Part 3: Certificates

By ben

Certificates are the next step in the CMS deployment. Now with version 2.7+ certificates are mandatory all to be signed by a CA. I’ve listed the functions below that we will generate CSR’s for. A brief description of how to generate the CSR is included. I find it easier to generate all CSRs from a single host, then have the IT Administrator sign all the certificates.. Then I’ll distribute the keys and signed certificates to the appropriate CMS Hosts.

I like to group certificate to functions. Yes, you can just issue a single certificate.. But again, I like to logically separate certificates to functions..

The general command to run is “pki csr function_name CN:cms-host1.example.com subjectAltName:cms-host2.example.com.au,cms-host3.example.com.au

Reboot each CMS Server after licenses have been applied.

Functions

WebAdmin – Standard certificate. I include ALL CMS Servers, including the EDGE (interface a) servers. Use the subjectAltName: attribute for the additional CMS Servers.
Call Bridge – Standard certificate. I will include only the CMS Servers that will host conferences.
Database Server – Standard certificate. I will only include on the CMS Servers that will share the Database.
Database Client – Specific CN for the certificate: CN:postgres Only enter this CN into the CSR. No subjectAltName attribute.
XMPP Server- This certificate will include all CMS Servers that will be a member of the XMPP Cluster. This certificate will also list domains for the organisation, including all domains in a multi-tenancy deployment.
Trunk – Standard certificate. Will include only the CMS Servers that are a member of the XMPP Cluster.
Load Balancing – Standard certificate. I will include only the EDGE servers.

The Chain or Root Certificate

The Cert Bundle is the Trusted Root Certificate. This is required when attaching signed certificates to the various components such as Web Admin. If there is only a single Root CA, then all you need to do is copy the Root CA cert to the CMS Servers via an SFTP client. Then simple reference the cert when activating a component. If there is also an Intermediate CA.. Then you will need to manually create a certificate bundle. To create a certificate bundle, open both the Root CA and the Intermediate CA certificates into notepad. Copy the text of both certificates into a new text file. Root CA text first, then next line add the intermediate certificate text. (no line break), then add a blank (space) line at the end of the file. Save this as a “.cer”. Copy this Root Chain certificate to the CMS Server. Then simply reference the chain certificate when activation components.

I use Filezilla FTP client to upload certificates, download CSRs and keys etc. All certificates, keys etc are loaded into the root directory on each CMS Server.

Run the command pki list to show a list of CSR’s, keys and certificates.

**NOTE: For certificates to be shared among the CMS Servers, copy the cert.key & the certificate to all required CMS Servers.

Cisco Meeting Server – Part 2: Licensing

By ben

All CMS Servers require a LIC-CMS-K9 host license. (Top Level SKU is R-CMS-K9). This enables Call Bridge, Web Bridge and TURN Server featurs. This is a zero dollar license from Cisco, that’s right.. You can deploy as many CMS VMs as you like.. However to allow conferencing you will need to purchase SMP+ or PMP+ licenses.

Quick run-down on the two licensing types:

SMP+ is a shared license. This license is invoked for all unknown users/owners that are hosting a conference within the CMS infrastructure.
PMP+ is a Personal Multiparty License. This license is assigned to users within the organisation. When a ‘licensed’ user hosts a meeting instead of a SMP+ license being used, a PMP+ license is granted. PMP+ licenses are included with the CUWL Meetings licensing type. Can be upgraded from CUWL Std or Pro.

How to Apply Licensing to CMS Servers.

Following the same typical process as you would for assigning PAK for the Part LIC-CMS-K9. You will need the MAC Address from the CMS. (cmd is ipv4 a). This will generate a cms.lic file for download. As mentioned above, this license will enable Call Bridge, Web Bridge and Turn Service.

Keeping with the first CMS Server, Next step is to assign the PAK for either SMP+ or PMP+. Exact same process as above. This will generate another cms.lic for you to download.

We can now install this cms.lic via an SFTP Client such as Filezilla. Simply drop the cms.lic file to the root of the CMS Server.

Process for Remaining CMS Servers

Moving onto the second and remaining CMS Servers.

First step is to again assign the Server PAK (Part LIC-CMS-K9) to the second CMS Server, you will need the MAC Address. A cms.lic file will be generated and available for download..

Next step is to share the additional features, in this case it’s the PMP+ / SMP+ licenses between the CMS 1 and CMS2 Server. To do this we navigate to the ‘Licenses’ tab on the Cisco Licensing Portal (traditional). Drop down the ‘Move’ menu and select Share -> Get Activation Code. Paste in the source MAC which is CMS 1′s MAC Address and Destination MAC being the CMS 2 MAC Address. Enter your CCO related email address to receive the activation code. Submit. An activation code will be emailed to the previously mentioned address.

Now we’ll copy this activation code and go back to the ‘Move’ menu and select Share -> Use Activation Code. Past the activation code and submit. The next page will list the additional licenses or feature you wish to share. Select the PMP+ / SMP+ feature and submit. This will generate a new cms.lic for CMS 2 server. Now simply follow the above process to add the license file to the CMS 2 Server via SFTP client.

Repeat the ‘Process for Remaining CMS Server’ for any additional CMS Servers.

Call Bridge Server with features (SMP+ and PMP+)
cms_license_1

Cisco Meeting Server – Part 1: Base Settings

By ben

I’ll be going through a scalable and resilient deployment in parts, as there is simply too much to get through in a single post. Some will also be applicable to single deployments. The CMS design is using three CMS Call Bridges and Expressway as the reverse proxy and video path. I will not be deploying an Edge Server in this design.. However, I’ll add on the Edge configuration after the blog series, as the CMA App still requires this infrastructure.

Start Virtual Server from VMWare, then log into CMS as username: admin and password: admin. The system will have you change the password. Select a secure password and confirm. We now have access to the console. Lets configure some basic connectivity and system settings.

Add IP Address to Interface ‘a’ – ipv4 a add ipaddress/prefix gateway_ipaddress
Add DNS Servers – dns add forwardzone . dns_server_ipaddress **The dot represents ALL Domains.
Add NTP Servers – ntp server add ntp_server_ipaddress
Add Hostname (Reboot required) – hostname name_of_CMS (exclude the domain suffix)
Add Timezone (Reboot required) – timezone Australia/Sydney. (timezone list, shows you all the Timezones available to use if you’re not in Aussie Land)

To validate above settings run the below commands

Validate IP Address and Gateway -> ipv4 a
Validate DNS server and forward zone -> dns
Validate NTP server and sync -> ntp status
Validate Timezone -> timezone

**Note**

CMS passwords expire after 6 months by default. Hence, I also like to set the password age to the max 9999. Below is how to achieve this.

Firstly display the current password age/expiry

>user info admin

Configure the new password age rule (global)

>user rule password_age 9999

We then have to reset the admin username’s password for the password age rule to take effect.

>passwd admin
>ENTER THE PASSWORD FOR THE ADMIN ACCOUNT

Confirm the password age for the admin account

>user info admin

SPA122 and CUCM Registration How-To…

By ben

Configuring an SPA122 for CUCM, quick guide.

Connect Network Port to Laptop, default IP is 192.168.15.1
Browse to the web page. Default login is admin and password admin
Navigate to Network Setup -> Internet Settings
Complete the IP Details for the SPA122 device to connected to the network. The Internet Port is used for SIP Signalling, registration and media.

spa-122-1

Optional Settings for Domain Name and DNS.. Are also recommended.

Navigate to Voice – > Line 1

Scroll down to the Proxy and Registration Section

spa-122-2

Scroll down to the Subscriber Information Section
Complete the below fields

Display Name
User ID
Password
Enable Auth ID
Auth ID

spa-122-3

Submit

CUCM Configuration

Create an Enduser. *User ID must only be in numerical format.. Not characters permitted.
Set the Digest Credentials
Set the Telephone Number

Create a Third-party SIP Advanced Device.

Standard Phone setup.. With the exception for the below.

- Set the Owner ID to the above created User
- Set the Digest User to the above created User

The SPA122 should now successfully register to the CUCM Cluster.

Session Timer Too Small – ITSP

By ben

Receiving a Session Timer too small from the ITSP (SIP/2.0 422 Session Timer too small)?

INVITE FROM ITSP

SENT TRYING

SENT INVITE TO CUCM

RECEIVED TRYING

RECEIVED SESSION TIMER TOO SMALL

CALL FAILED

CUCM has a min session timer of 1800. By default the CUBE will accept any negotiated size for the session timer. Hence we need to ensure the session timer is negotiated correctly with the ITSP before handing onto CUCM.

 *** Required Changes on the CUBE ***

Router(config)# voice service voip

Router(conf-voi-serv)# sip

Router(conf-serv-sip)# min-se time

 *** After the above change ***

INVITE FROM ITSP

SENT TRYING to ITSP

SENT SESSION TIMER TOO SMALL to ITSP

RECEIVED INVITE (with session timer of 1800) from ITSP

SENT TRYING to ITSP

SENT INVITE TO CUCM

RECEIVED TRYING FROM CUCM

RECEIVED CALL IN PROGRESS (Ringing) from CUCM.

Call succeeded.

Cisco Unified CM SIP Route Patterns

By ben

SIP Route patterns in CUCM allows the system to route SIP URIs to a predefined destination.. Mostly toward to the Collaboration Edge environment. To cover all possible URI formats use the below configuration.

Note: CUCM doesn’t allow to cover the entire IPv4 Range in one expression. The work around is to split into two expressions as per image below. (1.0.0.0/1 & 128.0.0.0/1)

SIP Route Patterns

Cisco Meeting Server – CMA ‘Copy Weblink’

By ben

You might be wondering where the Copy Weblink is in the CMA Invite Menu, or why can’t participants just click on my ‘join’ weblink and be connected straight into my meeting room.

Simple explanation.. The ‘Web Bridge URI’ field on the WEB Admin GUI is blank. That’s it.. However, for you Multi-Tenancy deployments.. Unfortunately there is a limitation! Only one URL can be defined, as this setting is required to be done via the WEB Admin GUI.

In a multi-tenancy case, users will have to forgo this ‘Copy Weblink’ etc and simply have the ‘https://join.tenant_domain.com.au’ listed in the invite, requiring participants to enter the Meeting ID to connect into a meeting room

cms-web-link-1

TMS Repeatedly Dialling PSTN Numbers with CMS

By ben

Has a very interesting problem with TMS and CMS integration piece. For any TMS meeting scheduled with dial out participants when the participant phone number had a zero prefix (Australian Standard for PSTN breakout), the TMS / CMS system would repeatedly dial the participant, even though the participant had already accepted the first TMS/CMS call out and had successfully joined the meeting.

This only occurred for phone numbers with a zero prefix. Hence phone number with +61 formation, or the straight 10 digit (again based in Australia).

Explanation

In CMS I have configured for user to dial a phone number using any standard means.. Straight 10-digit number, prefix with zero, plus e164 format, extension etc.. So catching all of the users dialling behaviours and making sure they route.. I transformed all of the above different dialling behaviours to a standard plus e164 format.. So essentially globalising the dialled number.

Any number leaving CMS is in a plus e164 format. Easy for the CUCM guys to manage routes.

TMS dialled number was in a zero prefix format. Example 00408842… so worries… TMS would make an API call to CMS to create a callleg for the above number. CMS would transform the number into a plus e164 number. So the number would become +61408842… CMS would route this to CUCM for PSTN breakout. CUCM would then localise the number into a compliant Telco format. The number now became 0408842…

The call would be dialled.. The participant would answer and be joined the CMS Meeting.. All good you say.. Well not quite yet.. While CMS had confirmed that indeed the participant had joined the meeting.. TMS never received such confirmation..

After CMS dials out to the participant, TMS will then send a GET request to CMS asking if a Call Leg has been established for the participant dialled. To break this down TMS sends a GET /api/v1/callLeg filter with 00408842… (notice this is the number TMS sent to CMS to be dialled originally). However.. CMS has no such Call Leg… TMS, then resends a POST request to CMS to create a Call Leg for the 00408842… so CMS the dials out to the participant again. The participant receives another call, even though they are already in the meeting!

This happens multiple times until TMS gives up.. (configurable).

Why is this So?

CMS contains a couple of key pieces of information in the Call Leg.

1. RemoteParty
2. OrginalRemoteParty

Remote Party is the connected Called Party ID. Remember how I was saying CUCM (or the CUBE) will localise the called number to comply with Telco Standards.. The CUCM (or CUBE) will send back the connected called ID to CMS.. This is then documented for the RemoteParty ID.

Original Remote Party ID is the dialled number from CMS to CUCM. Essentially this is the ‘Transformed’ number.

Following my case above.. The CMS Call Leg will have the below

remoteParty = 0408842…
orginalRemoteParty = +61408842…

By now, you’re probably putting the puzzle together.. The number TMS requested to be dialled is no where to be seen in the Call Leg, hence TMS believes the participant did not join the meeting (based in the results of the GET callLeg request by TMS), so TMS attempts a redial.

The Fix (for now)

To resolve this issue, allow the dialled number from TMS to be passed through CMS without transformation onto the CUCM Server. This reflects in the Original Remote Party field as being the number that TMS dialled.. Hence the GET request for TMS matches the dialled number.

Saving WAV Files for Cisco Meeting Server with Audacity

By ben

With audacity you can modify WAV files for the Cisco Meeting Server.. The important notes are the file must be under 500KB and be saved with ‘WAV (Microsoft)’ as type and Encoding to be Signed 16-bit PCM.

One important note to make aswell in regards to the wav file ‘only_participant.wav’. Cisco CMS will repeat this message continuously with no breaks for AUDIO ONLY callers. The default ‘only_participant.wav’ file is padded with 10 seconds silence. So…. We also need to pad the WAV file for 10 seconds.. (more if you like), otherwise audio callers will be driven crazy waiting for someone else to join the conference.. Again.. This only impacts audio only callers.. Video callers only hear this announcement once.

cms-wav-files

Troubleshooting CMS Webrtc Connections – Incorrect Username/Password

By ben

cms-webrtc-tshoot1

You receive this error when you attempt to log into your personal space via the “Sign in” button and also when you attempt to join a meeting as a Guest.

The XMPP Server is guy who will authentication users, whether they be local domain users or guest users.

With Guest users. The web bridge sends the call bridge instructions to create a temp guest user account, the call bridge creates this account, then send the web bridge the username/password details.. The Web bridge, then will contact the XMPP Cluster to verify authentication for the newly created guest user.. As you can see below capturing packets on the EDGE device.. The port TCP 5222 is being blocked toward the XMPP Cluster.

Cisco Document references the below ports only.

cms-webrtc-tshoot2

cms-webrtc-tshoot3

cms-webrtc-tshoot4

Cisco Expressway – CPL Reference to Block Toll Fraud

By ben

Quick reference for CPL rules to close all potential toll fraud calls. (Australia)

Single Domain reference below. For multi-domain environments, will just need to duplicate for each. Be careful of the order.

Please reference the image below, but essentially we allowing:

- Ben.morgan@domain.com.au
- ben@domain.com.au
- ben1@domain.com.au
- Ben.morgan1@domain.com.au
- 3 digit extension@domain.com.au
- Full 10 digit number@domain.com.au
- E164 number@domain.com.au

Block everything else.

expressway-cpl

If anyone has additional expressions to add in case I missed one.. Please add a comment.

Cisco Meeting Server – LDAP Discussion

By ben

Crikey.. All these API commands, recently have been doing a couple of CMS deployments.. And literally have to jot down my most used commands.. aswell as most used IDs.. Can be very tedious to configure then look back at what you have configured!

Thought I would jot down here the commands I most use.. More for my memory as I know more deployments will come my way.. And rather than cross referencing the API continuously.. well you get my drift..

LDAP is a killer.. Customers always seem to create their own variation of standardised ldap fields.. I reckon its just to keep guys like us on our toes..

LDAP API Commands

GET: /ldapservers – displays all ldapservers to go deeper, copy the ldapserver ID and paste it to the end of the above API string.. This will now show all fields for that ldap server connection. Note: you best copy this server ID somewhere safe, as you’ll need it later.

GET: /ldapmappings – this seems never ending when first trying to sync to an organisation’s LDAP..fields most used are , this is the authentication mapping. ie username for the CMA/webrtc client. REMEMBER to configure the XMPP Domain on the CMS and to create a _xmpp-client._tcp.domain 5222 SRV record.

GET: /ldapsources – if you thought ldapmappings was never ending.. you’ll quickly get used punching this little bugger in.. Main culprit is the filter field to ensure you’re only bring across the users required.. One organisation can have multiple ldapsources dependind on what userprofiles are to be assigned to users.

POST: /ldapsyncs – Yes finally we sync to LDAP.. You may need to enter this string a million times over before all the above settings are finalised and users have been successfully imported.. And then.. You’ll enter this string another million times for changes that need to be made..

*Handy Tip*
To remove LDAP users.. Simply delete the ldapsource, then run the POST: /ldapsyncs again…

Ok so what do the fields mean..

Ldapserver

<address> = the ldap server IP Address
<port> = port used to connect to ldap. Mainly 389 but can use 3268 if need be.
<username> = This is the service account used to access ldap user records. This must be in a CN path format. Eg. CN=service_user,OU=IT,DC=domain,DC=com
<password> = Password for the service account.. NOTE: this field does not show when running a GET: /ldapserver.
<secure> = whether you want a TLS Ldap connection or leave unsecure.

LdapMapping

<jidMapping> = This is the authentication string for users. The @domain MUST match one of your XMPP Domains configured. Example format is $sAMAccountName$@meet.domain.com.au NOTE: you can also insert any AD attribute here if the sAMAccountName is not to your liking. I like to try and the organisation’s email prefix as a standard.. So sometimes I will use $mailNickname$@meet.domain.com
<nameMapping> = This displays a friendly name for the user in the CMS System. Typically used is $giveName$ $sn$
<coSpaceNameMapping> = This is the display name for the user’s meeting space. Typically used is $givenName$ $sn$’s Meeting Space
<coSpaceUriMapping> = This is the meeting space’s URI prefix. IMPORTANT: This cannot be the same as the <jidMapping> prefix. So typically the URI would be $mailNickname$.space or $sAMAccountName$.space. Get the picture.. append a “.space”.
<coSpaceCallIdMapping> = This is the Meeting Room Number. This code is entered in when someone joins via an IVR or the Weblink. If you do not complete this field.. The CMS system will automatically generate a Call ID for you. NOTE: This field MUST be unique across the organisation AND… across ALL tenants configured on the system. If you can get away with using an extension number and all ldap accounts have a unique extension number (highly unlikely) use this.. Easy for the user to remember.. BUT as with most case.. A system generated Call ID is your only option.

LdapSource

This is where we tie everything together to essentially create profile for the ldap sync.
<server> = This is the ldapserver ID from previous steps.. Paste it in here
<mapping> = this is the ldapmapping ID from previous steps.. Paste it in here
<tenant> = if you are configuring multi-tenancy.. Well paste the tenant ID in here.
<baseDn> = This is the base ldap search path.. ALL users must be within this path. This doesn’t mean you want to import all users in the path.. That is what the “filter” is for.. Example is OU=Users,DC=domain,DC=com
<filter> = This how we specify ‘who’ exactly we want to import. Maybe its just an OU? Maybe its only members of a particular security group. Or only users with a telephone number.. You get my drift.. A couple of examples

Member of Group called ‘CMS’ = memberof=cn=CMS,ou=security,ou=groups,dc=domain,dc=com
Member of Group called ‘CMS’ AND have a mailNickname AND Telephone configured = (&(mailNickname=*)(telephoneNumber=*)(memberof=cn=CMS,ou=security,ou=groups,dc=domain,dc=com))
Users who have a Telephone Number, but who are not a member of the security Group called ‘CMS’ = (&(telephoneNumber=*)(!(memberof=cn=CMS,ou=security,ou=groups,dc=domain,dc=com)))

Why would we need to exclude a Group for? Maybe we only want to attach a PMP+ license to a specific Security Group? And the remaining users to share SMP+ licenses. In this case we would create TWO ldapsources.. One ldapsource with a filter matching all users but excludes users in a security group. Then the other ldapsource to filter only users in the security group. On this ldapsource we will also attach a ‘userProfile’. A userProfile allow us to apply a PMP+ license to users.
<userProfile> = Paste in the userProfile ID. (create a userProfile and attach the ‘haslicense’ to the profile)

LdapSyncs
We POST to this string.. With no Body everytime we want to sync to ldap.. At this stage there is no schedule we can apply. The option is to create a python script to run the ldapsync on a schedule.. I’ll leave that up to you. But, please post any scripts here for others to use or improve on.

2N GSM Gateway Voice Blue Configuration

By ben

As I get a few requests to setup GSM gateways for backup purposes and for mobile to mobile calling.. I always find that I have to sift through doco and click on boxes and to navigate the GSM configuration portal. I thought I would share a quick run down of a basic set of configuration for outbound and inbound calling.

Scenario to configure..
1. Use 2N GSM Gateway for backup purposes only.
2. Outbound calls to use all 4 SIMs and have called ID enabled.
3. Inbound Calls to be directed to the Reception, and also have all 4 SIMs available to use.

So we’ll start from the very beginning.. Crack open the GSM gateway and plug it into your LAN.. I normally direct connect it to my laptop initially. The default IP Address is 192.168.1.2/24.

Log into the gateway with the username: Admin and password is 2n.

There isnt too much to configure here.. Its just knowing where to go to get the gateway up and running.

Lets head to the Gateway Configuration Menu (Left), then select Voip Parameters. Here we will want to enter the IP Address of your CUCM Servers. I have entered for both fields IP->GSM and GSM->IP as I have the requirement to setup both outbound and inbound calling.

I also selected English for the VOIP Ring Tone.

2n-1

Next is to ensure the Ring Tones are set correctly.. Default is set to European.. So that sound a lot different us Aussies. I set this to English for both Dial tone and Ring tone.

2n-2

Onto the GSM Groups Assignment. By default all SIMs are placed into Group 1. I will leave this for my scenario.. However, you can dedicate SIMs for either outbound or inbound calling.

2n-3

Lets jump down to Prefixes. Simply put, Prefixes allow for normalisation of called numbers. This is exactly what I need to do, as the GSM Gateway will receive Called Numbers from CUCM with a Zero (0) prefixed.. We need to remove the Zero before we dial out to the Telco network. The below image depicts just that. I’m removing the Zero and replacing with ‘nothing’ essentially.

2n-4

Ok, lets move onto GSM incoming groups. This is where we can configure some inbound functions. In my scenario, I need to direct all calls to the Reception Phone. Firstly, I need to drop down the ‘Mode’ box and select “Accept incoming call + dialtone”. The 2N GSM Gateway by default will reject all calls from the GSM network.

Next, I modify the DTMF dialling timeout field. Default is 10 seconds.. I change tis to 0 seconds. This will not wait for any dtmf digits to be pressed and forward the call onto the List of Called Numbers. (below image). Now this takes us to the List of Called Numbers, essentially all inbound calls in this group will call in a sequential order any number in the list. Just make sure this number exists in CUCM.

2n-5

2n-6

Now of course, I always recommend changing the default password.. I’ll let you figure that one out.

That’s it for the GSM Gateway side of the story.. I leave with a couple if useful features on the GSM Gateway.. Its packet capturing and making test calls both toward the GSM and CUCM. Self explanatory so if you get stuck, these two tool will definitely come in handy.

2n-7

Now onto the Cisco CUCM Side.

Start by creating a new SIP Trunk Security Profile. You can just copy the standard non secure security profile. Ensure the Outgoing Protocol is UDP. Also see below for the checkbox enablement.

2n-8

Next, lets create a SIP Trunk. Nothing fancy here. Just make sure you have the required fields configured along the below fields.

- Calling Search Space
- Destination Address
- Sip Profile
- SIP Trunk Security Profile

Create a Route Group and add the new created SIP Trunk. You can also edit an existing Route Group if you wish.

We then need to create a Route List, we add the Route Group we create in the previous step the this Route List. Forget this step if you have simply added the SIP Trunk to an existing Route Group.

Create a route pattern and select the Route List above.

Remember to Reset the Trunk!

Now make some test calls..

Cisco CMS Ad-Hoc Conferencing with CUCM

By ben

For those interested.. A short article of configuring CMS as an Ad-Hoc Conference resource in CUCM.

NOTE: prior to CUCM 11.5 SU3 TLS used is version 1.0. CMS 2.3+ uses TLS 1.2 by default, so to allow pre 11.5 CUCM versions to connect to CMS.. We need to set the minimum TLS version via MMP.

Commands are:

tls webadmin min-tls-version 1.0
tls sip min-tls-version 1.0

For CUCM to use CMS as an Ad-Hoc conference bridge we need to configure a user on CMS with the API role associated. CUCM essentially creates a temp conference space for the ad-hoc conferences.. CUCM does this via HTTPS using API strings.

Commands to configure a User on CMS

User add username api
The MMP console will ask you to set a password.

Lets remain on CMS, and log into the Web Admin portal. We now need to configure Incoming Call Settings. This will allow calls to enter and terminate on the CMS Server. CUCM will add the SIP Trunk Destination Address as the suffix/domain to all calls for ad-hoc conferences. So we need to configure the SIP Trunk Destination Address into the Incoming Call Handling page on CMS.

Incoming Call Settings

cms-ad-hoc-2

Now we turn to the CUCM Server. First step is to upload the certificate chain that signed the ‘Web Admin’ service certificate to the CUCM as CallManager-trust.To find out which trust certificate to use you can jump back on the MMP for CMS and run the command ‘webadmin’ and look for the ‘CA Bundle File’. Jump into your SFTP client and download the CA file to you PC.. ready for upload to the CUCM Server.

Once uploaded, navigate to Media Resources and Conference Bridge and select ‘Add new’.

Complete the following fields on the conference bridge configuration page.

Conference Bridge Name = Nothing special here.. Just assign a logical name for the conference bridge.
Description = Again.. Something logical always helps
Conference Bridge Prefix = If you have multiple CUCM Clusters linked to CMS or multiple CMS Call Bridges, you will need to apply a prefix. This mitigates the risk of two CUCM Servers from two difference clusters creating a temp ad-hoc conference with the same conference ID. If there are two Call Bridges, you must then create a conference bridge resource for each with a different prefix. This will assist with load balancing issues (Load balancing across two or more Call Bridges is not supported in the Ad-Hoc Conferencing setup).
SIP Trunk = Select the CMS SIP Trunk, which will also be referenced below.
Override SIP Trunk Destination as HTTP Address = checked.
Hostname/IP Address = FQDN of your CMS Server..
Username = enter the username create in the above steps
Password = self explanatory..
Use HTTPS = checked.
HTTP Port = This is the port you have configured for the Web Admin Server.. I use 445 in this case, default is 443.

Save, then we reset the bridge. Should now show as registered. You can add the Conference Bridge to your select MRGs and MRGLs for testing.

cms-ad-hoc-3

cms-ad-hoc-4

Create a Lecture Mode Space – Cisco CMS

By ben

Essentially we are creating a single meeting space with multiple access methods. ie the Speaker/Presenter will connect to the meeting space via a separate access method to a student or participant. It is through this means, we can apply or attach policies in the form of Call Leg Profiles, so when a student joins the meeting space we can have policy enforcing Mute Only for example.

Below it the process to creating a Lecture Only Room

Create the Call Leg Profiles

These profiles will determine what type of features or access the participants will have when they connect into a conference.

Presenter Call Leg Profile

POST /api/v1/calllegprofiles

Body

needsActivation = false
Name = Presenter
defaultLayout = allEqual

Guest – Muted Call Leg Profile

POST /api/v1/calllegprofiles

Body

needsActivation = true
Name = Guest – Muted
defaultLayout = speakerOnly
rxAudioMute = true
rxVideoMute = true
deactivationMode = deactivate

We need to retrieve both Call Leg Profile ID’s for use later.

GET /api/v1/calllegprofiles

Create the Meeting Space.

Now we create a space, name the space something meaningful and friendly to read.

POST /api/v1/cospaces

Body

Name = Class Meeting Space

Retrieve the Meeting Space ID

GET /api/v1/cospaces

Create the Access Methods

Once the space has been created, we will create two access methods (one for the Speaker or presenter and one for the students). We will attach the above created call leg profiles to their respective Access Method.

Access methods are appended to the cospace API string. Example.

https://cms_server.example.com.au:445/api/v1/cospaces/866aadfd-6ff4-43ca-ae0d-3aab6711c598/accessmethods

POST /api/v1/cospaces/cospace_ID/accessmethods

Included below is a Call ID, however you can also specify a SIP URI to call directly into this space, can also add passcode (PIN) to access to the meeting

Presenter Access Method

Body

callId = 1234
callLegProfile = 9a491602-851a-46c4-a2c9-9f144c1a53e9 (Presenter Call Leg Profile ID)

Guest – Muted Access Method

Body

Uri = guest.mute
callId = 5678
Passcode = 11111
callLegProfile = ed5834e4-c2fc-43b1-a703-2394b8e4d200 (Guest Call Leg Profile ID)

Now when a participant connects to the Meeting Space via the Call ID 1234, they will join the meeting without activation and be permitted to send/receive video/audio. However, if a participant connects to the Meeting Space using the Call ID 5678 (or the URI guest.mute@example.com.au), they will sit in the ‘Lobby’ until the presenter joins the meeting. When the participant does join into the meeting, their system will be muted for both video and audio. In addition, their screen will only ever show the active speaker.

❌