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.
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
4. Next we enable load balancing for the Call Bridge Group.
PUT -> api/v1/callbridgegroups/callbridgegroup_id
BODY -> loadbalancingEnabled = true
BODY -> loadbalancOutgoingCalls = true
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!
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.
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)
callbridge listen a
callbridge certs callbridge.key callbridge.cer chain.cer
*Repeat all Call Bridges
The base call bridge service has now been setup for each call bridge.
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 localnode a (We are specifying the CMS network interface for the DB to use)
Now Join each of the Slave Database Servers to the database cluster
Upload via SFTP the below certificate files
The above files were generated under the Certificates section. These files will be shared among CMS Servers.
database cluster localnode a
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.
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
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
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.
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.
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.
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
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.
>ENTER THE PASSWORD FOR THE ADMIN ACCOUNT
Confirm the password age for the admin account
>user info admin
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.
Optional Settings for Domain Name and DNS.. Are also recommended.
Navigate to Voice – > Line 1
Scroll down to the Proxy and Registration Section
Scroll down to the Subscriber Information Section
Complete the below fields
Enable Auth ID
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.
Receiving a Session Timer too small from the ITSP (SIP/2.0 422 Session Timer too small)?
INVITE FROM ITSP
SENT INVITE TO CUCM
RECEIVED SESSION TIMER TOO SMALL
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-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.
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. (184.108.40.206/1 & 220.127.116.11/1)
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
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).
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.
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.
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.
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.
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:
- 3 digit email@example.com
- Full 10 digit firstname.lastname@example.org
- E164 email@example.com
Block everything else.
If anyone has additional expressions to add in case I missed one.. Please add a comment.
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..
To remove LDAP users.. Simply delete the ldapsource, then run the POST: /ldapsyncs again…
Ok so what do the fields mean..
<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.
<jidMapping> = This is the authentication string for users. The @domain MUST match one of your XMPP Domains configured. Example format is $sAMAccountNamefirstname.lastname@example.org 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 $mailNicknameemail@example.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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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..
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.
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
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.
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
needsActivation = false
Name = Presenter
defaultLayout = allEqual
Guest – Muted Call Leg Profile
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.
Create the Meeting Space.
Now we create a space, name the space something meaningful and friendly to read.
Name = Class Meeting Space
Retrieve the Meeting Space ID
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.
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
callId = 1234
callLegProfile = 9a491602-851a-46c4-a2c9-9f144c1a53e9 (Presenter Call Leg Profile ID)
Guest – Muted Access Method
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 firstname.lastname@example.org), 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.