G3SIMAINT

Hello,

I have been recently been getting a Denial event 1164 on one of my LD Trunks when i place a outbound call. This happens when dialing 4 specific numbers that are routed to this TG. This TG is for my LD traffic. All other call over this TG are completed with no problems. This trunk group has been up and running for a couple of years with no issues. I have included the trace info in hopes that someone can shed some light on this??? Is it my PBX or is my ILEC causing this??

My PBX is a G3SI running RLS 11.1.3

16:16:56 dial 9913145384571

16:16:56 route-pattern 2 preference 1 cid 0x254

16:16:56 seize trunk-group 4 member 22 cid 0x254

16:16:56 Setup digits 13145384571

16:16:56 Calling Number & Name NO-CPNumber NO-CPName

16:16:57 Proceed trunk-group 4 member 22 cid 0x254

16:16:58 denial event 1164: ISDN call reject D2=CV D1=0xcc D2=0xf29

16:16:58 idle trunk-group 4 member 22 cid 0x254

16:17:07 idle station 5419 cid 0x254



Any help on this will be greatly apreciated,

Respectfully,

Greg Reynolds

technician101

Per Maint docs,

Denial Event 1164

ISDN no cause value
Outgoing ISDN trunk rejected/ dropped by far end

It would appear to be a carier issue, check with your service provider to make sure they are allowing you to call the 314 area code.

PBXtech.info

 

martinyoung

Just in case you don't see my other message, I will repeat it here. The other answer posted here explained the denial event and a possible cause. The event data 2 entry of "0xf29" is the actual problem. The (f) shows where it happened and the (29) shows what happened.

0xf29 is a hex number that must be converted to decimal to find out what is going on. In Avaya document 03-300430 on page 130 is the location code table. Location code A to F mean the problem is at the far end of the circuit, the carrier equivalent of a blue alarm.

The hex value of 29 converts to a decimal value of 41 and this is mentioned in the cause code table on page 149. It is supposedly a temporary failure but since you can never call those four numbers, it is not temporary. The problem is at the far end, it is not you.

It is unlikely that one channel on a T1 will go bad unless the vendor has done something.

Possibilities are, unable to call that area code, area codes have split and those numbers are now in a different area code, the company you are calling has a problem on some numbers and they are unaware of it, the numbers you are calling are no longer in service, your vendor has a problem, etc.

Get with the vendor, the problem is in their ballpark or beyond.

One thing that might bring it closer to home is I notice you have to dial "99" to get out, this usually means Centrex. Check with your provider to make sure nothing has changed there, they might be inserting or deleting something to make it fail at the far end.

This is a longer answer than my other one because I have had a chance to sleep on it.

__________________
Marty
Retired Avaya DSIC tech

G3SIMAINT

Thanks Marty...
It's always been difficuit to figure out Denial messages.

The reason you see "99" is due to a directive from my organization. I'm definetely dealling with a PRI.

I just got off the phone with my carrier. They also thought the trouble to be on the distant end. They had me do a few test calls and watched the D-channel messages on there packet analyzer and determined that the distant end was not excepting Codeset 5 IE messages and rejecting the call.

The tester recommended either i turn off the Codset 5 messages or have the distant end allow them. Currently, i havent contacted the distant end To talk with them in hopes i could tweak my end.

Can this be done on a G3SI running CM 1.1.3

I have included the D-channel messages the Carrier has sent me.



------------ ISDN Header ------------
ISDN: Q.931: ATT&5ESS
ISDN: Protocol Discriminator = 0x08 (Q.931 Call Control)
ISDN: Call Reference Length = 2
ISDN: Call Reference Flag = 0 (FROM side that originated call ref)
ISDN: Call Reference Value = 0x1D9C
ISDN: Message Type = SETUP (0x05)
ISDN: Information Element = Bearer Capability (0x04)
ISDN: Information Element Length = 3
ISDN: Coding Std = CCITT
ISDN: Info Trans Cap = 3.1 KHz Audio
ISDN: Transfer Mode = Circuit
ISDN: Transfer Rate = 64 Kbit/s
ISDN: Layer Id = Layer 1
ISDN: Proto Id = G.711 u-law Speech
ISDN: Information Element = Channel Identification (0x18)
ISDN: Information Element Length = 3
ISDN: Interface Id Present = Implicit
ISDN: Interface Type = Primary
ISDN: Channel = Exclusive
ISDN: D-channel = No
ISDN: Info Chan Selection = As Indic
ISDN: Coding Std = CCITT
ISDN: Number/Map = Number
ISDN: Channel Type = B-channel units
ISDN: Channel Number = 1
ISDN: Information Element = Network Specific Facil (0x20)
ISDN: Information Element Length = 2
ISDN: Network Id Length = 0
ISDN: Parametrized/Binary = Binary
ISDN: Expansion = Value In Next 6 Bits
ISDN: Feature/Service = Service
ISDN: Bin Facil = Virtual Priv Net
ISDN: Information Element = Called Party Number (0x70)
ISDN: Information Element Length = 11
ISDN: Number Type = National
ISDN: Number Plan = Private
ISDN: Number Digits = 3 1 4 5 3 8 4 5 0 0
ISDN: Information Element = Shift (0x95)
ISDN: Shift Type = Locking
ISDN: Codeset = 5
ISDN: Invalid Codeset 5



Thanks again for all your help,

Greg

martinyoung

This one I have had to dig for and I am not sure I have found everything yet. Here is what I have so far. The only valid codeset I have found in the documentation for a Definity, so far, is 6. And the only place I have found to set it is in the middle of the first page of the ISDN trunk group, there are two fields for this. I have looked in my R9.2 G3r and an R11 G3r that I have access to. It defaults as a 6 when you create the trunk group.

I would be cautious about making any changes at your end. You indicate that all other long distance traffic completes successfully, if you modify your end you might break everything else. Remember that successful calls also use the same D channel. Any change you make will affect all calls.

I would be curious what your vendor would see in a trace of a good call.

Just for grins, what happens if you send these four numbers out of the non long distance T1s?

I will keep looking.

__________________
Marty
Retired Avaya DSIC tech

G3SIMAINT

I agree you thought in regards to changing codesets... If you can change it at all... I can route all the problem numbers successfully though another PRI that i use for local traffic. I'll take your advice and do few more test calls and get my carrier to watch the messaging.

Those codeset's you mention that are in the middle of page one of the TG screen. I have modified them with no luck. On the National IE codeset, You can only select 6 or 7. I've done both with no change.

Greg

PBXtech.info

 

martinyoung

According to the Avaya documentation, the only time you use codeset 7 is if you have a System 85. I wonder how many of those are still out there?

I can remember when I thought a System 85 was easy to work on, but that was comparing it to a Dimension 2000 :)

I have not found anything that tells me this codeset 5 is coming from the Definity and since it is at the end of the trace, I am inclined to believe the network is inserting it (or asking for it) somewhere else.

An interesting test would be to try calling some other number in the area code you are having a problem with while your vendor is tracing the calls.

Other questions I did not ask previously -

Are these four numbers all in the same PBX at the far end? If so, what is it?

Were calls to these numbers working before and just began having a problem? If so, and the answer to the above question is yes, what changed in the receving machine?

If calls to other numbers in that area code terminate successfully, but your four numbers do not (and they are in the same PBX), it is not likely to be a CO problem. Especially since you can get there using your local T1s.

__________________
Marty
Retired Avaya DSIC tech

G3SIMAINT

I want to thank all of you for your input. I'm still tring to clean up this issue. I post the out come of this problem..

Thanks again,

Greg