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.
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
CUE is as the CME a small business voice mail solution that you can easily deploy on a router. Most of the time, CUE will reside on the same chassis than the CME but for some implementations, you can split both. The only backdraw is that you must have a LAN connectivity between your elements.
CUE is interesting because it doens’t provide only voice mail but can also provide a small Auto-Attendant (AA). The integration between CUE and CME is done via the SIP protocol, while the integration with a Call Manager will be done via JTAPI ( CTI-QBE). It can be the case for implementation where you need to provide Unity backup on SRST location).
CUE will be supported by Network Module (NM-CUE) or as an Advanced Integration Module (AIM-CUE).
CME can be integrated with Cisco Unity, it is more or less as an integration with Call Manager except the fact that you must every setting in the CLI mode. Let’s see a kind of basic config:
call-forward busy 5555
call-forward noan 5555 timeout 10
name “VM-Port 1”
name “VM-Port 2”
name “VM-Port 3”
name “VM-Port 4”
So you can easily see that your config is trying to match the Unity port name and this is done with the command vm-device-id <<string>>. It helps also to register with Unity where you need the deviceId instead of a mac-address.
CME is more or less the same as we have seen in the SRST implementation. But there is some other enhancements, so let’s see or recap the available mode:
- Cisco Unity Express
- Cisco Unity
- Analog voicemail systems . (See this post for this point as it is still valid)
Call Hunt allows a search among ephone-dn dial peers for an available ephone-dn to answer the call. This can be used to provide a kind of call waiting solution. take a look at the following configuration:
call-forward noan 1501
call-forward busy 1501
call-forward noan 1501
button 1:10 2:20
So in this setup, if the phone extension is already busy on 1000, a second call still can hit the ephone-dn 20 and as the first one has told to continue the hunt, then making ringing the phone again on incoming call.
Another mechanism of hunting is to use the ephone-hunt group notion. In that configuration , an incoming call will be directed to a hunt-group pilot number which will hunt a group of ephone-dn. Let see the following config
ephone-hunt 1 peer
For the hunting, you have the following opportunities:
- Peer : Configures hunting in a circular manner among the hunt group member DNs, starting with the DN to the right of the last DN to ring
- Sequential : Configures hunting in a sequential manner, left to right and always starting with the left most DN in the list
- Longest-idle : Specifies hunting based on how long DNs have been idle. In that case, the call will go to the DN that has been idle the longest