All calls to extensions 2XXX or 5XXX on MITEL 3300 result in reordertone

[mszodiac]

This has really puzzled me! I'm hoping someone can point me to the right direction.

I have MITEL 3300, release 5.2, SP2.  I programmed a 5330 IP phone with DN 2555.  but when I call it from an external phone (different system), I get a reorder tone.  Below is the CCS call trace.

What's weird is that I can call extensions 4XXX, 3XXX, 6XXX, but NOT 2xxx, or 5xxx.  This is happening only on this system.  Any ideas/thoughts will be greatly appreciated.

CCS Tracing is enabled for continuous output display                           
17:05:57 RIX DPN PBX1 154 1834 D** B** 2C ISRM_I                               
           ;10;*1#*19*X#*58*Ca*1*X#*58*CW*cEDv@@@@ATZWq@#                       
17:05:57 RIX DPN PBX1 154 1834 D** B** 23 SSRM_I                               
           *50*3092000#*58*C4*4*1#*58*C6*001#                                   
17:05:57 RIX DPN PBX1 154 1834 D** B** 1C SSRM_C                               
           *58*C4*4*1#*58*CO*B#3702555                                         
17:05:57 ROX DPN PBX1 154 1834 D** B** 2 CRM/CIM ;0;                           
17:05:57 RIX DPN PBX1 154 1834 D** B** 2 CRM/CIM ;0;     

[jrg0852]

Do you have 2 and 5 with 3 to follow in the ARS of the remote systems?

[Mattmayn]

I would start with the ARS. Can the 2xxx and 5xxx call all of the other sites? Isn't the Cluster Element ID supposed to match the length of the extension number? I see 3702555 there. Do you have a 370(4 to follow) route that points at the site where the 2555 extension is? What does the display on the phone say when you get the reorder tone?

[mszodiac]

Just an update... When we switched over to the resilient unit, I was able to call the 2XXX, 5XXX and every other extension! Which means ARS is programmed correctly. 

[Mattmayn]

Would all of the phones be on the same ICP when failed over? Do you share all ARS info between these two controllers? Just wondering how failing over proves that it isn't ARS.

[jrg0852]

I'm with Matt. Also check for SDS errors.

[LoopyLou]

The fact that when you switch over to the resilient system and can now call the numbers means you have problems in SDS. Do you see the extensions in the remote directory number form of the "different system"? In a cluster if you want to call a phone that is not on your element then it would need to either be found in your systems remote directory number form or you will have had to create ARS to direct the calls across your IP trunks.

[mszodiac]

Wow.  Thanks for all your replies.  It never crossed my mind that it could be an SDS error.  The way I described my resilient test wasn't very clear.  Here's how I did my test which lead me to believe the problem is with the primary controller.

1) removed the ethernet connection on the primary controller.  IP sets re-registered to the resilient controller. These IP sets are extensions 2xxx, 3xxx, and 5xxx
2) on the resilient controller, I programmed/registered a 5330 IP phone with DN 2555.
3) I was able to called 2555 number from another phone on the network, INCLUDING the 2xxx, and 5xxx that just failed over to the resilient controller
4) as soon as I reconnected the ethernet cable on the primary controller, all IP sets re-registered to the primary controller.  At this point, I was no longer able to call number 2xxx, and 5xxx numbers.

[LoopyLou]

Assuming from your post you have sets programmed on the primary from the two ranges 2xxxx and 5xxxx. Your problem then is when their primary MCD is up these sets can't be called but in failover mode they can. Also you can call 3XXXX and 6XXX extensions when the primary is up. Does that pretty much sum it up?

Do the 2xxxx and 5xxx sets show up properly in the remote directory number form of these other systems?