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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Offset Filter Limitations on the Taddy

Status
Not open for further replies.

metballnut

Vendor
Oct 21, 2005
92
0
0
US
I have a tadiran IPX office, version 15 that has a PRI. I am using offset filters for the 4 digits from the phone company.
In my SIZ setings, the limit in setup is 64.

Here is the SIZ printout:

OFFSET_FILTER( 250) - 8
N_FILTER_ELEMENTS PER OFFSET FILTER ( 64) - 64


Currently, I have 87 ranges/filters (example, from 4913 to 4913 Coral # 1179)and the system will let me add 5 more or a total of 92 for the
From Received To Received Coral# fields.
4913 4913 1179

Does anyone know how this filter number limit is calculated?
I am only using offset filter #1. All other offset filters are blank.

Per the SIZ, I would think the limit is 64 - but, I do have 87 currently and have added 5 more "fake" ones just to test and then get the error command on the 93rd entry (wrong offset filter please check)

I know I can use libraries and shrink the number of entries, but this customer manages the system themselves and I can see the problem down the road of running out of offset filter space because they currently have 7-8 did ranges that are all over the place.

I just want to know if anyone can tell me how Tadiran calculates the total number of inputs into the offset filter?
Thanks
 
Not 100% sure on that one. Looks like you're a bit lucky to get what you've got in.

However, the way the Coral works is all related to the number of Indexes. Each Index takes up x amount of memory so the less Indexes you use, the more memory you save.

For example, in NPL it's best to do this...
FROM TO CORAL (Index, Slot/Card/Cct)
400 499 (0,1,0)
which will put xtn 400 on port 0/1/0, 401 on 0/1/1 etc and takes up one "block" of memory. Whereas if you did this...
FROM TO CORAL (Index, Slot/Card/Cct)
400 400 (0,1,0)
401 401 (0,1,1)
402 402 (0,1,2)
all the way to
499 499 (0,5,8)
that would be 100 "blocks" of memory.

The same goes for offset filters and other things. So it;s in your best interest, and the customer's, to keep things lining up as much as possible. Obviously when a new system goes in this should be easy to do. Over time xtns will move around and the NPL starts expanding but that's why you max out the SIZ as much as possible initially to stop the customer having to pay for you to rebuild it, and you from having to ASCII it.

Just to confirm, you have 87 individual entries in the offset filter ie 87 separate lines?? If so, looks like you're lucky. Either reSIZ or renumber things so xtns match DDIs.
 
Can't resize...the limit on the flash card is 64. The customer legacy did's are multiples, so the way it is is the way it is.
 
One thing you can try is to build libraries that match the 4 digit DNIS numbers that your receive from the CO. The libraries don't have to be programmed in the offset filter, Tadiran will match the DNIS number with any valid number that already exists in the system (in your case a library). Then you can route that libray to any extension/vmail port within the system.
 
Hey IPguy, thanks. I already knew that.
I guess I am just looking for the reason and/or limitation explained, not the workaround.
 
I have tried to find out but never had an explanation, it can be painful sometimes but as you know most people get around it with libs, sorry.

Also I wished you could assign another Offset filter for Night1 or Night2, it wold be handy sometimes.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top