TFTP is the part of Call Manager where you store all phone’s configuration so that you are able to retrieve then at the bootup sequence. TFTP IP Address will be communicated to IP Phones via the DHCP option 150.
There is two types of security that you can enable with Call Manager
- Mixed mode : In this mode, depending the security configured on each phone, you can have secure calls when both devices are security-enabled and when one of the phones is missing security, your call will be nonsecure.
- Nonsecure mode : As all phones are not set up with security (default configuration), all calls are nonsecure.
When you device to put security on phones , they can support the three following levels:
- Nonsecure mode : secure calls are not supported
- Authenticated mode : the phone will be able to authenticate calls
- Encrypted mode : the phone will be able to support encrypted calls
If you enable the authentication and the encrytion on your network , you are then able to secure the media traffic as well the voice signaling.
If you want to have security on the media flow, it is then mandatory to secure also the signaling as the keys which are used to secure the media traffic are exchanged during the signaling phase.
SCCP messages sent by IP Phones and Call Manager can be secured using TLS, it is the signaling part. Then for the protection of the media traffic so the RTP packets , you will use the Secure RTP which is providing a framework for encryption and authentications of your stream.
SRTP will be also use between your MGCP gateway and your IP Phone but you need to know that your SRTP keys are exchanged in cleartext session between the MGCP gateway and the Call Manager.
With the CRS Editor, you can configure your scripts and related applications to interact with the SQL DB. Here are the action that you can use within your script:
- DB Read : used to select a database and obtain data (using SQL statements)
- DB Get : used to assign specific variable(s) with the result of the query specify in the DB Read
- DB Write : used to select a database and update an enterprise database (using SQL statements)
- DB Release : used to close a SQL query and releases resources after the DB Get or Write step.
As in Call Manager, you can specify the level of traces that you want to enable but we will not cover this now. Let’s see the common issues.
Most of the times , issues are due of a mistake with the JTAPI. You can find easily the root cause with the Control Center as it will give you a status of the engine. Then with these status, you can see in which direction you have to go.
- In-Service : Indicates a full operational mode (all CTI ports, CTI route points and associated applications are successfully initialized)
- Initializing : Indicates that the subsystem is initializing the CTI route points, ports and associated applications
- Partial Service : Indicates that the JTAPI subsystem was unable to initialize one or more CTI route points or ports. Most of the time, it is due to a misconfiguration, so check that route points/ports exist , are correctly configured and associated with the JTAPI on Call Manager
- Out-Of-Service : Indicates that none of the CTI route points and ports were correctly initialized. It can occur for a number of reasons as follows:
- JTAPI Provider on Call Manager down
- No CTI ports or route points configured
- Username/password incorrect
- CRS is unable to resolve the Call Manager’s DNS name
- No connectivity between the CRS and Call Manager
Here are some basic steps to perform the configuration of the IPCC:
- Configure the JTAPI subsystems (Subsystem>JTAPI) with the Call Manager IP address and username/password . Remind also that if you need redundancy , then you need to configure 2 users.
- Configure then a JTAPI call control group. This permits to CRS tocontrol CTI ports to answer calls and so on
- Be sure that everything is synchronized between CUCM/CTI Manager and CRS
- Configure the CMT which is reponsible of all the media involved
- Configure all others subsystems that you need (MRCP ASR, MRCP TTS, HTTP, database, email)
- Start the CRS engine
- Install and configure all your applications by using your scripts
Remember also that even if you have a redundant IPCC and CTI Manager, only 1 CTI Manager can be active during normal operations.
Here are all the steps to perform if you want to integrate the CUE with the CME
- Create a SIP dial peer pointing to the CUE Module
- Configure the MWI On/Off extensions
- Configure the connectivity between CME and CUE Modules
- Perform CUE Configuration
For the first step , your dial peer will look like
dial-peer voice 1000 voip
session protocol sipv2
session target ipv4:172.17.1.1
The configurations of the MWI On/Off must be generic as it must cover all numbers and it is generally implemented as a kind of prefix as the MWI must know which number must be turned on or off. So it adds the number after the extension the MWI shortcut.
Regarding the link configuration between the CUE and CME, you need to borrow the Ethernet interface where the CUE module resides (don’t forget that CME and CUE can be splitted). So everything under the service-engine ( this is the CUE module) will rely on the Ethernet interfaces:
interface Service-Engine 1/0
ip unnumbered FastEthernet 1/0
service-module ip address 172.17.1.1 255.255.255.0
service-module ip default-gateway 172.17.1.254
ip route 172.17.1.1 255.255.255.255 Service-Engine1/0
In a multi-site implementations , you have then to configure a translation between your remote CME and the central CUE/CME because we told before that CUE relies on SIP Protocol and the rest of your network is an H323 network , so you need to translate all H323 request to SIP. You can do it generally with the config:
voice service voip
allow-connections H323 to sip