Can't dial out from analog extensions

[MattRutter]

Hi all.

Here's a wierd one..........

Customer has the following kit:

IP406 2.1(15)
DCPx30 4.1(15)
DCPx16 4.1(15)
Pots8 4.1(15)

The extensions on the pots8 get dial tone ok, can dial internally, but cannot dial out - get NU.

Assume the pots8 is faulty, but not having a spare one, I added a pots30 as a temporary fix. Moved the extensions from the pots8 onto the first 8 ports of the pots 30. And have the same problem; NU when dialling external numbers!

Put a phone into one of the old ports on the pot8, and lo - i can dial out!

So, with the customer unwilling to suffer another re-boot, i change the incoming call route to point at the new extension on the original port (on the pot8) - cant dial out!

But the old extension on the new (pot30) port now can!

So basically, any analog port i point an incoming call route to cannot dial out!!!

I got round the problem by pointing the incoming calls at a spare ext. then forwarding the call to the correct one.

But what is going on here? do i need to default the switch?

Matt

 

[revco696]

What kind of external PSTN connection do you have? I'm thinking if it's a PRI, you might need to send the carrier a full 7/10 digits by using the "Nsxxxxxxxxxx" short code for it to work. Have you done a monitor trace with call/T1 options selected to see what might be going on? Are you using a different short code for the analog extensions vs. digital extensions? Does this happen on digital extensions at all?

 

[intrigrant]

It looks to me that the POTs were a incoming call route is pointing to are dialling out with a illegal CLI number, the network operator then disconnects the call.
You could try a usershortcode on such a POT like this :
Shortcode = 0 (or 9)N
Number = NW
Linegroup = 0 (or the group as needed)
Function = dial
If you don't use a digit for external line access then you have a shortcode like this:
SC = ?
Teleph.nmbr = .
linegr = 0
Funct. = dial
Add a W after the . in the Teleph.nmbr field.

The W after the dialled number suppresses any CLI information towards the network operator.
If now the POTs can dial-out you know the problem.
POTs without a incoming call route will never send any CLI information towards the network operator.

But of course, i could be wrong but it's worth trying

 

[Telecomboy]

I ran into this issue once before. It is happening because of the incomming call route. The provider is looking for additional information as revco696 stated. If your incoming call route is 4-digits, it is probably sending out 4-digits when making an outside call and the provider is denying it because they don't recognize the origine of the call. Try using the "Nsxxxxxxxxxx" short code mentioned above (x's representing their main number). This will send the provider their main number so they recognize where the call is coming from. That is what did the trick for me.

 

[Morrack]

Agree with above, and for good measure, stop using 2.1.15!! Either downgrade to 2.0.18 or upgrade to 2.1.248901

Peter

 

[intrigrant]

Better use the 2.1(27) software, is pretty good actually.

 

[IPGuru]

V2.1(27) is still on field trial so I havent had time to check it out yet.

any feed back you could give this forum would be greatly apreciated.

 

[Morrack]

Yeah, I'm with IPGuru, if you have info spill it intrigant!

Peter

 

[MattRutter]

Thanks all.

This has cured the problem. The only mystery now is, why did it suddenly stop working, and why are the DS phones unaffected?

Matt