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.

First impressions of the new HTC Diamond

Yes ladies and gentlemen, I have yet again upgraded early due to my irrational attraction to shiny things.

I'll try to keep this brief as I have a steak under the grill (And you can find stuff like this all over the web):

• This device is sexy! In fact it's the first HTC device that I really think will attract the consumer rather than the businessman. It's feature-packed, easy to use, has a much better camera (though still no flash), and it doesn't cost iPhone prices...
• The built in GPS is somewhat fiddly to get going with TomTom but is a great addition
• The device attracts scratches - you'll find it difficult to sell this on Ebay "scratch free" after you've owned it for a while. Bear that in mind!
• The battery life is terrible (I think i've got a phone from a bad batch) and has lasted as little as a day with light useage. Some are suggesting that this is down to the ROM being used and it may be updated soon if enough people complain about it.
• Internet Connection Sharing works brilliantly with Vista, and allowed me to get up to great speeds on my laptop using the phone as a modem.

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.