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.
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.