Call supervision time

[lpb612]

Hi guys!

I am not able to complete calls to a certain destination at PSTN. The carrier I use has asked to increase the call supervision time. Which PARNUM should I change? After the change, is the effect immediate or does it need to reset something?

Best regards.

 

[lpb612]

Who does send release signal? A or B party?

 

[snor]

???
more information would be helpfull.
TSW or TSE ? Version of the system
Analog-, ISDN- or SIP-trunk ?
ROCAP, RODAP, RODDP
.
Who does send release signal? --> a trace would show who release the connection.
best regards,
Norbert

 

[lpb612]

Thanks for reply.

Here the PBX:
[tt]
VERSION=LZY203511211-R1A/BC90G
<rocap:rou=42;
ROUTE CATEGORY DATA
ROU SEL TRM SERV NODG DIST DISL TRAF SIG BCAP
42 013000000000 5 2100000010 0 30 128 01151513 211000000050 001100

<rodap:rou=42;
ROUTE DATA
ROU TYPE VARC VARI VARO FILTER
42 TL30 H'00000000 H'0A140122 H'00000572 NO

<roddp:dest=142;
EXTERNAL DESTINATION ROUTE DATA
DEST DRN ROU CHO CUST ADC TRC SRT NUMACK PRE
140 42 000500000000025000 0 4 0
142 42 000500000000025000 0 4 0
149 12 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
150 30 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
151 31 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
152 32 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
153 33 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
154 34 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
155 35 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
156 36 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
157 37 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
158 38 000500000000025000 0 4 0
40 1 000500000000025000 0 4 0
42 4 000500000000025000 0 5 0
[/tt]

This route has a Least Cost Routing.

 

[lpb612]

Facts:
1) When I use the carrier A (code 21), the outgoing external call is disconnected (time expired).
2) When I use the carrier B (code 31), the outgoing external call is connected.

The attachment has the both traps.
[tt]
<aspaparnum=all;

APPLICATION SYSTEM PARAMETERS
PARNUM PARVAL
1 1
2 30
3 30
4 30
5 30
6 120
7 120
8 1
9 60
10 30
11 30
12 30
13 30
14 60
15 60
16 4500
17 150
18 80
19 6
20 3
21 5
22 3
23 4
24 7
25 2
26 1
27 7200
28 1800
29 16
30 1
31 1800
32 1
33 1
34 1
35 0
36 1
37 30
38 120
39 60
40 120
41 180
42 60
43 1
44 1
45 90
46 1
47 120
48 120
49 4
50 120
51 60
52 0
53 0
54 0
55 6
56 15
57 0
61 90
62 0
63 0
64 0
66 1
67 0
68 1
69 1
70 60
71 10
72 60
73 3
74 0
75 1
76 0
77 1
78 1
79 1
80 2
81 1
82 1
83 1
84 1
85 0
86 0
87 0
88 0
89 600
90 8
91 30
92 122
93 0
94 120
95 0
96 0
97 0
98 1
99 1
101 1
102 0
103 0
104 1
105 1
106 0
107 8
108 600
109 8
111 1
114 0
115 0
116 0
120 1
121 2
122 6
123 0
124 8
125 7200
126 7260
127 7200
128 7260
129 1
130 0
131 0
132 6
133 5
134 1
135 1
137 1
138 5
139 0
140 0
141 0
142 0
143 0
145 0
146 0
147 0
150 0
153 5
154 2
161 0
162 0
165 20
168 30
169 10
170 0
171 5
175 0
176 0
177 0
179 1
180 0
181 6
182 4
183 1
184 1
185 999
186 0
187 0
188 45
189 0
190 0
200 0
201 1
202 2000
203 400
204 21
205 1
206 0
207 0
208 0
209 12
210 0

END
[/tt]

 

[himdp]

When 0212121016234 is dialed, there is no acknowledgement from the central exchange to the sending of the last digit (4). The inter-digit timeout in TLP30 times out (15 seconds)and the call releases. This timeout is inside TLP30 and is not set by ASPAC as far as I can see.

I believe that even if you extend it, it will still time out because of an issue in the public network.

You should re-address this issue with your carrier.

Hope this helps

 

[lpb612]

Thanks a lot for reply himdp!

If you don´t mind, could you tell me how do you figure out the inter-digit timeout in TLP30 times out (15 seconds)? And how can I understand the trace´s signals? Are they in ALEX?
How can I perceive the numbers dialed?

Thanks again.

 

[himdp]

They are not in Alex, they are in Plexview which was only made available to level 3 support organisations (Field Support Centres) but was later restricted even more to Ericsson/Aastra and Wipro.

If you look at the trace of the failed case, line 298 shows the MFC signal SENBEG for the last digit (4) this should be answered by a RECBEG. See lines 295 and 296 in the working case.

Since the sent signal in line 298 is not acknowledged, the timer expires in TLP30 resulting in the CLEAR signal at line 300.

The time difference between line 298 and line 300 is 14.22.17.340 to 14.22.32.300 which is approx 15 seconds.

I hope this helps.

 

[lpb612]

How great!

You help me a lot. Thank you so much. Actually, I think you are master Jedi in MD110.

 

[himdp]

Thanks, I am about as old as Yoda

 

[fcpli]

himdp:
Just look at the trace. He is sending 3 times 21 - is it OK? But in any case, A3 or A5 or whatever back from the SP is missing, so this is definitely the PSTN issue (or maybe the digits are just accepted by the PSTN before it understands that this kind of numbering scheme/length is not possible? no idea, but loks a little bit strange to me).

Yoda2

 

[himdp]

Hi, fcpli,
I must admit that I scanned through to the point where the call failed. I use Notepad++ with a split window and lock vertical scrolling and scroll through to find the variation between the good and bad call cases. Looking back more closely after your question however, I can see no problem with the digits sent. It is confusing that 21 appears three times in the number (check in SENALLNUM it is 0212121016234) is this the case, or am I missing something?

I must say that I have had more than my fair share of analyzing MFC traces and I am not a fan The last problem I had was a very intermittent failure at call set up through a private AXE10 (On old software of course) the result was that it was an AXE hardware issue where the MFC code receiver seemed to have a nervous breakdown for no apparent reason. The issue was finally admitted by the AXE support guy but true to form it was my problem until I conclusively proved it to be his. I don't know the outcome as the customer was not too keen to upgrade (forklift) the AXE and Cisco were hovering like vultures ready to pick over the bones. I left before the decision was made.

The fault in this case was very similar to the case I had where the failure showed as a lack of responding RECBEG to a SENBEG the difference in this case is that it is reliably reproducible according to carrier selection so is not the same.
BR himdp

 

[lpb612]

Yoda1 (himdp) and Yoda2 (fcpli),
The numbers are correct. It's just a coincidence.
The first 21 is the code of the carrier, the second is the area code and the third is part of the PBX main prefix (2101).

Again, thanks a lot!
Dreaming of being a padawan.