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

Denial Event 1164

Status
Not open for further replies.

G3SIMaint

Technical User
Oct 28, 2005
10
US
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
 
Note that the service feature is sdn. The 1164 error is common on a sdn network if you dont set up your route to handle this feature.


Pattern Number: 4 Pattern Name: LONG DISTANCE
SCCAN? n Secure SIP? n
Grp FRL NPA Pfx Hop Toll No. Inserted DCS/ IXC
No Mrk Lmt List Del Digits QSIG
Dgts Intw
1: 13 4 303 0 n user
2: 9 4 303 1 n user
3: 1 4 303 1 n user
4: n user
5: n user
6: n user

BCC VALUE TSC CA-TSC ITC BCIE Service/Feature BAND No. Numbering LAR
0 1 2 3 4 W Request Dgts Format
Subaddress
1: y y y y y n n rest sdn none
2: y y y y y n n rest none
3: y y y y y n n rest none
4: y y y y y n n rest none
5: y y y y y n n rest none
6: y y y y y n n rest none
 
PS if this dont work send a copy of your route pattern. If this is a sdn feature you may need to set your prefix mark to 0 to suppress the 1 going out because sdn likes the 10 digits only
 
your comment ILEC implies that you are using someone other than AT&T, MCI or one of the Bells.

usually an ISDN cause code of 1164 means that your ILEC is not keeping up with the ITU-T e.164 or the North America Numbering Plan Administration changes.

The other possibility is that the far end does not like what you have setup in the DS1 form for the T1 where your DCP/analog Bearer Capability being set as 3.1kHz or speech. This situation is rare, so I am more inclined to believe that its the ILEC.

Also in your trace your dialed digits are
16:16:56 dial 9913145384571
but your setup digits are
16:16:56 Setup digits 1 314 538 4571

Is your ARS FAC 99 ? If so, that is interesting.

 
g3rguy,

I made the changes in my routing table and had no luck making the call.

The reason you see "99" is due to a directive from my organization.

I just got off the phone with my carrier. They 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
 
changes to codeset XX is on page 1 of the trunk group and it is about 2/3 of the way down on the left. typically in the US, we do codeset 6 (sometime 7) so without understanding what you have it is hard to tell you, but trying codeset 6 (more common) might help. I don't know what codeset5 does ???

the other thing that i notice in those traces that you need to check is
ISDN: Info Trans Cap = 3.1 KHz Audio
and my comment regarding it ...
The other possibility is that the far end does not like what you have setup in the DS1 form for the T1 where your DCP/analog Bearer Capability being set as 3.1kHz or speech.
You should set that for 3.1kHz



 
Wleong,

I verified that all my setting are the same as you mentioned... Still no luck as of right now. Still looking!!
 
I noticed you're not sending name and number. The far end may block calls where there is no name/number?
 
I tried that as well. The Carrier thought it was a CPN trouble too. He inserted a alias CPN and this still didnt help.
 
on our trace, i see invalid codset5 ...
have you tried codset6 ?
that change is located in on page 1 of the trunk group and it is about 2/3 of the way down on the left. typically in the US, we do codeset 6 (sometime 7)

 
Yes... Mine is set for Codeset 6 . I have changed it to seven as well. Still no change.

Im not sure where the codeset 5 comes into play. Codeset 5 isn't a selectable option.

 
Here is some info regarding Codeset 5, which appears to be National Specific. Possibly this is related to SDN or other endpoint specific protocol.



The message (0x95) appears in the second link as a Custom Lucent/Avaya "transfer reject" I remember an issue related to a Nortel Customer Switch that was rejecting 3.1khz calls to a tandem switch on its network because of an older card in the second switch that its firmware did not support that type of call???
Just for grins, set an ARS exact pattern match (11 digit) to one of the failing numbers and set the call-type to Natl instead of FNPA and see if that makes a difference

Here is a Cisco link also discussing codeset 5.
 
Thanks for your input... I'll try it Monday morning.. I'll keep you posted.

Greg
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top