Can't Call Certain Exchange from PRI 1

[RocketJTech]

Good Morning. I don't have a lot of experience interpreting Monitor Traces and would welcome your input on the following.

Situation: Release 11.0 Preferred Edition (VMPro) system with a single PRI. All outgoing calls have worked fine for several years. However, it was recently discovered that at least 2 exchanges (563-655-xxxx, and 319-499-xxxx) cannot be called from any of several phones (using several ARS tables). I believe that these are fairly new exchanges, and I suspect a routing issue with the PRI provider. The attached Monitor trace file had all tabs cleared except the ISDN tab, which had all options enabled. approximately 10 consecutive calls were attempted from outgoing caller ID (563-659-0735) to phone number (563-655-2131). The call does not go through and the caller hears a fast busy. The PRI provider claims that they are not seeing calls hit their switch. When I ran an SSA trace on the caller's extension, I was seeing cause codes 100, 43, then 4 consecutively. Is there anything in this trace that should give me clues on what is going on?



Thank you for your time.

Sometimes, I feel like a kindergartner missing out on recess, because certain kids won't shut up and get in line.

 

[critchey]

The PRI provider claims that they are not seeing calls hit their switch.

You can clearly see that is a lie in your trace (RX means this was recieved from the provider):

997269880mS ISDNL1Rx: v=9 peb=9
0000 02 01 92 70 08 02 06 cd 05 04 03 90 90 a2 18 03 ...p............
0010 a1 83 81 1c 16 9f 8b 01 00 a1 10 02 02 4e cc 06 .............N..
0020 07 2a 86 48 ce 15 00 04 0a 01 00 1e 02 84 83 6c .*.H...........l
0030 0c 21 83 35 36 33 32 32 31 32 30 30 37 70 08 c1 .!.5632212007p..
0040 36 35 39 30 37 35 30 6590750
997269880mS ISDNL2Rx: v=9 peb=9
0000 02 01 92 70 08 02 06 cd 05 04 03 90 90 a2 18 03 ...p............
0010 a1 83 81 1c 16 9f 8b 01 00 a1 10 02 02 4e cc 06 .............N..
0020 07 2a 86 48 ce 15 00 04 0a 01 00 1e 02 84 83 6c .*.H...........l
0030 0c 21 83 35 36 33 32 32 31 32 30 30 37 70 08 c1 .!.5632212007p..
0040 36 35 39 30 37 35 30 6590750

997297810mS ISDNL1Rx: v=9 peb=9
0000 02 01 9c 76 08 02 06 ce 05 04 03 90 90 a2 18 03 ...v............
0010 a1 83 82 1c 16 9f 8b 01 00 a1 10 02 02 4e cd 06 .............N..
0020 07 2a 86 48 ce 15 00 04 0a 01 00 6c 0c 21 81 35 .*.H.......l.!.5
0030 36 33 36 35 39 34 34 33 38 6c 0c 21 83 35 36 33 636594438l.!.563
0040 36 35 39 34 32 30 30 70 08 c1 36 35 39 30 37 31 6594200p..659071
0050 34 4
997297810mS ISDNL2Rx: v=9 peb=9
0000 02 01 9c 76 08 02 06 ce 05 04 03 90 90 a2 18 03 ...v............
0010 a1 83 82 1c 16 9f 8b 01 00 a1 10 02 02 4e cd 06 .............N..
0020 07 2a 86 48 ce 15 00 04 0a 01 00 6c 0c 21 81 35 .*.H.......l.!.5
0030 36 33 36 35 39 34 34 33 38 6c 0c 21 83 35 36 33 636594438l.!.563
0040 36 35 39 34 32 30 30 70 08 c1 36 35 39 30 37 31 6594200p..659071
0050 34 4 4

Them acting like they NEVER get it is simply not true. There are some instances when you TX and get no matching RX but to say they never receive anything is a lie clearly.



The truth is just an excuse for lack of imagination.

 

[RocketJTech]

That is what I thought… I also ran a trace in SSA… (on the extension from which I was dialing)… i received consecutive cause codes 100, 43 and 4.

Thank you for your input

Sometimes, I feel like a kindergartner missing out on recess, because certain kids won't shut up and get in line.

 

[IPGuru]

Cause No. 100 - Invalid information element contents.
This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment sending this cause.
What it means:
Like cause 1 and cause 88, this usually indicates that the ISDN number being dialed is in a format that is not understood by the equipment processing the call. SPIDs will sometimes fail to initialize with a Cause 100, or a call will fail with this cause.

Cause No. 43 - access information discarded.
This cause indicates that the network could not deliver access information to the remote user as requested. i.e., user-to-user information, low layer compatibility, high layer compatibility or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic.

Cause No. 4 - send special information tone.
This cause indicates that the called party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party.

As critchly stated they are clearly getting something or they would not be returning a cause code
assuming there is no special routing for different numbers on the IPO & everything gets routed via the same short code then this is a line provider issue


Do things on the cheap & it will cost you dear

Avaya Remote Support Engineer (A.R.S.E)