Thursday, January 17, 2019

UCCX Finesse using custom Call Variable Layouts

Cisco's documentation has always been rather spartan regarding assigning / presenting custom variable layouts to agents:

To display a custom Call Variables Layout, in the Unified CCX routing script, set the user.layout ECC variable to the name of a configured Call Variables Layout. In this case, if no custom layouts match the user.layout value (or no custom layouts are configured), Finesse displays the default layout.

Here's my note to self (note this is circa UCCX 11.6):

First, in your script / Cisco Unified CCX Editor, choose Settings | Expanded Call Variables.

There you will need to add at least one variable named user.layout.  This special variable and its value is what Finesse uses to decide whether to present the default layout or a custom layout you create to your agents.

Here you can also create custom variables you can populate in your script to present agents interesting info.

For example, I added userCSQ that I will use to present the name of the queue that is processing the call when an agent answers. Perhaps an agent answers sales and service calls.  You can populate userCSQ here with "Sales" and present that to an agent in Finesse so they can answer appropriately.


Then, in your script you need to populate the variables using a Set Enterprise Call Info step.

In the Expanded Call Variables tab you want to associate values with the variables you just created.  Here I set the user.layout variable to "ITS Layout".  Note this value will be the name of the Call Variable Layout you later create in Finesse Administration.  When an agent is presented a call by this script after this Set Enterprise Call Info step, the agent will see the Call Variable Layout named ITS Layout.

So, you're not associating Call Variable Layouts with UCCX Teams, nor Finesse Desktop layouts. You use the script managing the call to present the layout.

Here I've also populated the userCSQ variable I created by simply typing the value "ITS".  Alternatively I could have used the drop down in the values column to pick another variable defined in your script.  I already have a CSQ variable used in the script and if the value there was appropriate for agent view, I could replace "ITS" with CSQ from the drop down.


Then in Finesse Administration on the Call Variables Layouts tab, create a new layout.

In this example it is critical that the name is ITS Layout, the value of the user.layout variable you created and populated in your script.  When the script presents an agent a call, this layout will be used as a result.

Note in the Call Header Layout I have a row with a description of Queue and a value of userCSQ.  As a result, when an agent is presented a call using this layout they will see the word Queue: and the value ITS.  You assigned the userCSQ variable the value of "ITS" in your script's Set Enterprise Call Info step.


Ultimately, now an agent will be presented with a layout like below, and this layout will ONLY be presented when a Set Enterprise Call Info step assigns ITS Layout to the user.layout variable.


Enjoy presenting interesting data!

Thursday, January 03, 2019

Cisco Expressway reset password

Having lost a root or admin password, you can reset them from the vSphere / vCenter console.

  1. Reboot the Expressway with the misplaced password.
  2. When prompted in the vSphere / vCenter console, log in with the username pwrec. You should not be required to enter a password.
  3. Then enter the username that needs the password changed.  This will be root or the name associated with administration (i.e. admin, etc.).
  4. Enter the new password for the account and once again to confirm.
  5. Reboot the system again.
  6. Enjoy  your new password.


Resetting root password on an Expressway Core server

Monday, December 31, 2018

Cisco Jabber SIP URI dialing

Assuming a single CUCM cluster in generally good call routing health, see below for short list of configuration changes required to enable SIP URI dialing in Cisco Jabber:

  • System | LDAP | LDAP Directory set Directory URI to mail
  • System | Enterprise Parameters set URI Lookup Policy to Case Insensitive
  • System | Enterprise Parameters set Directory URI Alias Partition to a partition accessible by clients
  • System | Service Parameter | Cisco CallManager set URI Dialing Display Preference to URI
  • User Management | End User set users' Primary Extension
  • Device | Device Settings | SIP Profile check Use Fully Qualified Domain Name in SIP Requests in a profile applied to endpoints
  • jabber-config.xml | Policies add true

Saturday, December 29, 2018

Using SIP OPTIONS Ping to monitor groups of carrier servers on Cisco CUBE routers

Implementing multiple CUBEs in separate data centers carrying voice traffic to and from the same group of carrier servers.

Ideally, a single dial peer in CUBE 1 points to all the carrier servers, and a single dial peer in CUBE 2 does the same.

Carrier only authenticates traffic by IP so they want to use OPTIONS Ping to monitor the availability of the CUBEs.

I want to monitor the availability of the carrier servers using OPTIONS Ping as well so I can fail between CUBEs and / or other circuits quickly if necessary.  I also don't want to have to create redundant dial-peers to do it.

Step 1:
Add voice class uri defining carrier servers. I'll use this to (at least) define which inbound dial-peer will answer the SIP OPTIONS ping from the carrier. This will let the carrier know which CUBE to send incoming calls to.

voice class uri 2 sip
   host ipv4:10.7.X.X
   host ipv4:10.7.Y.Y

Step 2:
Add a server group defining carrier servers.  This allow me to both route calls to multiple carrier servers as well as monitor them with OPTIONS Ping with a single dial-peer. If OPTIONS Ping fails in defined intervals, the dial-peer is busied out and calls can be routed elsewhere. 

voice class server-group 2
   ipv4 10.7.X.X preference 1
   ipv4 10.7.Y.Y preference 2
   description SIP Carrier Interfaces

Step 3:
Use a voice class to administer down-intervals, up-intervals and retry intervals in one place rather than on a list of different dial-peers.

voice class sip-options-keepalive 2
   description SIP Carrier Interfaces Keepalive
   down-interval 30
   up-interval 60
   retry 5

Step 4:
Create a dial-peer to respond to the carriers OPTIONS Ping using the voice class uri above.

dial-peer voice 2 voip
   description incoming calls from carrier
   session protocol sipv2
   incoming uri via 2
   voice-class codec 1
   voice-class sip bind control source-interface GigabitEthernet0/0/2
   voice-class sip bind media source-interface GigabitEthernet0/0/2
   dtmf-relay sip-kpml rtp-nte
   no vad

Step 5:
Add the server-group session above to a single outgoing dial-peer. With that you can eliminate redundant dial-peers pointing to individual carrier servers.  Add the sip options-keepalive profile above to the same outgoing dial-peer.  You will then send SIP Options ping to the carrier servers to monitor their statuses.  When SIP OPTIONS Ping fails, this dial-peer will be busied out.

dial-peer voice 10 voip
   description Outgoing calls to carrier
   translation-profile outgoing OutboundPSTN
   destination-pattern +T
   session protocol sipv2
   session server-group 2
   voice-class codec 1
   voice-class sip options-keepalive profile 2
   voice-class sip bind control source-interface GigabitEthernet0/0/2
   voice-class sip bind media source-interface GigabitEthernet0/0/2
   dtmf-relay sip-kpml rtp-nte
   no vad

Now you can use show voice class sip-options-keepalive 2 or show dial-peer voice summary to monitor the status of the individual carrier server and general dial peer status.  Below you see neither carrier server is reachable (Busy) via SIP Options ping / voice class sip-options-keepalive 2 and that dial-peer 10 is in a busyout state:


myCUBE1#show voice class sip-options-keepalive 2
Voice class sip-options-keepalive: 2 AdminStat: Up
 Description: Carrier Interfaces Keepalive
 Transport: system Sip Profiles: 0
 Interval(seconds) Up: 60 Down: 30
 Retry: 5

  Peer Tag    Server GroupOOD SessID  OOD Stat    IfIndex   
  --------    ----------------------  --------    -------   
  10          2                       Busy        16         

  Server Group: 2 OOD Stat: Busy
   OOD SessID  OOD Stat   
   ----------  --------   
   5           Busy       
   6           Busy       

 OOD SessID: 5            OOD Stat: Busy
  Target: ipv4:10.7.X.X
  Transport: system       Sip Profiles: 0

 OOD SessID: 6            OOD Stat: Busy
  Target: ipv4:10.7.Y.Y
  Transport: system       Sip Profiles: 0

------------------------------------------------------

csb-dc-s0-vg1#show dial-peer voice summary
dial-peer hunt 0
             AD                                    PRE PASS                OUT
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF
2      voip  up   up                                0  syst                          NA                 
10     voip  up   up             +T            0  syst                               busyout    NA                 


See related official Cisco documentation here:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_sip/configuration/15-mt/cube-sip-15-mt-book/oodo-ping-group.pdf



Wednesday, December 26, 2018

QSIG PRI between CUCM and NEC 8500 hold and resume issues

Call flow was basically:
Cisco 8841 -> SIP -> CUCM -> SIP -> CUBE -> QSIG PRI -> NEC 8500

When making calls from CUCM to NEC endpoints, placing a call on hold on the Cisco endpoint and resuming resulted in disconnecting the call on the CUCM side.  The NEC system did not release the call.

Found a SIP UPDATE message being sent from CUCM to CUBE when resuming the call resulted in an ISDN NOTIFY message between CUBE and the NEC system.  Either the NOTIFY message, or maybe just the fact it included a caller name in ISDN Display format was not supported by NEC.  The result was the call would drop on the CUCM side.

Although you can remove the name in the ISDN SETUP message via "no isdn outgoing display-ie", there was no way I could find to eliminate the name from the ISDN NOTIFY message.  The work around was to prevent caller ID from being updated on the SIP trunk side via SIP | no update-callerid in the CUBE configuration.  This eliminated the entire ISDN NOTIFY message as a result.

This is a sample message sent to NEC when resuming held calls and the disconnect:

Dec 21 18:51:49.701: ISDN Se0/1/1:23 Q931: TX -> NOTIFY pd = 8  callref = 0x00C8
        Notification Ind i = 0x8300
        Display i = 'Ray Maslanka'
        Calling Party Number i = 0x0081, '78898'
                Plan:Unknown, Type:Unknown
        Cause i = 0x85E328 - Information element not implemented
        Call State i = 0x00
Dec 21 18:51:49.774: %ISDN-6-DISCONNECT: Interface Serial0/1/1:0  disconnected from 23999 , call lasted 19 seconds

This is relevant snippets of the CUBE configuration:

voice service voip
 ip address trusted list
  ipv4 X.X.X.X 255.255.255.0
 mode border-element license capacity 200
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 fax protocol t38 version 0 ls-redundancy 1 hs-redundancy 1 fallback none
 modem passthrough nse codec g711ulaw
 h323
 sip
  bind control source-interface Port-channel1
  bind media source-interface Port-channel1
  ! This eliminates the SIP UPDATE message
  ! that in turn eliminates the ISDN NOTIFY message
  no update-callerid 
  early-offer forced

controller T1 0/1/0
 framing esf
 clock source network
 linecode b8zs
 cablelength long 0db
 pri-group timeslots 1-24
 trunk-group PSTN timeslots 1-24 preference 1

interface Serial0/1/0:23
 encapsulation hdlc
 no cdp enable
 isdn switch-type primary-qsig
 isdn protocol-emulate network
 isdn incoming-voice voice
 ! This eliminates name display in ISDN SETUP messages.
 ! This DOES NOT eliminate name display in ISDN NOTIFY messages 
 ! when resuming from hold.
 no isdn outgoing display-ie