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

Number Length

Status
Not open for further replies.

UKTurnip

Technical User
Aug 21, 2009
22
GB
Hi

I am moving from 4-digit extensions to 5-digit extensions - by prefixing all existing extension numbers with a '3'.

I am looking for a method of identifying callers coming in over my network connections who have dialled the old extension number (with insufficient digits) and to send them to a recording advising them of the required change. Callers who correctly dial will need to be connected immediately.

The problem is easily resolved through an incoming translation for those callers who are trying to reach any of my old extension numbers which do not begin with a '3'. However, as I already have 4-digit extensions beginning with a '3' I cannot just automatically insert an extra digit on incoing calls without first testing whether they have dialled the correct number of digits.

I therefore need to check the number of digits dialled on calls INTO my system with a leading '3' and if incorrect I need to route the caller to a recorded message.

Can anyone think of an elegant method that can be used (for example) by using the NLT - even if this requires spoofing an external route?

The ENT table will work up to a point (using 'conf' but is limited by the number of available entries (1000) as I would need all 1000 entries to achieve this method leaving no spare entries for other purposes.

Any help would be appreciated.
 
Which revision do you have? In TSW the ENT record is 2000 and SP7 has up to 7000 entries....
 
I take it then that your extension numbers do not match your DDI range or is this problem only on interconnections between your system and other PBX networks?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
umm,it IS supposed to do that, right??
 
Hi Guys

I am running MX-One Ver 3.2

Sorry - I missed that ENT has 2000 entries, still it doesn't really help though.

My issue is purely incoming private N/W calls where I will be getting a mixture of calls to my old 4 digit numbers and my new 5 digit numbers - where both types of number have the same first digits (3XXX).

I did try the ROVNI 'sday' & 'snig' settings (for incomplete numbers), but couldn't get it to work ('sel' bit 1 set to 7), although 'vac' did work for spare numbers - but only on PSTN lines i.e. not my n/w connections. If the incomplete number option (sday) could be made to work on inter-swirchboard lines it would be an ideal solution.

I have also tried setting 'conf' on entries in the LC ENT as follows:

Example

I added (old extension number) 3456 in LC ENT table with conf set and a trc/pre to change the dialled number to a recorded announcement extn. This works up until a point - if 3456 is dialled the system waits 7 secs for extra digits and if none recieved follows the trc/pre settings. This is exactly what I want as after my number change this would be an incorrectly dialled number and I would want to send it to a recorded message.

However, if a correctly dialled 5-digit number is dialled e.g. 34567 the call immediately drops out of the EN Table and into the NL Table - at this point I need to be able to strip off my added prefix (see below) and point the call at the (correctly) dialled extension.

Problems

Obviously any entries in the LC table cannot also be defined as extensions - I therefore had to add a prefix in the number_conversion to deliniate from the extnsion range.

When a correctly dialled call drops through the ENT table, it seems to be assumed by the system that the call is an O/G PSTN call (not an I/C N/W call). I therefore cannot easily strip off my added prefix and send it to an extension - unless I maybe back-to-back some lines and route the calls that way.

As stated in my first post - (because the MX-One doesn't support wildcard characters), I will need to input an entire block of 1000 numbers to check all possible misdials. I am already using over 800 entries so things will get pretty tight.

If anyone can think of an elegant method to point the calls that fall through the ENT table to local extensions please let me know.

I have also been experimenting with using number-conversion to sort this but with little success. I had thought that an entry in number_conversion assigned to a route would pass the call into the 'system' conversions (like on an iSDX) if no match found. Had this been the case I would have checked on the incoming route for the long version (5-digit) of a targeted extension and if found routed it correctly. If the short (old) version was dialled, the call would fail the 'route' conversion (after inter-digit timeout) and pass into the 'system' number_conversions where I could pick up the calls and send them to a recording.

Problems

It seems that a call only passes though the number_conversion tables once unless the 'cont' setting is used (along with numbertype=12) - even if there is an incoming conversion set against a route. When 'cont' is used, if a number is recognised it will follow the digit modifications and then re-present the call back into the table. However this has no value because in both the first and second check in the number_conversion table, if insufficient digits are dialled for an entry, the call will just timeout. I therefore have no means to pick up and route calls which have dialled insufficient digits (the old number). Unlike the 'conf' option in LC ENT there is no apparent way to take a call in two separate directions depending upon the number of digits dialled - where the smaller number is the same as the beginning of the larger number.

Unless there is a well disguised setting somewhere to get around one of the above resrictions, I suspect that I will need to use a combination of methods in order to resolve this - any help would be appreciated.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top