Mar 25

Phones not Registering with Cisco UC560 System

Posted on March 25, 2015 by ben

Existing registered phones all work fine. They can make and receive calls, speed dials work etc. However adding new phones or if an existing phone is reset, they do not register. The phone displays a spinning icon with the word ”Registering”. When you do a debug ephone register and debug tftp events, you only see the tftp debugs come through and no debug logs for ephone register.

This is caused by the SCCP listening socket being shutdown under the telephony-service menu. By default on the UC 560 and other versions of CME, the SCCP listening socket is enabled by default. However if shutdown, phones are unable to register, however existing registered phones maintain their operations.

Resolve the issue by entering the below commands. The confirm you start seeing debug messages for ephone register.

Commands

(config)#telephony-service
(config-telephony)#no shutdown

NOTE: This post also relates to all Cisco CME versions.

Sep 10

CME Shared Lines – Quick Note

Posted on September 10, 2014 by ben

Shared Lines behave differently between CUCM and CME so much so that I find UC Administrators are getting a little muddled between whats normal and abnormal with Shared Lines configured in CME. Below is a quick note of the configuration and expected behaviour of CME Shared Lines for SCCP Phones.

General requirement of a shared line.

1. When a call comes in, I’d like it to ring both phones
2. If one phone is active, I’d like to have Call Waiting so I can see who is trying to call.
3. We should be able to receive more than two calls at a time
4. I also want the ability to hold, conference or transfer the call to another phone.

Sounds pretty standard right and out of the box CUCM does this by assigning a single DN to multiple phones, with a couple of DN tweaks like Busy Trigger etc. However CME on the other hand, if you were just to configure the a single ephone-dn and assign the ephone-dn to two phones like in the sample configuration below, you would see different results.

ephone-dn 1 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
!
ephone 1
mac-address 00E1.2D14.EEEE
ephone-template 1
max-calls-per-button 4
busy-trigger-per-button 3
button 1c1
!
ephone 8
mac-address 1C1D.8A24.EEEA
ephone-template 1
max-calls-per-button 5
busy-trigger-per-button 3
button 1c1

The above sample represents what seems to be a standard shared line setup, single DN, with the DN being assigned to two phones. The behaviour is as follows. Calls comes in, Both phones will ring, Phone 1 will answer the call. Next call comes in, seeing that Phone 1 has seized the line (currently on an active call) the inbound call will only ring on Phone 1, so Phone 1 will see a call waiting signal because we have configure the button with a ‘c’ however Phone 2 doesn’t ring at all. This is because by default there are two commands placed on each ephone-dn; huntstop and no huntstop channel. These two commands effectively tell the Router to stop hunting if ephone has an available line, which in this case it does, remember dual-line has been configured for the ephone-dn, so ephone-1 can still receive a second call on the second line, hence the call waiting signal being flashed to ephone-1. We need the second call to hunt to another ephone. Below is how we do it.

In the sample above we have added the no huntstop and huntstop channel commands to the ephone-dn 1 and also added a second ephone-dn with the same number. Then we have overlayed the second ephone-dn onto the first button. This allows for a second call on the DN 4000 to be routed to the second ephone-dn if a phone is active on a call. Plus this also allows for supplementary features like hold, transfer, conference etc, which requires a second line to complete the transaction.

Only one more problem to solve, one of the requirements was to have each phone be able to handle more that two calls simultaneously. All we have to do is add more ephone-dns to the configuration. The below sample configuration allows for four calls to the 4000 DN.

ephone-dn 1 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
no huntstop
huntstop channel
preference 0
!
ephone-dn 2 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
no huntstop
huntstop channel
preference 1
!
ephone-dn 3 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
no huntstop
huntstop channel
preference2
!
ephone-dn 4 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
preference 3
!
ephone 1
mac-address 00E1.2D14.EEEE
ephone-template 1
max-calls-per-button 4
busy-trigger-per-button 3
button 1c1,2,3,4
!
ephone 8
mac-address 1C1D.8A24.EEEA
ephone-template 1
max-calls-per-button 5
busy-trigger-per-button 3
button 1c1,2,3,4

Now we have all the requirements satisfied. So after reading the above its now worth noting the differences in shared line behaviour between CUCM and CME.

Aug 20

SRST Mode Auto-Provision All

Posted on August 20, 2014 by ben

Recently I was caught out with CME-SRST. This issue was ‘awoken’ by an actual failover event for one of the remote sites. When the CUCM solution was initially deployed SRST was tested in full among other services without issues. Phones registered to the SRST Router, tested inbound/outbound calls, voicemail routing to CUC (Head Office), also tested CME features and Media Resources, all these passed with flying colours.

I’m referring to the command “srst mode auto-provision [all , dn, none]” This is what effectively brought undone SRST. Using SRST CME mode is completely fine and I would recommend you configure any SRST Router in this mode, due to the additional features that can be accessed by remote users when in SRST mode. One big gotcha, if you configure the auto-provision mode to be anything other than ‘none’ then this saves the ephone-dn and ephone to the running configuration of the SRST Router.

What does this mean? Exactly what you think it means, the ephone and ephone-dn is now a part of your configuration, and if an ephone-dn is in the running configuration of the router, then the Virtual POTS dial-peer is in an UP state with a host specific dial-pattern [$] beating all others.
So when the remote Site is brought online again, the phones deregister correctly from SRST and register back to CUCM. BUT because the ephone-dn remains in the running configuration…. Yep you guessed it the Virtual POTS dial-peer remains UP. The biggiest issue is when this SRST router is also a local ISDN gateway for the remote site, the inbound calls will match….. the Virtual POTS dial-peer! No calls will ever route to CUCM.

This isn’t so much of an issue if the SRST Router does not terminate calls locally ie ISDN, as the inbound calls will never pass through the SRST router.
You will have to manually delete the ephone-dn’s effectively shutting down the related Virtual POTS dial-peer.

So my recommendation is too always configure SRST with auto-provision none. This ensure the ephone-dns and ephones do not write to the running configuration.

Like I’m mentioned in the beginning of this article, my initial failover tests worked like a charm, but was bitten by this little command.

Cisco UC

Collaborate Anywhere

Tag Archives: CME

Phones not Registering with Cisco UC560 System

CME Shared Lines – Quick Note

SRST Mode Auto-Provision All