CUC 9.x: Call Transfer

There are different methods to transfer calls in CUC. Below are couple of them.

Directory Handler

This is detailed in call routing section. However, worth to mention that this will lookup users in the corporate directory based display name and once identified the call will be transferred to the user extension by looping it back to the phone system.

The callers can be internal to the organization or external. You just need to make sure that the phone system is sending the right call information to CUC.

Note: This method can't be used if you want to dial numbers which aren't listed in the directory from CUC.

User or Call Handler

Another way is creating a call routing rule which sends the call to user with mailbox or call handler. The user or call handler will allow call transfer to external numbers if not restricted by restriction table and if the Allow Transfers to Numbers Not Associated with Users or Call Handlers check box is enabled under greeting settings.

For user with mailbox or call handler, call transfer will take place before taking message action. Once message recording started, CUC will ignore transfer or call caller input. CUC will take them as part of the message. You need to make sure that after greeting action isn't take message, for example it can be restart greeting.

There are two types of transfer, Standard and Closed. Standard transfer settings takes place during active hours of the user or call handler while Closed Transfer settings take place during inactive time or holiday. This is controlled by the schedule assigned to the user or call handler.

The extension setting is the caller ID to be provided to phone system. Else, you can play a greeting and use the CUC number as caller ID. Also, you can release the call directly to phone system or make it as supervised transfer (consulted transfer).

Note: This methods can be used to transfer calls to external numbers outside the CUC directory.

System Transfer

You can route callers to one of the two transfer conversations:

Caller System Transfer

This conversation prompts callers to enter the number that they want to transfer to. To help protect your organization from toll fraud and unauthorized use, Unity Connection performs the transfer only when the Default System Transfer restriction table permits it.

User System Transfer

This conversation prompts callers to sign in to Unity Connection. After callers enter their Unity Connection IDs and PINs, Unity Connection prompts them to enter the number that they want to transfer to. To help protect your organization from toll fraud and unauthorized use, Unity Connection performs the transfer only when permitted by the transfer restriction table that is associated with the class of service for the user who signed in.

This can be done by:

1. Creating a call routing rule pointing to the conversation
2. Configure caller input on a call handler/user to send the caller to system transfer conversation. This is called one-key dialing.

Note: This method allow transfer to external if allowed by restriction table.

Note: When using either the Caller System Transfer or User System Transfer conversation, Unity Connection prompts users and callers to confirm the number that they enter before performing the transfer. To disable the confirmation prompt, change the System Transfers: Confirm Number Before Transfer setting on the System Settings > Advanced > Conversations page in Cisco Unity Connection Administration.

CUC 9.x: Call Routing

The building blocks which control call routing in unity connection are:

System Call Handlers

Answer calls and can take messages; provide menus of options (for example, “For customer service press 1, for sales press 2...”); route calls to users and to other call handlers; and play audiotext (prerecorded information).

Directory Handlers

Directory handlers provide access to a corporate directory that callers can use to reach Cisco Unity Connection users who have mailboxes and who are listed in the directory. When a caller searches for a username or part of a name, a directory handler looks up the extension and send call forward request to the PhoneSystem to dial the extension of the user.

Note: For SIP integration with CUCM, you need to assign Rerouting CSS to the trunk and Enable Divert by Application on the SIP Profile.

Callers can also enter an extension/called number to place an outgoing call from a directory handler; the extension/called number is checked against the applicable outcalling restriction table if the caller is a user, or against the Default Outdial restriction table if the caller is an outside caller.

There are two types of directory handlers:

1. Phone Keypad

Callers enter search information or extensions by using the phone keypad. For this type of directory handler, you can specify how it searches for names, what it does when it finds one or more matches, and what it does when it detects no caller input.

2. Voice Enabled

(For Cisco Unity Connection systems with the voice-recognition option only). For this type of directory handler, callers say the first name and last name of the Connection user that they want to reach, or enter an extension by saying the individual digits in the extension. In addition to searching by first and last name, the voice directory handler includes alternate names in searches. Callers can narrow down the search by saying the name and city or department of the user (or both) if these fields are defined on the Edit User Basics page in the user profile.

• Connection users who are listed in the directory are available to outside callers as names that can be reached.
• Administrator-defined contacts are only available to Connection users who are signed in to Connection
• User-defined contacts are only available to the Connection users who defined them.

Note that for this type of directory handler, users cannot be accessed by using directory handlers unless they have a display name specified and the 'List in Directory' check box is checked for them on the User Basics page

Interview Handlers

Collect information from callers by playing a series of questions and then recording the answers. When a call is routed to an interview handler, the interview handler plays the first recorded question, then plays a beep, then records the answer. Cisco Unity Connection stops recording either when the response reaches the maximum recording time that you have specified, or when the caller stops speaking. When all the answers have been recorded, they are forwarded as a single voice message, with beeps separating the answers, to the recipient that you designate.

Call Routing Tables

Allow you to define how calls are initially routed, based on criteria such as the phone number of the caller and the schedule. When you have set up call handlers, interview handlers, and directory handlers, as well as extensions for users, you can route calls to the applicable person or handler by modifying the call routing tables.

When Connection receives a call, it first determines if it is a direct or forwarded call based on the call information that is sent by the phone system, and then applies the applicable call routing table as per below flow chart.
 

Note: Two important settings are present in any dial rule whether it is direct or forward:

• Send to Greeting: It will skip the transfer rules.
• Attempt transfer for: t will start at the top of the flow with the transfer rules. 

If the call information matches all of the conditions for the first rule, the call is routed as specified in the rule. If any of the conditions specified in the first rule are not met, the call information is then compared to the conditions of the second rule, and so on, until a rule is found that matches all the characteristics of the call.

Route from Next Call Routing Rule

In a user profile or call handler, you can configure the After Greeting action, the After Message action, or the action of a caller input key to apply the 'Route from Next Call Routing Rule' action to calls. This action causes Cisco Unity Connection to continue processing the call according to the applicable call routing table (direct or forwarded, depending on how the call was received from the phone system) starting at the rule immediately after the rule that Connection previously applied to the call. If the call was already processed according to the final rule in the table, the final rule is applied again.

A typical usage for this action if you want to play a disclaimer before starting call routing. In this case, a rule should be configured in both direct and forwarding table to play the disclaimer. The after greeting action should be 'Route from Next Call Routing Rule' to resume call routing.

Restriction Tables

Control outgoing calls by allowing you to specify the numbers that Connection can dial for transferring calls, for notifying users of messages, and for delivering faxes.

When a user uses the Cisco Unity Connection Messaging Assistant or the Connection conversation to attempt to change a phone number that is used for call transfer, message notification, or fax delivery, or when signed-in users use the Connection conversation to perform User system transfers to a number that they specify, Connection applies the restriction table associated with the class of service of the user to verify that the phone number entered is allowed.

Note: An administrator can, when necessary, override the limitations of the class of service of a particular user.

Each row of a restriction table is made up of a dial string. Each dial string consists of a call pattern and a setting that specifies whether numbers that match the call pattern can be called.

Types of Default restriction tables:

Default Fax	Restricts numbers for fax delivery.
Default Outdial	Restricts numbers for message notifications. Also restricts the user extensions that Unity Connection dials when the phone is selected as the recording and playback device in the Media Master.
Default System Transfer	Restricts numbers that can be used for Caller system transfers, which allow unidentified callers to transfer to a number that they specify. For example, callers may want to dial a lobby or conference room phone that is not associated with a Unity Connection user. By default, the table does not allow Unity Connection to dial any numbers.
Default Transfer	Restricts numbers for call transfers.
User-Defined and Automatically-Added Alternate Extensions	Restricts the numbers the users can use to create alternate extensions for themselves through interfaces such as the Cisco Personal Communications Assistant or via an API call. Also restricts numbers from being offered as alternate extensions. For example, you might block a lobby or conference room extension so that users who frequently call Unity Connection from those shared phones are not automatically prompted to add the number as an alternate extension.
Excluded Extensions for Automatically Added Alternate Extensions	Restricts numbers from being offered as alternate extensions. For example, you might add a lobby or conference room extension so that users who frequently call Unity Connection from those shared phones are not automatically prompted to add the number as an alternate extension.

Schedules and Holidays

Define business/nonbusiness and holiday hours for the organization, for the purpose of controlling which set of call routing rules, greetings, or transfer options is currently active.

SSL Messages Exchange DeepDive (for advanced users)

SSL packets are called records and can be classified into four types:

• Handshake (22, 0x16)
• Change Cipher Spec (20, 0x14)

• Alert (21, 0x15)

• Application Data (23, 0x17)

Each record consists of:

• Type: uint8

• Version: uint16

• Length: uint16
• Data

Types of Records

Handshake Records

Handshake records contain a set of messages that are used in order to handshake. These are the messages and their values:

• Hello Request (0, 0x00)
• Client Hello (1, 0x01)
• Server Hello (2, 0x02)
• Certificate (11, 0x0B)
• Server Key Exchange (12, 0x0C)
• Certificate Request (13, 0x0D)
• Server Hello Done (14, 0x0E)
• Certificate Verify (15, 0x0F)
• Client Key Exchange (16, 0x10)
• Finished (20, 0x14)

In the simple case, handshake records are not encrypted. However, a handshake record that contains a Finished message is always encrypted, as it always occurs after a Change Cipher Spec (CCS) record.

Change Cipher Spec Records

CCS records are used in order to indicate a change in crpytographic ciphers. Immediately after the CCS record, all data is encrypted with the new cipher. CCS records might or might not be encrypted.

Alert Records

Alert records are used in order to indicate to the peer that a condition has occured. Some alerts are warnings, while others are fatal and cause the connection to fail. Alerts might or might not be encrypted, and might occur during a handshake or during data transfer. There are two types of alerts:

• Closure Alerts: The connection between the client and the server must be properly closed in order to avoid any kind of truncation attacks. A close_notify message is sent that indicates to the recipient that the sender will not send anymore messages on that connection.
• Error Alerts: When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Some examples of error alerts are:
• unexpected_message (fatal)
• decompression_failure
• handshake_failure

Application Data Record

These records contain the actual application data. These messages are carried by the record layer and are fragmented, compressed, and encrypted, based on the current connection state.

A typical SSL client-server authentication as follow.

Hello Message Phase

When an SSL client and server begin to communicate, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public key encryption techniques in order to generate shared secrets.

Client Hello

The Client Hello sends these attributes to the server: 

• Protocol Version: The version of the SSL protocol by which the client wishes to communicate during this session.

• Session ID: The ID of a session the client wishes to use for this connection. In the first Client Hello of the exchange, the session ID is empty (refer to the packet capture screen shot after the note below).
• Cipher Suite: This is passed from the client to the server in the Client Hello message. It contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (first choice first). Each cipher suite defines both a key exchange algorithm and a cipher spec. The server selects a cipher suite or, if no acceptable choices are presented, returns a handshake failure alert and closes the connection.

• Compression Method: Includes a list of compression algorithms supported by the client. If the server does not support any method sent by the client, the connection fails. The compression method can also be null. 

Note: The server IP address in the captures is 10.0.0.2 and the client IP address is 10.0.0.1.

Server Hello

The server sends back these attributes to the client: 

• Protocol Version: The chosen version of the SSL protocol that the client supports.
• Session ID: This is the identity of the session that corresponds to this connection. If the session ID sent by the client in the Client Hello is not empty, the server looks in the session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server responds with the same value that was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the finished messages. Otherwise, this field contains a different value that identifies the new session. The server might return an empty session_id in order to indicate that the session will not be cached, and therefore cannot be resumed.
• Cipher Suite: As selected by the server from the list that was sent from the client. 
• Compression Method: As selected by the server from the list that was sent from the client. 
• Certificate Request: The server sends the client a list of all the certificates that are configured on it, and allows the client to select which certificate it wants to use for authentication.

For SSL session resumption requests:

• The server can send a Hello request to the client as well. This is only to remind the client that it should start the renegotiation with a Client Hello request when convenient. The client ignores the Hello request from the server if the handshake process is already underway.
• The handshake messages have more precedence over the transmission of application data. The renegotiation must begin in no more than one or two times the transmission time of a maximum-length application data message.

Server Hello Done

The Server Hello Done message is sent by the server in order to indicate the end of the server hello and associated messages. After it sends this message, the server waits for a client response. Upon receipt of the Server Hello Done message, the client verifies that the server provided a valid certificate, if required, and checks that the Server Hello parameters are acceptable.

Server Certificate, Server Key Exchange, and Certificate Request (Optional)

• Server Certificate: If the server must be authenticated (which is generally the case), the server sends its certificate immediately after the Server Hello message. The certificate type must be appropriate for the selected cipher suite key exchange algorithm, and is generally an X.509.v3 certificate.
• Server Key Exchange: The Server Key Exchange message is sent by the server if it has no certificate. If the Diffie?Hellman (DH) parameters are included with the server certificate, this message is not used.

Client Exchange

Client Certificate (Optional)

This is the first message that the client sends after he/she receives a Server Hello Done message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client sends a no_certificate alert instead. This alert is only a warning; however, the server might respond with a fatal handshake failure alert if client authentication is required. Client DH certificates must match the server specified DH parameters.

Client Key Exchange

The content of this message depends on the public key algorithm selected between the Client Hello and the Server Hello messages. The client uses either a premaster key encrypted by the Rivest-Shamir-Addleman (RSA) algorithm or DH for key agreement and authentication. When RSA is used for server authentication and key exchange, a 48-byte pre_master_secret is generated by the client, encrypted under the server public key, and sent to the server. The server uses the private key in order to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret.

Certificate Verify (Optional)

If the client sends a certificate with signing ability, a digitally-signed Certificate Verify message is sent in order to explicitly verify the certificate. 

Cipher Change

Change Cipher Spec Messages

The Change Cipher Spec message is sent by the client, and the client copies the pending Cipher Spec (the new one) into the current Cipher Spec (the one that was previously used). Change Cipher Spec protocol exists in order to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) Cipher Spec. The message is sent by both the client and server in order to notify the receiving party that subsequent records are protected under the most recently negotiated Cipher Spec and keys. Reception of this message causes the receiver to copy the "read pending" state into the "read current" state. The client sends a Change Cipher Spec message following handshake key exchange and Certificate Verify messages (if any), and the server sends one after it successfully processes the key exchange message it received from the client. When a previous session is resumed, the Change Cipher Spec message is sent after the Hello messages. In the captures, the Client Exchange, Change Cipher, and Finished messages are sent as a single message from the client.

Finished Messages

A Finished message is always sent immediately after a Change Cipher Spec message in order to verify that the key exchange and authentication processes were successful. The Finished message is the first protected packet with the most recently negotiated algorithms, keys, and secrets. No acknowledgment of the Finished message is required; parties can begin to send encrypted data immediately after they send the Finished message. Recipients of Finished messages must verify that the contents are correct.

What is SSL Cryptography?

Recently, I have been working on a project to deploy Cisco Jabber. Cisco Jabber needs integration with Cisco AnyConnect VPN for remote teleworkers. AnyConnect VPN is a sub-division of Cisco SSL VPN.

As I usually prefer, I will post in the following order:

1. What SSL Cryptograph?
2. SSL Messages Exchange DeepDive (for advanced users)
3. ASA SCEP Proxy Enrollment
4. Deploying Jabber for Remote Teleworkers (Step-by-Step Guide)

I prefer this order to avoid any gaps in knowledge transfer. Some of the posts won't be relevant to some people who already have the knowledge or not interested in VPN technologies.

SSL is a security protocol used to establish encrypted link between clients and servers to carry data securely. Clients can be outlook, web browsers, any connect client, etc.

Asymmetric Encryption

Asymmetric encryption (or public-key cryptography) uses a separate key for encryption and decryption. Anyone can use the encryption key (public key) to encrypt a message. However, decryption keys (private keys) are secret. This way only the intended receiver can decrypt the message. The most common asymmetric encryption algorithm is RSA.

 

Asymmetric keys are typically 1024 or 2048 bits. Though larger keys can be created, the increased computational burden is so significant that keys larger than 2048 bits are rarely used.

Symmetric Encryption

Symmetric encryption (or pre-shared key encryption) uses a single key to both encrypt and decrypt data. Both the sender and the receiver need the same key to communicate.

Symmetric key sizes are typically 128 or 256 bits.

Which is better?

There are three parameters to use in the comparison:
1. Security
Due to the fact that asymmetric encryption uses two keys, make it more secure and very complex to crack.

2. Compute Complexity

Symmetric keys are smaller than asymmetric, so they require less computational burden.

3. Ease of Distribution

Since symmetric keys should be similar at both ends of communication, distribution can be more complex in large environments. With asymmetric keys, this won't be an issue since the public key is used for encryption only. This means that you can distribute the public key globally. Private key is kept as secret and will be used by intended destination only for decryption.

SSL Encryption

SSL Encryption combines the advantages of both symmetric and Asymmetric encryption. Its usually called Public Key Infrastructure.

In SSL communications, the server’s SSL Certificate contains an asymmetric public and private key pair. The session key that the server and the browser create during the SSL Handshake is symmetric. This is explained further in the diagram below.

1. Server sends a copy of its asymmetric public key.

2. Browser creates a symmetric session key and encrypts it with the server’s asymmetric public key.

3. Server decrypts the asymmetric public key with its asymmetric private key to get the symmetric session key.

4. Server and Browser now encrypt and decrypt all transmitted data with the symmetric session key. This allows for a secure channel because only the browser and the server know the symmetric session key, and the session key is only used for that session. If the browser was to connect to the same server the next day, a new session key would be created.

Asymmetric Encryption Algorithms: These can use RSA and Elliptic Curve Cryptography (ECC) to create the public and private keys. With asymmetric encryption it is computationally easy to generate public and private keys, encrypt messages with the public key, and decrypt messages with the private key. However, it is extremely difficult (or impossible) for anyone to derive the private key based only on the public key

Symmetric Encryption Algorithms: These use algorithms like Twofish, AES, or Blowfish, to create keys. All of these encryption algorithms fall into two types: stream ciphers and block ciphers. Stream ciphers apply a cryptographic key and algorithm to each binary digit in a data stream, one bit at a time. Block ciphers apply a cryptographic key and algorithm to a block of data (for example, 64 sequential bits) as a group. Block ciphers are currently the most common symmetric encryption algorithm.

SSL Certificates

To get a certificate, you must create a Certificate Signing Request (CSR)on your server for your organization domain name/web site. This CSR creates the private key and a CSR data file that you send to the SSL Certificate issuer (called a Certificate Authority or CA). The CA uses the CSR data file to create a public key to match your private key without compromising the key itself. The CA never sees the private key.

Once you receive the SSL Certificate, you install it on your server. Now the server hosts private key, public key, and SSL certificate. Also, the server is ready to accept and encrypt connections.

Now if you got the private and public keys, why do you need the SSL certificate?

Certificates are mainly used for authentication and verifying identity of the organization (you don't want to submit your credit card information to untrusted organization using fake domain name). Anyone having a CA server (MS, Cisco IOS, OpenSSL) can issue a certificate and generate public key for a CSR, but browsers only trust server certificates issued by trusted CAs. Browsers come with a pre-installed list of trusted CAs, known as the Trusted Root CA store.

Trusted CAs usually verify the identity of the organization before signing the CSR and generating the certificate (establishment card of the organization, verifying the authorized representative of the organization, etc). When the client trying to connect to server and receives the certificate, it looks at the certificate path to check the CA who signed the certificate. If the client has the CA certificate (Root certificates) in its Trusted Root CA Store, it knows that the certificate was signed by a trusted CA which means that the organizations identity was verified, i.e. authentication is successful

Certification Chain

For some CAs, you also install a pair of intermediate certificates that establish the credibility of your SSL Certificate by tying it to your CA’s root certificate.

In the image below, you can see what is called the certificate chain. It connects your server certificate to your CA’s (in this case DigiCert’s) root certificate through a series of intermediate certificates.

IOS Tip: %Error deleting flash0:xxxx (Can't delete a directory that has files in it)

Have you seen this error before? Cisco IOS doesn't allow deletion of directories which contain sub-directories/files. This won't work with "delete" or "rmdir" command.

2951-router#delete /force flash0:CME9.1.0GUI
%Error deleting flash0:CME9.1.0GUI (Can't delete a directory that has files in it)








To make it working, you need to use "/recursive" keyword with "delete" command. It will start deleting using bottom-top approach from most deeper file in reverse direction..

2951-router#delete /force /recursive flash0:CME9.1.0GUI

IOS Tip: How to Move Directories within IOS Flash Memory

Have you ever uploaded a directory to Router Flash Memory (e.g. CME GUI Dir) and found that it was uploaded to wrong path? How to move it back to right path?

Let's consider a directory named CME9.1.0GUI. I wanted to upload it to "flash0:/" however, I discovered that its uploaded to "flash0:phone_loads/".

One option to put it back in the right path is to delete the directory from the wrong path and re-upload it. This can be easy when uploading from LAN or small directories over WAN. But not for big directories over WAN.

Another option is to use "rename" command. When you rename the directory, it will ask for the destination path of the renamed directory. This means that "rename" command is doing two functions which are copying the directory to new path and renaming it.

2951-router#rename flash0:phone_loads/CME9.1.0GUI flash0:CME9.1.0GUI        
Destination filename [CME9.1.0GUI]?
 
2951-router#dir
Directory of flash0:/

    1  -rw-    89934456  May 28 2013 22:07:24 +07:00  c2951-universalk9-mz.SPA.152-4.M3.bin
    2  -rw-        3064  May 28 2013 22:17:54 +07:00  cpconfig-29xx.cfg
  240  drw-           0   Aug 9 2013 04:34:26 +07:00  phone_loads
    3  drw-           0  May 28 2013 22:18:12 +07:00  ccpexp
  239  -rw-        2464  May 28 2013 22:19:54 +07:00  home.shtml
  241  drw-           0   Aug 9 2013 04:34:58 +07:00  ringtones
  242  drw-           0   Aug 9 2013 04:35:46 +07:00  CME9.1.0GUI
  246  -rw-      496521   Aug 9 2013 05:04:12 +07:00  music-on-hold.au

PS: This is applicable for any memory in IOS not only Flash.

Design Question: "dialplan-pattern" or "voice translation rule" ???

No doubt that voice translation rules are very powerful and provide many advantages in addition to digit manipulation. But let's consider a common scenario where you have CME and would like to convert extensions to E164 numbers for PSTN dialing.

One of the common ways to do this using "dialplan-pattern" command in CME. This is usually preferred over voice translation rules due to simplicity. Single command instead of voice-rule, voice-profile, assign profile to dial-peer or voice-port.

From design perspective, it is very dangerous to use "dialplan-pattern" feature. In fact I would say never use this feature. Let's look deeper.

The way how "dialplan-pattern" works that it will create an additional dial-peer for each Ephone-DN with destenation pattern as E164 number. For example, if you added a DN with number 6004 and your expansion pattern is 789.... , CME will create two virtual-dialpeers for numbers 6004 and 7896004 (you can see this using "show dial-peer voice summary" command).

Creating Ephone-DN with secondary number and having "dialplan-pattern" feature will result in 4 virtual dial-peers created (two for primary/secondary and two for E164-priamry/E164-secondary).

This means that number of virtual dialpeers is multiplied by two. For an office with 20 employees and 20 phones, you will have 40 virtual dialpeers (if only primary numbers are assigned) or 80 virtual dialpeers (if primary/secondary numbers are assigned) !!!!

Ok, till this point we didn't understand why this is a problem? What's wrong in having 80 or 100 virtual dial-peers ??

1. Dial-peers are stored in the RAM of the router for operation. Each dial peer consumes approximately 6KB of memory. 

By misusing this feature, you are adding overhead to your router's RAM without feeling it and bringing it very close to crash.

2. Assuming your are incorporating other features in your router (e.g. 2951 with default 512 MB RAM) such as zone-based firewalls, VPN, NAT, etc, you won't be able to add more than 10 ephone-DNs (assuming that secondary numbers are used). You will start getting error:

"Error: Can't Add Dial Peer"
 
3. On router reboot, although dial-peers configuration is saved in startup config, the router won't apply them to running config due to lack of RAM. This means that your router will boot with missing config (if you connect console due to reload, you will see the same error message in above point).

All of this can be resolved simply by using single voice translation rule applied to voice-port. So what do you think !!!