No external call for extension 1

[gilekele]

Hi,

I have an unusual problem with one of my extensions. All other extensions are able to dial outside numbers but not this particular one, instead you get a message...the number you have dialed is not in service.

My diagnosis is as follows.
-able to call/receive other extensions,
-able to receive outside calls,
-changed to different LEN but problem persists,
-same restriction code with working extensions,
-all stations in same tenant,
-changed handset without effect.

I suspect this could be related to LCR? I'm stoned!

We use ips2000 and NEC analogue handsets. Any help would be greatly appreciated.

G!le.

 

[belevedere]

When you changed the LEN did you delete the station or use a station swap command? By deleting then re-programming the station the system defaults are set up. Try that without any restriction classes assigned. It sounds like a per-set digit is being sent out.

 

[OzzieGeorge]

The message is a network generated message so you are getting out, I know this may sound unusual but have you tried changing the outgoing CLI in Cmd 1212. I have had restriction problems in the past because the carrier was rejecting the number as it didn't consider that number to have an account with them!

 

[gilekele]

oops. I owe you an apology. I got myself mixed up with an older fault which had been resolved .

This extension however does make outside calls and receives internal calls. But it does not receive outside calls except thru the operator. Same restriction pattern and tenant as the working extensions. There is always a busy sound when calling in from outside. Any pointers on what to check? Changing of LEN had no effect.

Many thanks.

G!le.

 

[OzzieGeorge]

Check Command 76XX for possible translations, or lack of!

 

[belevedere]

If you are using DID's, does the DID number match the extension number? If not, then Follow Ozzie's suggestion and look for DID conversions. CMD 7600>DID#> to find a table number, then CMD's 7601>table #> for day and 7602 for night mode to find the translation.

 

[OzzieGeorge]

Even if they do match, check 76XX as the number in question may be re routed for a reason (sometimes for such things as a night mailbox) they fall into disuse for one reason or another, then when you try to recycle the number, you hit a problem like this!

The other possibility is split call forwarding in Cmd E6XX

 

[gilekele]

Ok. Here's what I have. Our DID is 4 digits as in 3280xxx


7600>328:000
7600>329:none
7600>330:none

7601>000:444-
7602:000:444-

So the block number is 000 , translation is 444. Where do I go from here?
The problem ext I have is 216.

In regard to split call forwarding there is no data(none) for E604 and E605 and the rest of the E6y cmds.

Thanks.

G!le.

 

[belevedere]

DID translation tables convert the last 3 or 4 digits. Your post is showing the first 3 digits. In your post it would indicate that 380 is being converted to 444. Change 444 to 216 in 7601/7602 and test it.

 

[OzzieGeorge]

Woah there!

We don't know what the conversion table is for the incoming digits 216! What do you get for Cmd 7600 de 216 de it should read none if that is the number people dial from the outside, to get ext 216 however if for example they dial XXXX316 you would check Cmd 7600 de 316 de and that should read 216.

I doubt people dial XXX444 to get ext 216 (but I could always be wrong)!

 

[belevedere]

Instead of messing with DID conversion table, try CMD's 1212 and 1213. Match them to a known good working station. It will send out the same CID as a working station just for testing purposes.
Or, just delete any data in 1212 for that station and set 1213 to a table with the main CID number (10 digits).

 

[gilekele]

Thanks OzzieGeorge that did the trick. Have a pleasant day.


G!le.