Showing posts with label CallManager 6. Show all posts
Showing posts with label CallManager 6. Show all posts

Sunday, 27 July 2008

Yet more issues with CallManager 6.0

Yet another bug with Cisco CallManager 6.0. Sigh. This was identified in version UCOS_ES_6.0.1.3103-1.

We found similarly to a previous post that when we tried to dial out, we got the following debug with "Bearer/channel not available". However we found in that this instance, changing the CLID made no difference, we verified that the customer had specified the correct number of B channels on their PRI, and attempts to use commands such as "bchan-order ascending" made no difference.

*Jan 26 09:01:29.606: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Calling num 01234115200*Jan 26 09:01:29.610: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Called num 07989163892*Jan 26 09:01:29.610: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0117 Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98399 Exclusive, Channel 25 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x0081, '01234115200' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '07989163892' Plan:Unknown, Type:Unknown*Jan 26 09:01:29.822: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8117 Channel ID i = 0xA98399 Exclusive, Channel 25 Notification Ind i = 0xE8*Jan 26 09:01:33.614: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8117*Jan 26 09:01:33.654: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x0117 Cause i = 0x80AC - Requested circuit/channel not available*Jan 26 09:01:33.830: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x8117*Jan 26 09:01:33.834: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0117

As it turned out, we were using 7945 and 7965 phones (Which id never seen before, though are worth the money over a 7961 etc!). Turning off G.722 Wideband codec on the phone fixed the problem! You may wish to think about changing the Enterprise parameter and resetting all phones if you aren't going to use this codec in your enterprise.

More issues with CallManager 6.0

I recently rolled out CallManager 6.0 for a customer and rather disappointingly we ended up having to apply an Engineering Special patch to fix the problems. Rather alarmingly, we found these bugs in version 6.0.1.3000-7:

  • Attendant Console is unable to allow you to select a Device Profile (Unable to change MAC address) however Attendant Console works fine when you choose to use a phone that is statically configured rather than using Extension Mobility.
  • Adding a new Device Profile to CallManager causes ccm.exe (or the Linux equivalant at least) to hang. Symptoms include CFWD state unchangeable, and attempting to log in/out of Extension Mobility causes the phone to endlessly say 'registering'.
  • Device profile Service URL is being overwritten by the actual devices' SURL. The symptom presents itself as the service URL that was being shown on the phone when the phone is EM logged out can still be seen when the phone has been logged into EM.

What's disappointing is that all three of these bugs were fixed in previous versions of CallManager 6, and somehow Cisco has allowed these bugs to get through to a later version. Does it have something to say about their Quality Control procedures???

Anyway. These bugs are all fixed in ES UCOS_ES_6.0.1.3103-1 or CallManager 6.1. Speak to Cisco TAC for further assistance.

Tuesday, 27 November 2007

Advice on CallManager 6 BAT tool

I hate BAT. I truly think that Cisco have actually made the BAT tool more unusable this time round and it sucks!

My advice to you is to start BATting earlier in your implementation process as it's likely to take you a longer amount of time (and leave you with bald patches with all the head scratching).

Oddities include:
  • All sorts of odd fields crop up when you export Device Profiles (most of which are blank) such as Device Pool! When I exported a Device Profile i'd configured and then deleted it from the system I found that (without editing) I couldn't use that exact file to import the same record because I got a "Audible Message Waiting" field was not a valid field. Stupid thing...
  • The User export now contains a "PKID" field which looks to be the CallManager's Primary Key field for users in the system. Attempts to import users while leaving this field blank failed due to a "Duplicate value in index field" error. To fix it I had to generate 250 hex strings and stick them into the spreadsheet.
  • Both the Phones import and the Device Profiles import failed to recognise that I had configured a Service and Service URL buttons. Every attempt to get this to work failed and I ended up manually adding Extension Mobility Service to 250 phones and 250 Device Profiles. I hope I never have to do a 1000 phone system using CM6 - it would just be a nightmare...

Fun!

Monday, 5 November 2007

Just a quick catch up...

Unfortunately I haven't had time for many things over the past week. But with install number 2 out of 3 gone live this morning - and all working well; i'm in good spirits!

So just as a quick catchup post i'll mention a few things:

  • Thanks to Stef for offering me a trial version of NetMotion software. Basically it's a very similar product to the Windows Mobile Device Manager software I discussed in my previous post. However hopefully it'll prove to be a well established bit of software - that more importantly is available now and supports my phone. I haven't even managed to download it yet though lol - will grab it soon and report back.
  • The latest install had an interesting problem which personally i'd not seen before - but i'm sure a few people have! We moved the E1 connection from an old PBX to the new gateway but found that no calls would go out - giving us a PSTN message like "Number not recognised". We tried alot of different things such as changing the Type and Plan fields of the ISDN messages, made sure of the formatting of the numbers correctly, and one or two other misguided fudges. As it turns out, the customer had no idea they used carrier pre-select, which meant we had to prefix a number such as 1200 onto the front of the number before it got sent to the PSTN. We happened upon this luckily because someone happened to know a thing or two about how to get on the old PBX, and the 1200 number appeared quite a few times...
  • A nice discovery on a previous installation was that you could do a Call Forward All to literally XXXX. I'll talk about this in my next post.

So last installation to sort out! It's nice and complex which should be fun, and involves CallManager 6.0 Business Edition, a QSIG to DPNSS trunk, a Quescom GSM Gateway, and IPCC Express. Hooray!

Thursday, 25 October 2007

Another problem with Mobility in CallManager 6.0 - Dual Mode Phones...

Bah another problem has reared it's ugly head...

In our office we have been successfully been using Dual-Mode mobile phones on our CallManager system. Basically this is either a Nokia E60 or E65 phone running SCCP software provided by Nokia, which uses Wifi to connect to CallManager. When calls come in to the DDI the Nokia has a shared line that also rings out at the same time so you can answer the call on either device - great so far!

The problem is that when the DDI gets called, it calls both the GSM line and the SCCP line of the dual mode phone at the same time - which is rubbish.

Documentation on Mobility at the moment appears to be incredibly poor. :(

Sunday, 21 October 2007

Busy!

Wow the next few weeks are going to be busy! I'm currently migrating a CallManager 4 platform to 5 (Which sadly involves Arc, Witness and Oak); installing a couple of new site's IPT for another customer (100+ phones, Unity Call Handlers and other stuff), and the rollout of CallManager 6 Business Edition + Mobility + Quescom GSM + IPCC Express + other rubbish for another customer.

I need a holiday!

P.S popped by the local Orange shop and got my hands on the HTC Touch - it's smaller and cuter than you think! I encourage anyone interested in it to go and get a hands on demo. Also I had a go with what looked like the TYTN II, with a hinged keyboard, but it could have been some other HTC device - there's so many I get confused!

Tuesday, 16 October 2007

Upgrading from Cisco CallManager 5.x to 6.x

Due to the fact that I have to roll out CallManager 6.0 for a customer in the UK before December this year we have now taken the plunge in the office!

Upgrading was a fairly simple matter - however (as usual) wasn't the same as the documentation described. Basically we were supplied with an upgrade disc and license PAK, with which you use to move to the new platform by way of a tar.gz file on the upgrade disc. Nicely, this had the big advantage of upgrading the CallManager server through the 5.1 GUI (in the same manner that you would any CM 5.x upgrade patch) and then simply rebooting into the new partition. All phones upgraded themselves - Robert's your father's brother. It wasn't quite as smooth as that though because our PAK code didn't work so we had to raise it on Cisco TAC.

So first impressions for me? Well the interface is a nice blue colour and the two great things about the 6.x GUI are the fact that the drop down box on the top right of the page now fits into a 1024x768 screen; and thankfully Cisco haven't moved things around too much - yay.

I think the first impressions were good as i'm used to the 5.x interface though those upgrading from 4.1 will find it quite tricky to navigate through for the first time.

The phones (when rebooting) now show the new Cisco logo as part of the device pack!

After the upgrade we did have a few niggles - the CM service stopped working and the service needed a kick; our MPE integration stopped answering calls because for some reason it had changed the Route List to something other than the MPE trunk; and Presence status stopped working in Cisco Unified Presence Server 6.0 and the server needed a reboot.

The only thing we haven't been able to fix is a service URL that's on everyone's Extension Mobility device profile to unlock the front door; which bizzarely has been replaced with the Extension Mobility service. In CallManager, the device profile shows the correct service URL applied to the speed dial but the phone shows otherwise. Removing the service URL and re-adding it before logging in/out of EM also does not solve the issue.

Update: None of the help pages work! They all give 404 errors - odd.

So that's the bad stuff. The good stuff is:

  • We now have syncronization between the Publisher and the Subscriber so that if the Pub goes down we don't lose functionality such as CallForward status, Extension Mobility, and others
  • We have mobility and single number reach built in! Also comes with new 'mobility' softkey
  • Improved SRST support
  • An intercom feature has cropped up in the list (woo!)
  • Directed Call Park has turned up
  • VERY IMPORTANT: Pickup Group Notification is back! It was missing from all CallManager 5 versions and in alot of instances this is a must have for customers!
  • Slightly improved BAT tool

I'll be configuring Mobility and Single Number Reach soon! More to come!