Keep losing forwards E600

[chipig]

We have an IPS 2000 and I keep losing more and more call forwardings set with command E600.
I know for sure that I have saved with EC6.

I know our system is old since it's an IVS converted to a IPS but It's really annoying and it's getting worse day after day.
I also have problems with ISDN link and the WMI for the AD-64.

Is my PBX finally dying? Is there anything that I could check to fix it?

Thank you

 

[belevedere]

The system should not "lose" call forward data. This usually comes down to user error. First, are the phones involved the same ones? Do you have any service codes set up to cancel CFA and are the users accidentally dialing it? Do you have CFA set up on any line keys? Soft keys?
I suggest you delete any CFA cancel codes (CMD 200). Then set CFA up again. EC6 is the command to do an immediate back up to the flash drive. This is done automatically at 2 AM, so if the system is not reset the settings should be retained in the flash ROM.
ISDN and MCI links need to handled individually. Post a new ticket for each with detailed information for assistance.

 

[chipig]

It happens to virtual extensions . I have this (200>B5:A011) in cmd 200 for users that uses call forwarding with their digital phones but the problem is always for virtual extensions.
Users cannot use the code since many virtual extensions are forwarded to a single analog station which is not forwarded anywhere anyway.


Like theses:

E600>3417:2497-
E600>3406:2497-
E600>3370:2305-
E600>3373:2414-
E600>3374:2466-

And I lost all theses:

E600>3375:NONE-
E600>3376:NONE-
E600>3354:NONE-

And the list goes on and on .....

I don't get it....

 

[chipig]

I just did a listup of all my E600 and I have lost over 100 CFA virtual stations. It's pretty bad. Could it be a memory issue? Our system is quite big 8 full PIM (analogs and Dterm) with about 700 virtuals.

 

[OzzieGeorge]

If these are set and forget forwards, it may be easier to just create hunt groups for the pairs and then make the virtual extensions busy in command E50. I have come across systems losing call forwards especially with power outages but I have yet to come across a system losing a hunt group.

 

[belevedere]

A long shot, but with a fully loaded system depending on what your software issue is, as you add MLT's you lose VE's. It's a capacity issue. Ozzie's hunt group option may be your best solution.
FYI..in older systems reseating the CPU sometimes corrects strange issues. As the gold contacts tarnish and the back plane is disturbed (moving cards in and out) you get a poor connection. Make a back up, shut down then reseat the CPU power back up and test.

 

[chipig]

I lose VE what is this? Some kind of Memory...?
Here is something I have never seen with CMD E600:

E600>3827:7-7,3827
WAIT, BUSY NOW

I will give it a try with hunt group.

 

[chipig]

Would the hunt group releases some memory? It's getting pretty bad right now as I am losing forwards more and more.
I have reseated the CPU without success. I really need to get this fix quickly.
How is the memory shared across the PBX? What about deleting speed dial memory?

MLT: What does it stands for? Regular Dterm of Virtual one?

 

[belevedere]

MLT = multiline terminal. D-Term.
Go to CMD 11, then put in the last virtual len number possible and see what is says.
Software version 3300 and below has 000-255. 3400 and above has 0000-1019.
If you are using MatWorX, then the software version is on the top line when logged in.
E600, 7,3827, the 7 is a trunk access code like 9 followed by the number to be forwarded to.
E600, 7-7,3827 is not a valid entry.
Hunt groups have their own memory allocated and it does not conflict with or use up virtual memory. Only Dterms can impact virtual memory because of the overall system capacity. This situation was corrected when NEC added up to 1019 virtuals with software 3400 and above.
Usually virtuals are added to a DTerm to get an additional extension for call forward busy to roll over when DID's are provided. I have seen cases where a virtual was added to the wrong DTerm or added to an additional extension. The user was removing the forwarding on one extension and the duplicate user complained that they were losing their virtual forwarding. You may need to look at all of your key data to see if those virtuals are duplicated over several DTerms.

 

[chipig]

My last len is this:

11>0792:NONE-
SEE CM14 00122

I have SC-3385 version in Matworx.

E600, 7-7,3827 is a valid entry in my case since the virtual extension is forwarded to another system, I use 7 to access the trunk then I remove it when going out to ISDN.
People can call extensions in our new system from the NEC.

I do not use Virtuals that much for Dterm. My virtuals are for users that share the same line and want a mailbox number or users in the new system.

CFA uses memory too then?
My last len used is 0674 and I will need more...

 

[OzzieGeorge]

So you have a new system and you are using virtuals to get calls to the new system? Why are you not using LCR? There is provision in LCR to be able to split number ranges between the two systems on a number by number basis.

 

[chipig]

I have used LCR for the trunk but I never thought using it number by number. 2xxx and 3xxx extensions exist in the new and old system.
Are you saying I could use LCR for each extensions even though the first digit exist in both system

For example:


Extensions in new system:
3835
3532
2526
3222

Extension in NEC:

3836
3569
2635

 

[belevedere]

11>0792:NONE-
SEE CM14 00122 This means that an extension already exists in CMD 14, LEN 00122 (DTerm). This virtual LEN is unusable for a virtual. Confirm it by going to command 14, LEN 00122 and see what the extension number is.
As for LCR over CCIS, go to

http://www.nectekhelp.com

for examples and cheat sheets.

You should be using LCR table 4007 for the network routing. You can route by individual extension number, or by groups. It will take a lot of break outs.
EX: 200>2>A129
8AA000>3>4007
8A4007>2000>804 = a station number in the local system
8A4007>2001>0043 = a route pattern table.
See the examples on that web site.

 

[chipig]

Yes there is indeed a Dterm assigned to this len:

14>00122:F2637-

As for LCR I know I should be able to route all the extension starting with 31,37,38,39 so it should gives me a lot of free virtual lens.
I will go ahead and start using LCR a bit more.It should be more efficient than virtuals and forwards I guess.
LCR for individual stations, I cannot wait to test it.

Thank you very much for your great tips! I'll let you know how it goes.

I just hope I don't get nuts using LCR, I just have to put more time into it I guess.

 

[OzzieGeorge]

I believe belvedere missed a digit in his example,

8A4007>2000>804 = a station number in the local system

Should read 8A4007>2000>8004

It is easy to do the change over using scripts and the Mach Script editor. Just use Excel and as an example put 8A4007 in the A column and extend it down to 100 cells making sure it copies the cell rather than range fills then in the B column put 2000 then extend it down this time filling the series so that the last cell reads 2099 then in the third column put 8004 and then extend that down using the copy fill so that all cells are the same value. Depending on your Matworx version you may need to put a star in column E and extend that down again (this ensures enough columns are recognized by Matworx). Save this as a .CSV file rather than as an Excel file this can then be imported into the Mach script editor and then written to the system and will have no immediate effect. You can then test it (having built the rest of the LCR pattern to handle it) by just toggling command 200 from 2000-804 to 2000-A129. You should still be able to dial all extensions. Then you simply go to 8A4007 and change the extension number you want to go to the new system to the 8A4007>2001>0043 = a route pattern table, as per Belvedere's example and that one extension will then go off to the other system, add more as and when needed.

If there are problems, just change Cmd 200 back to the way it was before and all will be back to normal.

One word of warning though if you just do this as a basic solution, you could end up with tromboning issues if calls get transferred a lot and that can chew up channels, but you will already have this if you are using forwards. CCIS is the way to go but there could be licensing issues.

 

[chipig]

Thanks, I was wondering why I could not find 804 in the command manual for 8A4007.
I will give it a try in Mach script. I've been using it a lot lately.

 

[chipig]

I have tested the huntgroup as well as LCR sucessfully. However the NEC will not send the calling extension number to ISDN.
I have looked all commands related to Caller ID in the command manual and still nothing.
The PN-DTA is programmed as a PRI 050>08>12. Does that change anything?
My other IPS (recent CPU version) sends the caller ID to ISDN with pretty much the same settings.

 

[belevedere]

Outgoing CID is handled with the following commands;
1212
1213
5005
08>400
If you are doing CID passthrough then add CMD's 8A5XXX>165 and 35145>XX (TK RT)
Verify A726 and A728 for the CCIS/ISDN channel.
ISDN PRI should be Ni-2 protocol.

 

[chipig]

I was able to setup everything with individual LCR and Caller ID. It is working great! Thank you very much for your great support.
I have another issue now with 911 calls but I will post another ticket.I hope I did not mess the 911 LCR. It is in another LCR table anyway.