United Arab Emirates PSTN Route Patterns

I recently had to configure a UC540 for use in the Dubai, unfortunately CCA doesn't have any dial plan templates for the UAE. Below is the route patterns for a simplified UAE dial plan:

Route Pattern	Description
00!	International calls
971	Water or electrical emergencies
997	Fire
999	Police and emergencies
[2-8]XXXXXX	Local calls
0200XXXXX	Shared cost services
0300XXXXX	Reserved for future use
0400XXXXX	Free access services
0500XXXXX	Shared revenue services
0600XXXXX	Fixed cost services
0700XXXXX	Shared cost services
0800XXXXX	Freephone services
0900XXXXX	Premium services
0[234679]XXXXXXX	National area codes
05[0256]XXXXXXX	Mobiles

QuesCom GSM Gateways

I've just completed my 2nd deployment of a QuesCom GSM gateway & they're painful to use, so here's a couple of tips for those of you with the misfortune to also have to deal with one these.

Firmware Updates
To update the firmware you'll need:

• A USB to serial adapter
• An Ethernet cable
• TFTPD
• PuTTY
• QuesCom firmware (getting this requires a support contract with QuesCom)

Now for the process:

1. Connect your PC's NIC to the QuesCom using the Ethernet cable, then using the serial cable that came with the QuesCom, connect to the console port on the QuesCom (this is the bottom serial port).
2. Run TFTPD, configure the DHCP server function on it & also enable PXE compatibility (otherwise you'll get errors), now restart TFTPD for the changes to take effect.
3. Run PuTTY & connect to the serial port using 19200bps, 8 data bits, no parity, 1 stop bit & no flow control.
4. Power on the QuesCom & interrupt booting by pressing CTRL + E, then type OK when it says to.
5. Select 1, wait for it to get a DHCP lease. Alternatively you can manually configure an IP address if DHCP fails.
6. Input the IP address of your PC running TFTPD, default gateway & file name of the firmware (this is case sensitive).
7. Wait for the firmware to finish downloading, then select 0 to boot with the new firmware.

Caller ID
The QuesCom GSM gateways default to restricting the caller ID on all outbound calls, regardless of what caller ID you present via H323 or SIP. This is undesirable as many people won't answer the phone to withheld numbers. Unfortunately you can't disable this behaviour from the web based GUI, you have to Telnet to the QuesCom and enter the following commands:

1. config
2. root gateway
3. cd isdn
4. cd Adapter.x (x=0,1 or 2; if you only have GSM cards in the slots, use 0)
5. set HideIdentification=0;0;0;0; (this assumes you have 4 SIM card model)
6. exit

Don't forget to save & reboot, otherwise the changes won't take effect.

Inserting Question Marks

The situations where you'd need to insert a question mark into the CLI are pretty rare, unless working with voice functionality as in regular expressions it means zero or one instance of preceding pattern (i.e. optional). For example when trying to make a dial-peer that matches 10 or 11 digits:

dial-peer voice 16 pots
 description Freephone 10/11 digits
 destination-pattern 080........?
 port 0/0:15

To insert a question mark, simply press Ctrl + V prior to inputting the ?. This acts as an escape sequence & prevents the context sensitive command line help from appearing instead.

ISDN Circuit Simulator

With a bit of ingenuity & an T1/E1 crossover cable it's possible to build your own ISDN PRI circuit simulator using spare parts. For this you'll need:

1. T1/E1 crossover cable (pinouts here)
2. 2x ISDN VIC/VWIC cards
3. Enough PVDMs to handle the ISDN card
4. Cisco routers with appropriate feature set

Using the isdn protocol-emulate command, one ISDN card is set to act as the network side & the other the user side. They're then cabled together using the crossover cable & suitable dial-peers configured to allow calls.
My test rig was a 3845 equipped with a PVDM2-64 & 2x VWIC-1MFT-E1, using my nifty Universal Network Cable for crossover. Config snippets below:

isdn switch-type primary-net5
!       
controller E1 0/0/0
 clock source internal
 pri-group timeslots 1-31
 description Network E1
!
controller E1 0/1/0
 pri-group timeslots 1-31
 description User E1
!
interface Serial0/0/0:15
 no ip address
 encapsulation hdlc
 isdn switch-type primary-net5
 isdn protocol-emulate network
 isdn incoming-voice voice
 no cdp enable
!
interface Serial0/1/0:15
 no ip address
 encapsulation hdlc
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn negotiate-bchan
 no cdp enable
!
voice-port 0/0/0:15
 cptone GB
 bearer-cap Speech
!
voice-port 0/1/0:15
 cptone GB
 bearer-cap Speech
!
dial-peer voice 1 pots
 incoming called-number .%
 direct-inward-dial
 port 0/0/0:15
!
dial-peer voice 2 pots
 destination-pattern .T
 incoming called-number .%
 direct-inward-dial
 port 0/1/0:15


Using some test IP phones to place calls, you can see from the debug isdn q931 output that the call exits Se0/1/0 & enters Se0/0/0:

*Oct  3 14:37:22.591: ISDN Se0/1/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Calling num 200
*Oct  3 14:37:22.591: ISDN Se0/1/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Called num 123
*Oct  3 14:37:22.591: ISDN Se0/1/0:15 Q931: TX -> SETUP pd = 8  callref = 0x0136
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1839F
                Preferred, Channel 31
        Progress Ind i = 0x8183 - Origination address is non-ISDN 
        Calling Party Number i = 0x0180, '200'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x81, '123'
                Plan:ISDN, Type:Unknown
*Oct  3 14:37:22.599: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x0136
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1839F
                Preferred, Channel 31
        Progress Ind i = 0x8183 - Origination address is non-ISDN 
        Calling Party Number i = 0x0180, '200'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x81, '123'
                Plan:ISDN, Type:Unknown
*Oct  3 14:37:22.603: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x8136
        Channel ID i = 0xA9839F
                Exclusive, Channel 31
*Oct  3 14:37:22.607: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8  callref = 0x8136
        Progress Ind i = 0x8188 - In-band info or appropriate now available
*Oct  3 14:37:22.607: ISDN Se0/1/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x8136
        Channel ID i = 0xA9839F
                Exclusive, Channel 31
*Oct  3 14:37:22.611: ISDN Se0/1/0:15 Q931: RX <- ALERTING pd = 8  callref = 0x8136
        Progress Ind i = 0x8188 - In-band info or appropriate now available
*Oct  3 14:37:27.759: %ISDN-6-CONNECT: Interface Serial0/0/0:30 is now connected to 200 N/A
*Oct  3 14:37:27.759: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x8136
*Oct  3 14:37:27.763: ISDN Se0/1/0:15 Q931: RX <- CONNECT pd = 8  callref = 0x8136
*Oct  3 14:37:27.763: %ISDN-6-CONNECT: Interface Serial0/1/0:30 is now connected to 123 N/A
*Oct  3 14:37:27.763: ISDN Se0/1/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x0136
*Oct  3 14:37:27.767: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x0136
*Oct  3 14:37:33.759: %ISDN-6-CONNECT: Interface Serial0/0/0:30 is now connected to 200 N/A
*Oct  3 14:37:33.763: %ISDN-6-CONNECT: Interface Serial0/1/0:30 is now connected to 123 N/A
*Oct  3 14:37:34.567: %ISDN-6-DISCONNECT: Interface Serial0/0/0:30  disconnected from 200 , call lasted 6 seconds
*Oct  3 14:37:34.567: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x8136
        Cause i = 0x8290 - Normal call clearing
*Oct  3 14:37:34.571: ISDN Se0/1/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x8136
        Cause i = 0x8290 - Normal call clearing
*Oct  3 14:37:34.571: %ISDN-6-DISCONNECT: Interface Serial0/1/0:30  disconnected from 123 , call lasted 6 seconds
*Oct  3 14:37:34.571: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x0136
*Oct  3 14:37:34.575: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8  callref = 0x0136
*Oct  3 14:37:34.579: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x8136
*Oct  3 14:37:34.583: ISDN Se0/1/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x8136

For a proper ISDN PRI simulator you'd want to implement a complete inbound dial plan with call routing to some IP phones or analogue phones connected to FXS ports to handle test calls. Then it'll be possible to have a proper Unified Communications lab with simulated PSTN connections.

Training Materials

I've been working my way through the CCIE Voice Blended Learning Self-Study Solution from IPExpert that work bought me. It's definitely worth a look if you want to learn more about Cisco Unified Communications, it covers loads of stuff that's not in the CCNP Voice textbooks from Cisco Press.

Communications Manager Tools Part 1

I recently stumbled across a couple of very useful tools for any CUCM deployment. The first uses AXL & JTAPI to remote control Cisco IP phones and the second uses AXL to query the dial plan & report which numbers are in use. Follow the link below for more information:

http://toip-tools.org/en/

MGCP PSTN and QSIG Gateway

Whilst it's becoming ever less common, sometimes there's a need to integrate with legacy equipment, such as PBXs & voice mail systems via a QSIG trunk. Given that a QSIG trunk requires an ISDN interface on a router with PVDMs, it's logical to stick an extra interface into your PSTN gateway & cable it to the legacy device.
Problem is that with MGCP you've now got 2 endpoints with the same IP address, which causes problems with the audio streams. If you enable debug isdn q931 you'll see calls come in a voice port & exit the other, yet there's no audio between the callers. Fortunately the solution is easy - in the CallManager service parameters enable path replacement & tweak the minimum/maximum delay timers:

Cisco ESXi Licences

As Cisco is pushing virtualisation with their Unified Communications applications & UCS servers, you'll come across Cisco licence certificates for VMware ESXi licences.
It used to be that you went to the VMware OEM portal for Cisco for Cisco to redeem the licence keys to get the actual ESXi licence. For this you'll need an account on the VMware website to able to log in & redeem the licences, which you then enter into vSphere.
Now Cisco have started shipping actual licence keys for ESXi, but only for certain part codes:

• VMW-VS-HYP
• R-VMW-UC-FND
• R-VMW-UC-FND5-K9

To redeem these you enter the key directly into vSphere.

Lightweight AP Controller Discovery

Cisco's lightweight Access Points (AP) support discovering the Wireless LAN Controller (WLC) management IP address via several methods, including:

DNS Resolution
The AP tries to resolve CISCO-LWAPP-CONTROLLER or CISCO-CAPWAP-CONTROLLER using the DNS server configured by DHCP. However you may not have DNS A records for these, especially in small deployments with no DNS server onsite.

DHCP Option 43
The AP uses IP addresses provisioned via DHCP option 43. This consists of a hexadecimal string starting with F1, the number of WLCs multiplied by 4 & the IP addresses of these WLCs in hex. For example one WLC with IP address 10.35.128.5:

1 x 4 = 04 (must be padded to 2 hex digits if less)
10.35.128.5 = 0A238005  (must be padded to 8 hex digits if less)
Resultant hex: F1040A238005

Adding a 2nd WLC with IP address 10.35.128.6 would result in F1080A2380050A238006.

Broadcasts
If the WLC is in the same broadcast domain & has Master Controller Mode enabled the AP can discover it by sending out broadcasts. This won't work in large deployments where APs are spread across multiple networks & is considered bad practice.

Over The Air Provisioning
The AP listens to Radio Resource Management (RRM) messages transmitted by neighbouring APs & learns the WLC IP address from these. However this is considered insecure & usually disabled.

Priming
You can connect a console cable to the AP & manually configure with the WLC's IP address using the lwapp ap controller ip address command. This only works on APs that haven't yet associated with a WLC, but is useful if you have an AP that's refusing to associate via the other methods.

Unified Communications Applications & VMware

Isn't it nice now that all the Cisco Unified Communications applications officially support virtualised installation on ESXi running on a Cisco UCS series server? However there's a couple of tweaks that need to be done to get the best performance out of these virtualised installs, fortunately Cisco provide instructions for both:

1. Disable Large Receive Offload (LRO)
2. Ensure the latest VMware tools are running

Without tweak 1 you can get poor network throughput on the virtual install, which can be a right pain for backups!

UPDATE: With the migration to Red Hed Enterprise Linux 5.0 in CUCM 8.6, disabling LRO is no longer required.

CCA Console

Ever wondered what CCA is upto? Especially as sometimes it takes ages to carry out a task!
Simply press F2 to open the console & you can see the activities it carries out behind the scenes. The screenshot below shows what's happening during installing a software pack:

Deleting Unity Connection Locales

Unfortunately Unity Connection has suffered a number of bugs relating to locales, including:

• Certain 8.5 versions of the UK English locale breaking the ability to leave voicemail messages
• Some versions of 8.5 & 8.6 unable to have upgrades installed if a non-US English locale is installed

The solution to either of these problems is to remove the locale which has to be done via the CLI.
First check which locale is installed use show cuc locales:

admin:show cuc locales

Installed Locale Package    Locale
--------------------------  ------
uc-locale-en_GB-8.6.2.1-12  en-GB

Next stop the Connection Conversation Manager & Connection Mixer services via the Cisco Unity Connection Serviceability GUI. Then delete the locale with delete cuc locale:

admin:delete cuc locale en-GB

en-GB uninstalled

You can then install whatever updated locale, upgrade patch, etc. is required to resolve the locale issue.

Kludging NAT for Communications Manager SIP Trunks

Ideally when using a SIP trunk to an external provider for PSTN connectivity with Communications Manager you'd use a Unified Border Element (UBE) in media flow-through mode to handle SIP to SIP inter-working & present a single IP address for NATing on your Internet router. But what happens when the customer is too cheap to pay for a UBE? Well if the SIP trunk requires registration or the SIP headers formatting in a way the CUCM doesn't like then you're out of luck! Otherwise you can kludge an IOS router into handling the NATing to a single IP address.
The problem stems from the fact that unless you enable "MTP required" Communications Manager handles a SIP trunk like an UBE in media flow-around mode - it handles protocol inter-working but the RTP audio streams pass directly between endpoints. This means that you have to NAT port 5060 to the CUCM server for the SIP traffic, but also NAT the phone's subnet too. Even if you do enable using an MTP, with multiple servers there could be multiple MTPs with different IP addresses.
The configuration below works assuming your IP address for NAT is 1.2.3.4, the CUCM server is 10.1.1.2, the phones reside in the 10.1.1.0/24 network & the SIP trunk is 4.3.2.1:

ip inspect name FIREWALL tcp
ip inspect name FIREWALL udp
ip inspect name FIREWALL sip
!
interface FastEthernet0
 description Outside interface
 ip address 1.2.3.1 255.255.255.248
 ip access-group OUTSIDE_IN in
 ip nat outside
 ip inspect FIREWALL in
 ip inspect FIREWALL out
interface FastEthernet1
 description Inside interface
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
!
ip access-list extended OUTSIDE_IN
 permit tcp host 4.3.2.1 host 1.2.3.4 eq 5060
 permit udp host 4.3.2.1 host 1.2.3.4 eq 5060
 deny   ip any any log
access-list 2 remark Voice subnet
access-list 2 permit 10.1.1.0 0.0.0.255
!
ip nat pool phones 1.2.3.4 1.2.3.4 netmask 255.255.255.252
ip nat inside source list 2 pool phones overload
ip nat inside source static udp 10.1.1.2 5060 1.2.3.4 5060 extendable

This kludge works as we've done a static port NAT to the CUCM server & allowed it in the access-list, this allows call control messages in & out. The SIP inspect punches holes in the access-list to allow the RTP inbound (outbound is allowed anyway). The SIP NAT ALG (application layer gateway) fixes the SIP headers to have the right IP addresses & port numbers. You can confirm this via show ip nat translations which shows the phone's being NATed as well as the CUCM server:

Pro Inside global   Inside local          Outside local   Outside global
udp 1.2.3.4:5060    10.1.1.2:5060         4.3.2.1:5060    4.3.2.1:5060
udp 1.2.3.4:5060    10.1.1.2:5060         ---                   ---
udp 1.2.3.4:32366   10.1.1.21:32366       4.3.2.1:30118   4.3.2.1:30118
udp 1.2.3.4:32367   10.1.1.21:32367       4.3.2.1:30119   4.3.2.1:30119
udp 1.2.3.4:26642   10.1.1.24:26642       4.3.2.1:21068   4.3.2.1:21068
udp 1.2.3.4:26643   10.1.1.24:26643       4.3.2.1:21069   4.3.2.1:21069
udp 1.2.3.4:19462   10.1.1.26:19462       4.3.2.1:31900   4.3.2.1:31900
udp 1.2.3.4:19463   10.1.1.26:19463       4.3.2.1:31901   4.3.2.1:31901
udp 1.2.3.4:29940   10.1.1.26:29940       4.3.2.1:20970   4.3.2.1:20970
udp 1.2.3.4:29941   10.1.1.26:29941       4.3.2.1:20971   4.3.2.1:20971
udp 1.2.3.4:25306   10.1.1.28:25306       4.3.2.1:25398   4.3.2.1:25398
udp 1.2.3.4:25307   10.1.1.28:25307       4.3.2.1:25399   4.3.2.1:25399

Kludging Power over Ethernet Power Allocation

PoE capable switches keep track of the amount of power they've allocated to devices to prevent oversubscription of the power supply. PoE devices are categorised into classes of power consumption:

Class	Power allocation
0	15.4W (default)
1	4.0W
2	7.0W
3	15.4W

A PoE capable device can inform the switch via CDP or LLDP of its power class & the switch will deduct the relevant amount from its power allocation budget. You can view the switch's current power allocation via show power inline:

Available:370.0(w)  Used:115.3(w)  Remaining:254.7(w)


Interface Admin  Oper       Power   Device              Class Max
                            (Watts)                          
--------- ------ ---------- ------- ------------------- ----- ----
Gi0/1     auto   on         12.0    IP Phone 7945       3     15.4
Gi0/2     auto   off        0.0     n/a                 n/a   15.4
Gi0/3     auto   off        0.0     n/a                 n/a   15.4
Gi0/4     auto   off        0.0     n/a                 n/a   15.4
Gi0/5     auto   off        0.0     n/a                 n/a   15.4
Gi0/6     auto   off        0.0     n/a                 n/a   15.4
Gi0/7     auto   on         9.0     IP Phone SPA525G2   0     15.4
Gi0/8     auto   off        0.0     n/a                 n/a   15.4
Gi0/9     auto   off        0.0     n/a                 n/a   15.4
Gi0/10    auto   on         15.4    AIR-AP1042N-E-K9    3     15.4
Gi0/11    auto   off        0.0     n/a                 n/a   15.4
Gi0/12    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/13    auto   off        0.0     n/a                 n/a   15.4
Gi0/14    auto   off        0.0     n/a                 n/a   15.4
Gi0/15    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/16    auto   on         6.3     IP Phone 7941       2     15.4
Gi0/17    auto   on         6.3     IP Phone CP-524S    2     15.4
Gi0/18    auto   off        0.0     n/a                 n/a   15.4
Gi0/19    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/20    auto   on         6.3     IP Phone 7961       2     15.4
Gi0/21    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/22    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/23    auto   off        0.0     n/a                 n/a   15.4
Gi0/24    auto   off        0.0     n/a                 n/a   15.4

Now there's two problems, a lot of switches aren't actually able to provide the whole 15.4W to every port & a lot of devices don't actually consume as much power as their class implies they do. This means that you may encounter situations where you need to power an extra PoE device but the switch has reached its power allocation limit. Fortunately Cisco let you override the automatic power allocation value on a per interface basis, allowing you to squeeze a couple more PoE devices out of the power allocation. The command is power inline consumption:

interface GigabitEthernet0/1
 power inline consumption 4000

Now show power inline now lists interface GigabitEthernet 0/1 as using 4W. Note that the phone is still powered & using however much power it draws, changing the power allocation affects only the switch's record keeping...

Available:370.0(w)  Used:107.3(w)  Remaining:262.7(w)

Interface Admin  Oper       Power   Device              Class Max
                            (Watts)                           
--------- ------ ---------- ------- ------------------- ----- ----
Gi0/1     auto   on         4.0     Ieee PD             3     15.4
Gi0/2     auto   off        0.0     n/a                 n/a   15.4
Gi0/3     auto   off        0.0     n/a                 n/a   15.4
Gi0/4     auto   off        0.0     n/a                 n/a   15.4
Gi0/5     auto   off        0.0     n/a                 n/a   15.4
Gi0/6     auto   off        0.0     n/a                 n/a   15.4
Gi0/7     auto   on         9.0     IP Phone SPA525G2   0     15.4
Gi0/8     auto   off        0.0     n/a                 n/a   15.4
Gi0/9     auto   off        0.0     n/a                 n/a   15.4
Gi0/10    auto   on         15.4    AIR-AP1042N-E-K9    3     15.4
Gi0/11    auto   off        0.0     n/a                 n/a   15.4
Gi0/12    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/13    auto   off        0.0     n/a                 n/a   15.4
Gi0/14    auto   off        0.0     n/a                 n/a   15.4
Gi0/15    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/16    auto   on         6.3     IP Phone 7941       2     15.4
Gi0/17    auto   on         6.3     IP Phone CP-524S    2     15.4
Gi0/18    auto   off        0.0     n/a                 n/a   15.4
Gi0/19    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/20    auto   on         6.3     IP Phone 7961       2     15.4
Gi0/21    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/22    auto   on         12.0    IP Phone 7945       3     15.4
Gi0/23    auto   off        0.0     n/a                 n/a   15.4
Gi0/24    auto   off        0.0     n/a                 n/a   15.4

You can disable PoE completey via power inline never or restore automatic classification via power inline auto.

WARNING! You can cause the switch's power supply to become oversubscribed by forcing it power more devices than it can handle. This will result in brown outs where devices randomly don't receive sufficient power to function properly.

CME Hunt Group Final Not Being Reached

Given the following configuration, what do you think will happen when 7343 is called and no one in the hunt group answers?

ephone-dn 1 dual-line
 number 7241
 label Kathleen
 name Kathleen
 call-forward busy 5000
 call-forward noan 5000 timeout 20
 huntstop channel
ephone-dn 2 dual-line
 number 7254
 label Eleanor
 name Eleanor
 call-forward busy 5000
 call-forward noan 5000 timeout 20
 huntstop channel
ephone-dn 3 dual-line
 number 7258
 label Natasha
 name Natasha
 call-forward busy 5000
 call-forward noan 5000 timeout 20
 huntstop channel

voice hunt-group 5 parallel
 final 5000
 list 7254,7258,7241
 timeout 30
 pilot 7343

Contrary to expectations, the call doesn't get forwarded to the hunt group final number of 5000. This is becaue CME won't ever use the final number in a hunt group if the time out on the hunt group is greater than the time out defined in the ephone-dns! 

UCS C200 Series Power On After Power Failure

We recently had a power cut in the office and our UCS C210 M2 server didn't automatically power back on. Normally there's a setting in the BIOS along the lines of "After Power Failure: Power On". After trawling through every option in the BIOS I couldn't find anything relevant - it turns out the setting is actually in the CIMC.
To access the CIMC GUI you need to make sure it has been configured, you can reach the configuration settings for the CIMC when the server is powering via these steps:

1. Press ESC to view POST messages
2. Press F8 to enter CIMC config

Keep an eye out whilst the server powers on and press the keys at the appropriate times - it'll say on screen. You can then set an IP address, etc.
Once the server's powerd on, go to the CIMC IP address in a web browser, e.g. https://192.168.111.175. If you've not set a username and password the defaults are as follows:

Username: admin
Password: password

Select the Sever tab on the left hand side of the screen, then Power Policies and select the Power Restore Policy you want:

Click Save Changes and you're done.