Jul 26

Webex Calling – User Calling Data Bulk Edit Notes

Righto, lets talk about some quirks with WxC User Calling Data bulk editing. Coming from a Cisco CUCM side of the fence, I configure User and Device Data from spreadsheets. It’s amazingly quick, contains all the fields you need and can easily add/replace and delete data all in a single upload.

Since shifting my focus to Webex Calling, I swiftly leaned into to how to effectively bulk edit objects as configuring every entry on the GUI is simply not feasible. I’ve found this bulk edit process vs CUCM bulk edit process to considerably different. Not sure yet, if the differences are for the better! Lets go through a couple to start the conversation.

The WxC Bulk Edit process involves using key words in cells to manipulate data. These words or commands as such are ‘ADD’, ‘REPLACE’ and ‘REMOVE’. To explain myself better lets follow the below scenarios that we find ourselves in.

We have a requirement to limit the BLF monitoring for User A to three users. So, we will need enable Privacy and add three users to the permissible list. The below image depicts the CSV fields to populate for such a change. We can see the “Privacy Selective Line Status Enable” set to ‘TRUE’ and then “Privacy User Action” is set to ADD, then we have specified the three users who will have permission to add User A’s DN as a BLF. This will give us the outcome we are after.

wxc-bulk-edit-2

wxc-bulk-edit-1

So all good thus far, however once we start receiving requests to modify these list, this is where we can start to see the difference between CUCM bulk edit and WxC bulk edit. Lets say we have a request to remove ‘Simon Zhu’ from the list and add ‘Jessie Cu’ to the list. Let s go through the process.

Due to the limitation of the command words such as ‘ADD’, ‘REPLACE’, ‘REMOVE’ we will need to upload the CSV a couple of times.. One for each type of change. First change is to REMOVE ‘Simon Zhu’. The CSV will resemble the below image. We can see the ‘Privacy User Action’ field is now set to ‘REMOVE’. We can also verify that we had to remove/delete the names for ‘Long and Hoai’ from the fields. Hence, we are left with only ‘Simon Zhu’ specified on the CSV. Once we upload this CSV to WxC, we can see infact ‘Simon Zhu’ has been removed with ‘Long and Hoai’ remaining with BLF permissions.

wxc-bulk-edit-3

Now we need to get back onto the CSV and make further changes to add ‘Jessie Cu’ to the Privacy List. Below Image depicts this information. I have purposely left ‘Long and Hoai’ from the list, this seems to not affect the adding of users.

wxc-bulk-edit-4

In contrast to CUCM bulk edit, where we could simply delete ‘Simon’ and replace with ‘Jessie’. Then upload the CSV. Effectively, whatever the CSV file has populated is essentially the configuration outcome. Now you must be asking yourself, “What about the REPLACE command?” Wouldn’t the REPLACE command simply follow the same logic. Unfortunately not. If you were to attempt the above mentioned change with the REPLACE command, all that simply happens is ‘Jessie Cu’ is added to the Privacy List and ‘Simon Zhu’ also remains. See images below.

wxc-bulk-edit-5

wxc-bulk-edit-6

Hence, we would have to edit the CSV file again to enter the ‘REPLACE’ command and only have ‘Simon Zhu’ showing in the CSV. The re-upload to make effective.

CUCM Bulk Edit vs WxC Bulk Edit, my humble opinion is with CUCM. However, I’m aware WxC is still in its early days.. And as we know, CUCM maturity also took years. Only good things to come!

Apr 28

Active Control and Cisco Meeting Server – Mute

Cisco Meeting Server provides a more feature rich conference environment with Active Control enabled. Not only the does the CMS Server need the SipUDT flag enabled (enabled by default), the Call Leg Profiles needs to have the feature enabled, the codecs need meet firmware versioning minimums and have the Active Control flag set to Auto as well as CUCM will need to have the relevant SIP Profiles sending the Xi Parameter for Devices and Trunks. Tracing Active Control is done via SIP and Active Control XCCP Packets, I’ve outlined below some key components to tracing Active Control Features. Below is an example of the Codec Muting and Unmuting itself. The unmuting will reflect the change in the rxAudioMute flag on the CMS Server, which is turn reflects the Microphone Unmuting in the CMM Management Screen. Also, worth to note, the below output is also based on ‘Linked’ Mute Behaviour as opposed to ‘Separate’ Mute Behaviour.

Scenario:

  • Multiple Call Bridges in a single Call Bridge Group with Load Balance enabled
  • Cisco SX20 Codec operating 9.15.X firmware.
  • Call Bridge version is 3.2.1
  • CUCM version 14 SU2
  • Direct routing between CUCM and CMS
  • Call Leg Profile is set as below
    • rxAudioMute = True (Mute on entry)
    • muteSelfAllowed = True (Allow Codec to unmute/mute as required)

Call Flow:

Codec -> CUCM -> CMS -> CMS

Codec dials into Space directly, CUCM sends a Delayed Offer to the landing point is which is CMS01. Load Balancing is then conducted, CMS02 Call Bridge is voted to host the conference. CMS02 then places an outgoing call to the Codec, hence sends a SIP INVITE to the CUCM. CMS01, will CANCEL the original SIP INVITE from the Codec/CUCM.

So, the within the SDP, there should be a couple of attributes to the tune of..
m=application 30419 UDP/UDT/IX *
a=ixmap:0 ping
a=ixmap:2 xccp

This is the Active Control negotiation within the SDP. If these lines are not present, then CMS is not enabled for Active Control. Vise versa.. If CUCM sends the 200 OK SIP Msg without the above attributes, then CUCM Sip Profiles do not have Active Control configured.

Active Control Tracing on the CMS will not show the Active Control State of the call via the b following line ‘ActiveControlState change, unknown -> negotiating’.

<?xml version=”1.0″ encoding=”UTF-8″?>\n
TX: <request type=”subscribe-capabilities” id=”1″>\n
TX: <subscribe-capabilities min-interval=”5″>\n
TX: <expires>1800</expires>\n
TX: </subscribe-capabilities>\n
TX: </request>\n
call 4942: need to start new conferencing link for XCCP
call 4942: starting up conferencing link for XCCP
call 4942: starting up conferencing link user for XCCP
call 4942: incoming XCCP message, size 197:
RX: <?xml version=”1.0″ encoding=”UTF-8″?>\n

Active Control Feature and Capabilities will now be negotiated between the CMS Call Bridge and the Codec.

CMS Call bridge will not set the feature capabilities upon the Codec. Below snippet is the Call Leg Parameter ‘rxAudioMute’ being pushed down to the Codec. (Also, within this same xml msg, the parameter ‘rxVideoMute’ is also pushed down to the Codc)

call 4942: outgoing XCCP message, size 684:
TX: <?xml version=”1.0″ encoding=”UTF-8″?>\n
TX: <notify type=”acked-self-info” notifyId=”4″>\n
TX: <self-info>\n
TX: <user id=”e0d5c105-5b68-44bd-85a6-3c3b2f23a749″ entity=”91021@justice.nsw.gov.au”>\n
TX: <display-text>SYD-DOWN-MULTIMEDIA-MR1- 91021</display-text>\n
TX: <recording>false</recording>\n
TX: <deactivated>false</deactivated>\n
TX: <endpoint entity=”91021@justice.nsw.gov.au”>\n
TX: <status>connected</status>\n
TX: <joining-method>dialed-out</joining-method>\n
TX: <capture-source-id>19416111</capture-source-id>\n
TX: <media id=”1″>\n
TX: <type>audio</type>\n
TX: <status>recvonly</status>\n
TX: </media>\n

TX: <media id=”2″>\n
TX: <type>video</type>\n
TX: <status>recvonly</status>\n
TX: </media>\n
TX: </endpoint>\n
TX: </user>\n
TX: <count>\n
TX: <visible>0</visible>\n
TX: </count>\n
TX: </self-info>\n
TX: </notify>\n

At this point, the Codec has successfully joined the Conference, the Call Bridge has set the relevant features upon the Codec. The Codec has been Muted both Audio and Video.

The Meeting Room Operator, can now press the Mute Button on either the Touch 10 or an external Microphone to unmute the Codec.  Below is snippet for the XML Msg sent to the Call Bridge from the Codec.

call 4942: incoming XCCP message, size 225:
RX: <?xml version=”1.0″ encoding=”UTF-8″?>\n
RX: <request type=”self-mute” id=”7″>\n
RX:   <self-mute>\n
RX:     <endpoint entity=”91021@justice.nsw.gov.au”>\n
RX:       <media id=”1″ media-allowed=”sendrecv”/>\n
RX:     </endpoint>\n
RX:   </self-mute>\n
RX: </request>\n

The Call Leg parameter ‘rxAudioMute’ is not set to false and the CMM Server will indicate the Mute is now off from the Codec.

Further Notes to Muting/Unmuting behaviour with Active Control. The CMM Server cannot unmute the Codec. If you attempt to unmute via CMM Console, the microphone icon will switch off for a couple of seconds, then switch back on indicating the microphone is muted again.

Jan 21

Upgrading to Cisco Meeting Server 3.5+

Key notes for upgrading to CMS 3.5+ from 3.4 and earlier is to ensure the database cluster is dissolved prior to the upgrade event. Cisco have introduced enhanced security for the Database Cluster from version 3.5.

Key steps is to firstly identify which CMS Nodes are in the database cluster and also which node is the current Primary Node.

Take backups of all CMS Servers prior to making any changes.

Log into the clustered peers and issue the “database cluster remove” command. After each peer is removed, log into the current Primary Node and issue the “database cluster remove” command.

Now the upgrade can take place for each CMS node.

After each CMS Node has been upgraded successfully to 3.5+, the database cluster will need to be re-established.

Log into the Current Primary Node as noted above and issue the command “database cluster initialize”.

Now log into the remaining CMS Nodes and issue the command “database cluster join IP_Address_of Primary_Node”

One last step is to update the schema. Issue the command “database cluster upgrade schema” from the Primary Node.

Jan 15

Finesse Agent Cannot View Live Widgets

New Agents receiving an Operation Error when logging into the Finesse Client. Specific error for information is “???33??? Finesse.utilities.l18n.getString(): invalid_getMsg”

 Note the process for creating UCCX Agents was not changed from previous new Agent creations.

 Found the CCX system may have been hitting Bug ID:CSCvk65545.

I forced a data sync from CUIC to CCX Server as per the Bug ID workaround. Agent continued to receive the error. Next step, was to log into CUIC and manually changed Agent permissions to read/execute live widgets for Finesse.

This resolved the issue. Essentially, new Agents are not being placed into the Agent Group in the CUIC Server, hence the Agent did not have required permissions to view/open the live widgets on the Finesse Agent Screen.

Below are the snippets of the Error display also the CUIC Screens I navigated to resolve the issue.

Agent_Finesse_Error CUIC-Error-1 CUIC-Error-2

Jan 13

Managing Certificates for Clustered Expressway Devices

Quick note on deploying/renewing certificated for clustered expressway devices, whether it be EXP-C or EXP-E devices. Typically, you will want the same SAN Certificate loaded onto each Expressway device. Outlined below is the process to deploy a single SAN certificate for each node in the cluster.

Primary Node Certificate Deployment

Follow the recommended certificate generation process for the first Expressway node. Generate a CSR on primary Expressway, ensuring to  include cluster name and all peer names. Add additional names into the CSR as required. Typically you will need the domain name for MRA and “Join” FQDN for CMS WebRTC.

Have the CSR signed by a public CA. (or Internal in the case of an Expressway-C Device). Download the Server Certificate and Chain.

Install the chain certificates first onto each Expressway Node, then install the server certificate onto the Primary Expressway-E. A reboot is required to complete the process.

Using the same certificate for the secondary and remaining cluster peers.

Using WinSCP, log into the Primary Expressway-E device using the root account.

Navigate to the directory Persistent>certs and copy/download the file ‘privkey.pem’. This is the Private Key.

 

Cisco Expressway Private Key Location

 Log into the Secondary Expressway-E nodes and upload both the Private Key and Server certificate together. (As mentioned above, ensure the Chain Certificates have already been uploaded.)

exp-certs-2

Repeat for each additional Cluster Peer.

Nov 01

Cisco Meeting Server – Part 8: Call Bridge Groups

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

Oct 20

Cisco Meeting Server – Part 7: Call Bridge Cluster

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

Oct 08

Cisco Meeting Server – Part 6: Call Bridges

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.