Can't Dial Internationaly after PRI carrier switch 4

[ame540]

Hi!

We are having a problem with our IPO 406 (4.2),or our phone company that is driving me up the wall! We recently switched our PRI's (we have two) from AT&T to TelePacific. After the move we can no longer dial internationally.

The phone company has assured me that we are not being blocked from making international calls and that both PRI's should be able to dial outside the company.

Currently our IPO is setup to use ARS codes and we dial 7 to reach an outside line. The reason why we are using ARS is that it was the only way i could figure out how to get local calls to connect without dialing the area code too. The code that I have setup for international calls is as follows:

ARS Shortcode [7]
Code: 0N;
Feature: Dial 3K1
Telephone Number: 0N
Line Group ID: 0
Locale:
Force Account Code: unchecked

What happens when an international number is called (specifcally one in Italy we need to reach) is that the number shows up in my Call Status window with a status of Dial, but it just sits there. On my phone i see all the digits, but its like the call is not even attempting to be made. I don't get any error tones or messages. It just sits there in limbo.

I have been working with a 3rd party Avaya tech to get some support on this. We pulled some Monitor logs as i made a test call and he says that it is selecting a PRI channel to try and make the call, but im not really convinced!

I have no idea how to get the system to dial the digits necessary to call international. If anyone has any ideas please shoot them my way! Thank you.

 

[CarGoSki]

Well OK but ITU does not actually define a cause code 8.

If you look at the IPO cause codes you posted vs the Cisco cause codes I posted you will see that they are the same only Avaya uses a different number scheme.

IE IPO

1 Unallocated Number.
2 No route to specific transit network / (5ESS) Calling party off hold.
3 No route to destination. / (5ESS) Calling party dropped while on hold.

ETC



IE Cisco

80 Normal Disconnect
The call disconnects normally.

81 Unallocated or unassigned number
The switch receives the ISDN number in the correct format. However, the number does not belong to destination equipment.

82 No route to specified network
The ISDN exchange receives a request to route the call through an unrecognized intermediate network.

This cause indicates that the equipment receives a request to route the call through a particular transit network. However, the equipment does not recognize the network.

The equipment that sends this cause does not recognize the transit network due to one of these reasons:

The transit network does not exist.

The transit network exists, but does not serve the equipment that sends this cause.

This cause is supported on a network-dependent basis

ETC







IE ITU Q.931 page 298

1 000 0001 Unassigned (unallocated) number
2 000 0010 No route to specified
3 000 0011 No route to destination
6 000 0110 Channel unacceptable
7 000 0111 Call awarded and being delivered in an established channel
16 001 0000 Normal call clearing


ETC






So I believe you have to look at the most significant byte in the information element which is 88 and not 8

575386919mS ISDNL3Rx: v=2 peb=2
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0054(Local)
Message Type = ReleaseComplete
InformationElement = CAUSE
0000 08 02 c0 88

It's people like you who generalize.

 

[tlpeter]

But still no answer on the [7] !!!
It is really terrible with anwering questions lately!

You ask a question and we respond.
It is not very nice when those answers are ignored !

So do you use [7] as a shortcode somewhere in the system ?
Using [] is not supported anymore from 4.0 and higher.
It is removed out of the software so it can cause bog problems if you use the []'s




ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[kflounders]

We had a similar issue and resolved it with two things:

First we saw that the calls were being tagged as national so in the no user source numbers we put it

NI2_CALLED_PARTY_TYPE=UNKNOWN

Then we noticed that the provider needed to see an outbound caller ID from our system that was an active DID on the T-1 so Our schortcode was this:

9011N,
Dial 3K1
011Ns6106924000 - Notice no "i"after the s
PRI ID

 

[amriddle01]

Hence my first response about finding out from the providor what they need, I remebered you posting that before but couldn't remember the specifics

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[hairlessupportmonkey]

i also think people should harden up and try a few variations and experiment a bit! also, get onto your telco and kick some ass, as they are the ones who should be offering some support and do some traces their end - just ask - who are you paying the bills to? tek-tips forums or the telco?

 

[mattKnight]

Confused now

88 Hex = 136 Dec = 1000 1000

bits 7 6 5 are class = 0 0 0 = Normal Event

Bits 4 3 2 1 are Value = 1 0 0 0 = 8 = premeption



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[ame540]

Here's some follow up:

1) I have removed the [ ] from the ARS short code, it is just plain old 7 without brackets.

2) I have tried "Dial" as opposed to "Dial 3k1" and it had no effect. Just for giggles I tried the 0N code with Dial Speech too. No such luck there.

3) I have a ticket open with my Telco (which is at Tier 3 review right now) since both myself AND my Avaya consultant believe that its not a config issue but rather we are probably not setup correctly on the phone company's end. He was able to work with Avaya directly and they have confirmed that our config looks good and there is probably a disconnect on TPAC's end.

So no, i don't look to just Tek-Tips for solutions, i work multiple angles to try to get input from various resources. Its just too bad that TPAC seems to be reluctant to get off their asses and really look into our problem. To be honest i am very disappointed with their provisioning and turn-up departments. They are more worried about selling service and "turning it up" than actually supporting it and make sure their customers are happy. [/rant]

 

[tlpeter]

So you have a system shortcode:

7N
dial
N
line id ARS

And an ARS shortcode:

N
dial
N line id trunk





ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[amriddle01]

Don't forget the ;

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[tlpeter]

It is a guide or a how to




ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[ame540]

tlpeter,

Yes we have both of those. Is there some kind of a problem with the way the international number comes through the 7N; short code and then is passed to the

N
dial
N line id trunk

 

[tlpeter]

When you dial 7 and you wait then you should get secondary dialtone (if checked in ARS)
Then you should dial the rest of the number.

But when you dial 7 and the rest of the number it jsut will send it to ARS too.
Can you try both methods ?




ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[ame540]

tlpeter,

Tried both methods (yes ARS is setup to give a Secondary dialtone), it didn't seem to make a difference. If i check the CallStatus in IPO, the extension sits in a "Dial" status with the digits 07739422433011 sitting there doing nothing.

If dial the 7 and all the digits immediately after, or hit 7 and wait for the seconday dial tone, it does not seem to make a difference.

I have a feeling that i just don't have something setup right in ARS to get the IPO to actually DIAL the number.

The codes i have in there right now are (They are all Line group ID:0)

Code: 911 Number: 911 Feature: Dial Emergency
Code: 1N; Number: 1N Feature: Dial 3K1
Code: xxxxxxxxxx Number: N Feature: Dial 3K1
Code: xxxxxxx; Number 949N Feature: Dial
Code: N; Number: N Feature: Dial
Code: 0N; Number: N Feature: Dial

Are some of my codes conflicting with each other? There is only one that is set to handle digits that start with zero (0).

 

[CarGoSki]

don't know matt. I'm still trying to digest the ITU doc. You are probably right.

It's people like you who generalize.

 

[kflounders]

Did you try my fix? That was the same exact issue.

 

[ame540]

kflounders,

I wasn't sure where to find this part of your solution:

First we saw that the calls were being tagged as national so in the no user source numbers we put it
NI2_CALLED_PARTY_TYPE=UNKNOWN

The real kicker is that my Avaya guy i've been working with has a client with an identical setup on their IPO on TelePacific lines in a different city that could call the number in question. He had a monitor running and saw that the logs were presenting the call in the exact same way as our, but they could get through.

I have convinced TPAC to dispatch a technician to our location, plug into our PRI and make some test calls. I am going to be VERY interested to see how this goes. I have a feeling that our last mile provider, or TelePacific themselves has something misconfigured on their end.

 

[amriddle01]

ame540, you do have it set up right as we can see from the trace what you are sendng and it is what you would need to send, if somethings wrong it's more than likely the line or because they haven't informed you of what they require

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[Telecomboy]

As KFlounders stated, You may need to add the NI2_ etc under the source number tab of No User. In Manager, go to Users, find No User, go to the Source Number tab, and add the NI2_ line that KFlounders put above. This tags the calls as unknown instead of National which some providers need.

 

[ame540]

Thanks for letting me know where to add the Source Number information for No User. Unfortunately even with the NI2_CALLED_PARTY_TYPE=UNKNOWN in there and also appending the extra information after the "s" in my 011N code, it did not make any difference when the international call was attempted.

On another note, the TelePacific techs came by today and unplugged each PRI from the IPO. Using a test set, they were able to make international calls on both circuits. I am at a total loss, working with Avaya i had a lot of confidence in knowing that the setup in our phone system was correct for making these calls (heck, this is how it was working previously with our old carrier Paetech Communications) so i am really stumped.

I took a snapshot of the config, and exported another log file to give to my Avaya tech to shoot over to Avaya support directly. Thanks for all the suggestions guys...

One thing still is really bugging me. I can't get over the fact that IPO is reporting that "Prefix 0 dialed in error" message:

677941064mS CMLineRx: v=1
CMReleaseComp
Line: type=Q931Line 1 Call: lid=0 id=36104 in=0
BChan: slot=0 chan=23
Cause=8, Preemption/(NI-2)Prefix 0 dialed in error

 

[hairlessupportmonkey]

have you flattened the switch and used a vanilla build to test with? perhaps the config is a bit screwed.

obviously back it up first.

factory it and try that.