Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SX-200 ICP MX - Multicall issue

Status
Not open for further replies.

kwbMitel

Technical User
Oct 11, 2005
11,504
CA
SX-200 ICP MX - Multicall issue
SW Rel 4.0.4.9
Config:
- 1 ICP Controller (Bay 8)
- 1 ELX Per BAY (Bay 1)
- 1 PRI Card in Slot 10 (Bay 2) 23 Channels active
- About 50 4025 DNIC Sets, Zero IP Sets
- Embedded Voicemail
- Site is networked to 2 remote SX200's and 1 remote 3300


Problem:
I have about 15 sets programmed with a Multicall appearance of a Non-Prime DID. When a call comes into the system directly to the DID only half of the phones ring. It is always the same half and not random. A phone that rings and a phone that does not ring both can (and do) reside on the same DNIC card.

If the DID is dialed internally from another set, all phones ring.

If you dial in via a trunk to the auto-att and dial the DN, all phones ring

If you dial into the system via an IP Trunk from a remote site (3300) direct to the DID, all phones ring.

Conclusions
My first thought is insufficient DSP resources but I would think one or more of the other scenario's would fail if this were the case.

My second thought is to post this and see if anyone agree's with my conclusion or can offer up a better one.

Anyone?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
If it is insufficient DSP resources, you will get a Software Log. Any logs when this happens?
 
The only logs generated this week are regarding Print Test Failures (IP Port Config) at about 1 per day and a couple if ICP Connection errors.

Clean in other words.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
You are not running out of DSP resources then, otherwise you would see a log along the lines of 'Commit failed'.

It seems like it's a trunk/connection limitation. You say half, is that 7 or 8? If you reduce the programmed sets to 10, does the number that ring stay at the 7 or 8? Not sure what else to look for, sorry.
 
I don't believe it is a software restriction. The site that is currently a 3300 used to be a 200 with a similar setup. Most of the multicalls were Maxed out at 32 appearances without any issues.

Unfortunately this site is in a remote city so specifics are hard to come by on the totals. The customer said 6 phones ring and the rest do not. I said half as my confidence level in this number is low.

I'm going to review the release notes and see if any fixes were made with respect to Multicalls.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Nothing in the release notes.

Tempted to call TAC but without first hand observation I don't think they can help me.

I'm tempted to remove the keys from the non-working phones and then re-program them one at a time while testing.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Nice one kwb!
Just for fun...
The phones that don't ring, are they on BNIC or DNIC? BNIC has caused me problems (not like this though) in the past.
In the per node, is it a BCCII or BCCIII?
Is the pernode connected via FIM or CIM?
Same question for the PRI card?
In form 4 what is the setup for DSP config opt 132?
Based on the fact that you are using a PRI card instead of embedded, I'd upgrade that card cuz it might be ancient.
Also, there's a newer version of software (without going to 5) 4.0.5.15 ur5 and that plus the automatic upgrade of the BCCIII (if you have one) might do the trick.
If you decide to upgrade the PRI card or the BCCIII be careful. Older ones have a limited number of "Writes" to the flash and then they die. Any of those cards that have been through the repair centre in the last year are OK.

Dave


You can't believe anything you read... unless of course it's this.
 
Also, did this just start happening or was it a result of the 200ICP install?

Dave

You can't believe anything you read... unless of course it's this.
 
CanuckVoip.

I'm not interested in throwing money at the system in the hope that something will fix it. Same goes for labour/upgrades.

The issue resides on the same card working and non-working.

BCCIII and CIM connections.

Not sure about the DSP config but usually Business1.

I am not very hopeful on this one. I had this working without issues on a sister site back on release 2 and 32 multicalls. Irwin has eliminated the DSP's.

It looks like I might need to send someone to site to work with me. Are you interested? I think I remember that you are in the Vancouver area. Just kidding actually, unless you work for Bell that is.



*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
You're a good man kwb!

Looks like you are saying that the ringing problem resides on a card that also has working phones on it.
Is it a BNIC or DNIC? You can tell in maintenance.
Also, are the bad apps all on one card?
What slot is it in?
There are/used to be power considerations with those phones/cards/slots.
In other words, the first 4 slots have more power, and the top 6 ports on a card have more power.
Another consideration is what is programmed on a particular card.
If you had a console or other high power endpoints on a card problems can occur.
Seriously look at the card. If you think any of the above might apply, do some software moves of bad phones to a different card.

All kidding aside, it wouldn't be the first time we helped Bell out. :>)
A buddy of mine used to work for J&D and needed some help. Long story. We have also done installs and training for Bell.
I know that there aren't a lot of Bell techs that know Mitel in this city (at least that's the way it was).


Dave


You can't believe anything you read... unless of course it's this.
 
Now that I'm thinking about it again...
When you rebooted, was it a remote/software reset?
Something tells me that the per node didn't reload.
Maybe get the cust to power down/up the microwave oven?

Dave

You can't believe anything you read... unless of course it's this.
 
Update:

Nothing beats first hand observation!!!

Turns out the DN in question was routed to an entirely different key. The customer failed to mention that the key being answered did not match the key being dialed.

Just goes to show that no matter how many questions you ask, there are more that should have been asked.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top