CiscoWebEx Configuration

Target Platform Integration and SIP Settings

Each Cisco WebEx extension can have up to 10 calls at a time
Each extension/device requires a unique MAC address upon its creation. Since we do not use MAC addresses in the cloud, we can manually generate one via a third-party website like this one.
- Enter the quantity of MAC addresses that you want to be created, use “Separator Style” set to “none”, and “HEX Characters” on “UPPERCASE” and click “Generate MACs!”

Configuration Within CiscoWebEx

To find that user go to Devices - (Click the User)
1. NOTE: The password is redacted
However, upon creation of this user/device, you’ll get these creds: (Make note of them or export the CSV file)
Outbound Call Traffic Settings
1. Within CiscoWebEx, you need to make sure that outbound traffic is enabled. You check these settings and configure this on the platform here
2. Since we are using their trunking and outbound codes, we need to know what they are for making outbound calls with WebRTC, and for Queued Callback calls
3. Users - Calling (Check Permissions)
4. Location > Calling > Call Handling > Outgoing Call Permissions
  1. Because we use the same infrastructure, any outbound call we make from WebRTC will have to cater to the rules as they’ve been configured within Cisco
5. Locations > Calling > External Dialing > Outbound Dial Digit**
Routing to Contact Center Skills
1. When routing to Contact Center skills on CiscoWebEx, we are able to do so by using the “Diversion” header. This is produced by forcing a “forward” within the UC Queue itself to the Xima Integration Extension
2. For Example - Ques are located under Services > Calling > Features > Call Queue
3. Within the Call Queue, you will find the Call Forwarding Setting
4. Open it up and enable the call forwarding for the Xima Integration Extension, as shown below
5. This forced forward will push the call queue name into the “Diversion” header which we can leverage as part of our call routing rules
6. In this example, this call queue is called “James Bond”. Here is that messaging in the SIP Header
7. Within Xima CCaaS for reference, here is the Call Routing configuration. We have specified the SIP header to look for when the call comes in as well as the value within that header. Once the rules match, it then will send the call to the “Spy Skill” in this instance
8. Here is a successful call routing example on Xima's side in Cradle to Grave based on the rules established above
9. Within CiscoWebEx, you can assign a DID directly to this Call Queue, or, you can setup a digit press within the Auto Attendant and route calls via digit press as well
  1. Auto Attendant is located here - Services > Calling > Features > Auto Attendant
  2. Open up the Auto Attendant and then navigate to Menu
  3. In this example
    1. Digit press 1 goes to Call Queue 4456, which is the “James Bond” queue
    2. Digit press 2 goes to a Call Queue that has a DID assigned to it called “Routing Test”
    3. Digit press 3 goes to Call Queue 4457 called Alan’s Test
  4. However you mix and match this, be sure that it goes to a Call Queue, and that queue has a forced forward to the primary Xima Integration Handset as described above
  5. NOTE: With this if you were to call 13854530577 (as noted in digit press 2), it will also go directly to this skill, as specified in the rules, bypassing this Auto Attendant

Configuration Within Xima CCaaS

Target Platform Configuration
- NOTE: TLS is Required. Also, on this platform, the number of calls allowed per extension is 10
SIP Integration Configuration
- NOTE: The SIP extension and the Authentication ID are the same

Required Feature Toggles on Xima's Side (Enabled by Xima)

WAIT_FOR_ANSWER_BEFORE_HANDLING_RE_INVITE - When transferring a call through an AA to a UC Call Queue, which forwards over to our handset, it sends two invites. Until this toggle, we were only handling one of those invites and upon answering, we wouldn’t get audio of either party
[OPT_OUT]_SEND_BYE_AFTER_BLIND_TRANSFER - When attempting to do a transfer (blind or assisted), it would disconnect the external party and not actually transfer
CACHE_LOAD_BALANCER_RINGING_REQUEST- CiscoWebEx only allows for 10 calls per handset. Because of this, we have to have multiple extensions to handle a higher volume of calls. Due to limitations on how the SIP messaging is sent upon a blind transfer from the load balancer over to the other extensions registered in-line, it would kill the SIP headers. This caches and maintains those headers to allow us to route intelligently after being sent from the load balancer. NOTE: From there, we have to use something called "X-BroadWorks-Correlation-Info" which is a unique identifier (think session id/call id). Without this, we wouldn’t know which call goes to which call route. With that said, unless a system has something equivalent to this, this will be exclusive to CiscoWebEx
[RESTART]LOOKUP_DNS_SRV_RECORD - CiscoWebEx is one of the few that requires SRV as opposed to standard DNS. This needs to be enabled in order to register any extensions
[RESTART]ENABLE_TLS_TRUST - TLS is the only protocol that is used on this platform. It won’t register, or attempt to register unless this is enabled
SIP_OK_ON_UPDATE - CiscoWebEx sends an UPDATE message about 15 minutes into every call. This is irrespective of whether or not the call has been answered by an agent, or if it’s sitting in queue. If this feature toggle is not enabled, Cisco will continue to send the UPDATE message and we won’t respond to it with an “OK” message. As a result, Cisco drops the calls. Hence, make sure this feature toggle is enabled so calls remain in session past the 15-minute timeframe
WEB_RTC_ASSISTED_TRANSFER_USE_SAME_HANDSET - If this isn’t enabled and you attempt an assisted transfer, there will be no audio from either party on the second leg of the call once you click “complete transfer”. What this feature toggle does is keep the call on the same registered integration extension that the call was initiated on, as opposed to using another “less full” extension and bridging both together. This can increase the likelihood of the assisted transfer failing due to a lack of available channels but will work assuming there are resources available within that registered extension