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.

The CUCM 6.1 moan

We recently upgraded to CUCM 6.1 and 6.0 - and the main reason for this was the fact that 6.0 was full of bugs. 6.1 is no better sadly and we still have "interesting" things happening:

• Pressing the DND button leaves a "???" on the phone screen.
• Call Pickup Group notifications have randomly stopped working (for certain people)
• Calling certain numbers results in a "fake display" appearing on the phone screen in the CLID area.
• The BAT tool is still a bag of crap.
• Sometimes faxes stop working randomly.
• System slowness

Grrrr! They're fairly minor issues but if I can try to sort them, will post up!

Been a while!

As always a busy guy, and have been installing 6500's over night for customer's and a few other bits and bobs. I also got to go on a Palmersport day which was incredible! Being able to drive a single seater sports car similar to a Formula 3000 car was just mind blowing - though I proved I had a lot to learn if my driving skills were to be as high as Louis Hamilton!

Just a word to say that I treated myself to an IBM X41 Tablet PC! I found myself using the UMPC less and less due to the speed of the unit and I can now safely say that the X41 has replaced my T60 in the office! I can now grab my PC and start writing when a support call comes in. I also plonked Vista SP1 and it's pretty quick (suprisingly!).

My ex missus went a bit mad though and decided to snap my UMPC pen (lol!), so if anyone knows where I can buy an Asus R2H Stylus please let me know!

Handy hint for 6500 switches

If you're looking to find out the serial numbers of SFP's installed in your chassis, but can't be bothered to find out by unplugging everything, you can use the following command in IOS. This doesn't include CatOS (it's a different command). Don't forget to no shut your interfaces before checking:

show idprom interface gigabitEthernet 1/1 include Vendor SN

The include part is optional. :)

Getting intimate with some 6509 switches :)

Well it had to happen - I finally got my hands on some real expensive kit! Allow me to show you:


The kit arrived on pallates, lots of them! And blimey they're huge!





After we finally shifted through all of the boxes we were left with 4 beasts (3 pictured):





Once we had all of the components unwrapped we started to assemble the chassis. I didn't include any pics of the dual 6000W PSUs (Hot swappable, dual input, essentially made up of two 3000W PSU's internally) because they were quite boring. The box can be powered up from a single input on a single PSU. The below Sup720 with 10Gigabit Fiber however, is definitely not boring:

The Sup720 is made up of a a PFC and MSFC for both forwarding and routing engines. All intelligence of the chassis is run from here, and the box won't boot without it installed. The box also won't boot without a fan tray:

The Sup720 can only be installed in slots 5 or 6 of the 6509 switch. Notice from the pic below that the backplane for slots 5 and 6 is wider than all the others. Slots 1 and 2 buses are wider too (apparently for when Sup cards used to reside in these slots) however no advantage can be gained by installing any cards in these slots.

In the other two slots we installed some new 48port Gigabit line cards and 24port SFP Gigabit line cards. Each SFP card had 14 Fiber SFP's installed in it. We had both cards set up with a DSFC which means that they are able to make their own decisions (instead of using the PFC on the Sup720). Which ultimately means less pressure on the Sup card.

Fully loaded baby! Time to play!

First post in a while!

So I doubt I have many avid readers but I may as well update on personal things too. I guess that's what it's for!

Since the ISDN word problem I set up a cucMBE system for u customer, broke up with my girlfriend, did another job in Scarborough (God it was cold), and finished up with a job today in Illinois USA. One busy guy!

I have a couple of bugs to write up here but I felt that sorting out my expenses and other affairs was more important! We also take delivery of 4 6509 switches tomorrow! Fun! Can't wait to get hold of those!

We are now a Nokia accredited partner so hopefully will update soon on some advanced phones to come into the office. Check back soon for that.

Mike out.

ISDN (wierd) problem

Well today I discovered an odd issue with a new customer network. For some reason, if the External phone number mask on a phone was anything else than what was deemed "valid" such as when (example numbers used):

Trunk number: 01234 115115
DDI number: 01234 115200
Valid EPNM to send is "200"
Invalid number such as 01234 115200 results in CLI presented to called party as 01234 115115.

...then the call would not complete. IE, if I sent 01234 115200 to the PSTN then the following symptoms would occur:

• IP Phone gets busy tone
• My mobile phone would ring out for half a ring, presenting 01234 115115 before hanging up. Odd!
• What's more is the debug isdn q931 from the Cisco router:

*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

Yes that's right! The call completes, yet the Q.931 debug says the bearer isn't available! It did make me wonder whether i'd configured too many bearers than the customer had paid for, but by a stroke of luck I determined that sending the correct CLI to the PSTN allowed the call to proceed:

*Jan 26 09:04:53.326: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Calling num 200*Jan 26 09:04:53.330: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Called num 07989163892*Jan 26 09:04:53.330: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x011A 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, '200' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '07989163892' Plan:Unknown, Type:Unknown*Jan 26 09:04:53.534: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x811A Channel ID i = 0xA98399 Exclusive, Channel 25 Notification Ind i = 0xE8*Jan 26 09:04:56.770: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x811A*Jan 26 09:04:58.538: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x011A Cause i = 0x8090 - Normal call clearing*Jan 26 09:04:58.706: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x811A*Jan 26 09:04:58.710: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x011A

Blackberries

We lost the blackberry's!

WAH

:-(