Help with CCS trace

[petr.necas]

We have a customer with two PRI lines from the same provider (old and new), calling out work fine on both lines but calling in on the new PRI line does not.

This is CCS trace from the old functional trunk where incoming call is correctly answered on an extension 206:

11:42:55 RI113 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*dIBc#*58*CI*W6a#     
11:42:55 RI113 DPN 1B SSRM_C  *50*420225296411#491939170                       
11:42:56 RO113 DPN 18 NSIM    ;1C;*100*Administration*1#                       
11:42:56 RO113 DPN 1C NAM     *1#*50*206#*58*CD*0#*166*6#                       
11:42:59 RO113 DPN 1  CCM                                                       
11:43:09 RO113 DPN 2  CRM/CIM ;30;                                             
11:43:09 RI113 DPN 2  CRM/CIM ;30;     

When a second PRI line is used the incoming call does not get thru (what I understood from the CCS trace the ICP is not responding and the other site is re-sending the request until it times out):

11:45:12 RI214 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*dIBc#*58*CI*W6a#     
11:45:12 RI214 DPN 1B SSRM_C  *50*420225296411#491939170
11:45:12 RO214 DPN 2  CRM/CIM ;0;                                               
11:45:12 RI214 DPN 2  CRM/CIM ;0;                                               
11:45:15 RI215 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*dIBc#*58*CI*W6a#     
11:45:15 RI215 DPN 1B SSRM_C  *50*420225296411#491939170
11:45:15 RO215 DPN 2  CRM/CIM ;0;                                               
11:45:15 RI215 DPN 2  CRM/CIM ;0;                                               
11:45:19 RI201 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*dIBc#*58*CI*W6a#     
11:45:19 RI201 DPN 1B SSRM_C  *50*420225296411#491939170
11:45:19 RO201 DPN 2  CRM/CIM ;0;                                               
11:45:19 RI201 DPN 2  CRM/CIM ;0;                                               
11:45:22 RI202 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*dIBc#*58*CI*W6a#     
11:45:22 RI202 DPN 1B SSRM_C  *50*420225296411#491939170
11:45:22 RO202 DPN 2  CRM/CIM ;0;                                               
11:45:23 RI202 DPN 2  CRM/CIM ;0;                                               
11:45:26 RI203 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*dIBc#*58*CI*W6a#     
11:45:26 RI203 DPN 1B SSRM_C  *50*420225296411#491939170
11:45:26 RO203 DPN 2  CRM/CIM ;0;                                               
11:45:26 RI203 DPN 2  CRM/CIM ;0;                                               
11:45:30 RI204 DPN 2B ISRM_I  ;10;*3#*19*Z#*58*Ca*1*Z#*233*`IBc#*58*CI*W6a#     
11:45:30 RI204 DPN 1B SSRM_C  *50*420225296411#491939170
11:45:30 RO204 DPN 2  CRM/CIM ;0;                                               
11:45:30 RI204 DPN 2  CRM/CIM ;0;                                               

Both PRI lines are using the same physical port on a Dual Framer module. We just test one PRI line and when we connect the second PRI line to the same port on the ICP.

Any ideas why the ICP is not responding to the ISRM_I and SSRM_C requests?

[markyb73]

What is your trunk service (attributes) set to do against the trunks? Do you have something against absorb, at a minimum 0 ?

[johnp]

I would use edt trace tsp l2l3 X X X X it might show a little more

[petr.necas]

What is your trunk service (attributes) set to do against the trunks? Do you have something against absorb, at a minimum 0 ?

Yes, in Trunk Attributes the absorb value is set to 5 so the number 491939170 is changed to 9170. There is also a system speed call for 9170 to dial extension the 206.

[petr.necas]

I would use edt trace tsp l2l3 X X X X it might show a little more

I executed EDT TRACE TSP L2L3 7 1 2 1 and did a call but only this was on the output:

 HDLC CC on link 1 trace enable .

 HDLC VERBOSE on link 1 trace enable .

[lundah]

Make sure the 2nd circuit and the digital trunks on it are using all the same settings as the working circuit. The only thing that should be different are the PLIDs and the trunk numbers, which of course have to be unique. Check your Digital Link Descriptor, Circuit Descriptor, Trunk Attributes, Interconnect, everything.

[msouva]

Check the Trunk Attributes form.  The trunk service number that you are using you will want to check "Dial in Trunks Incoming Digit Modification - Absorb".  This should have a 0 if you are not absorbing.  The note says if it is left blank calls will fail.

[petr.necas]

Check the Trunk Attributes form.  The trunk service number that you are using you will want to check "Dial in Trunks Incoming Digit Modification - Absorb".  This should have a 0 if you are not absorbing.  The note says if it is left blank calls will fail.

in Trunk Attributes the absorb value is set to 5.

[petr.necas]

Make sure the 2nd circuit and the digital trunks on it are using all the same settings as the working circuit. The only thing that should be different are the PLIDs and the trunk numbers, which of course have to be unique. Check your Digital Link Descriptor, Circuit Descriptor, Trunk Attributes, Interconnect, everything.

The settings is for 100% same because we are reconnecting cable to the same port. There might be different setting on the Telecom site but but how can I explain them the problem when they are ignorants.

[acejavelin]

Make sure the 2nd circuit and the digital trunks on it are using all the same settings as the working circuit. The only thing that should be different are the PLIDs and the trunk numbers, which of course have to be unique. Check your Digital Link Descriptor, Circuit Descriptor, Trunk Attributes, Interconnect, everything.

The settings is for 100% same because we are reconnecting cable to the same port. There might be different setting on the Telecom site but but how can I explain them the problem when they are ignorants.

At this point you really need to do the "edt trace tsp l2l3 (PLID)" command and watch the actual information coming in from the telco... ccs trace is unusable for stuff like this

[petr.necas]

At this point you really need to do the "edt trace tsp l2l3 (PLID)" command and watch the actual information coming in from the telco... ccs trace is unusable for stuff like this

Unfortunately there was not any output of this command during the call :-(

[acejavelin]

At this point you really need to do the "edt trace tsp l2l3 (PLID)" command and watch the actual information coming in from the telco... ccs trace is unusable for stuff like this

Unfortunately there was not any output of this command during the call :-(

Interesting... No output at all? This should be the Q.931 messages for all calls on the PRI on that PLID.

You should see output like this:

EDIT TRACE TSP L2L3 4 1 2 1

 HDLC CC on link 3 trace enable .

 HDLC VERBOSE on link 3 trace enable .

2018-10-11  16:39:55  Link 3  - To Mitel   - HLen 4, ILen 62, IType 6
SAPI 0 TEI 0 C/R 1 P/F 0 NR 18 NS 20 INFO Orig PD=0x8 CR=0x026  SETUP(0x5)
1   00000100 Information Element: Bearer Capability:
2   IE Length                   : 3  octets
3   1------- Extension bit      : Not Continued
    -00----- Coding Standard    : CCITT
    ---00000 Info. trans. cap.  : Speech
4   1------- Extension bit      : Not Continued
    -00----- Transfer Mode      : Circuit Mode
    ---10000 Info. trans. rate  : 64 kbits/s
5   1------- Extension bit      : Not Continued
    -01----- Layer identifier   : 1
    ---00010 Layer 1 protocol   : Rec. G.711 u-law
1   00011000 Information Element: Channel Identification:
2   IE Length                   : 3 octets
3   1------- Extension bit      : Not Continued
    -0------ Interface ident.   : implicitly identified
    --1----- Interface type     : primary rate
    ---0---- Spare
    ----0--- Indicated channel  : preferred
    -----0-- D-channel indicator: not the D channel
    ------01 Info. chan. sel.   : as indicated in the following octets
3.2 1------- Extension bit      : Not Continued
    -00----- Coding Std         : CCITT Std
    ---0---- Channel indicated  : by following octets
    ----0011 Chan/Map type      : B-chan units
3.3 1------- Extension bit      : Not Continued - Single channel
    -0000001 Channel Number     : 1
1   00011100 Information Element: Facility:
2   IE Length                   : 25 octets
3   1------- Extension bit      : Not Continued
    -00----- spare 
    ---11111 Service discrim.   : Protocol Profile (Networking Extensions)
    0x8b, 0x1, 0x0, 0xa1, 0x13, 0x2, 0x1, 0x1, 0x2, 0x1,
    0x0, 0x80, 0xb, 0x53, 0x74, 0x65, 0x76, 0x65, 0x20, 0x53, 0x77, 0x69,
    0x73, 0x73,
1   01101100 Information Element: Calling Party Number:
2   IE Length                   : 5 octets
3   0------- Extension bit      : Continued
    -000---- Type of number     : unknown
    ----0000 Numbering plan     : unknown
3a  1------- Extension bit      : Not Continued
    -00----- Presentation       : Allowed
    ---000-- Spare
    ------00 Screening          : User provided, not screened
4   ******** Phone number       : [701475XXXX] <- This is the Caller ID digits sent to the Mitel from carrier (I X'd out the last 4 digits)
1   01110000 Information Element: Called Party Number:
2   IE Length                   : 11 octets
3   1------- Extension bit      : Not Continued
    -010---- Type of number     : National number
    ----0000 Numbering plan     : Unknown
4   ******** Phone number       : [701425XXXX] <- This is the DNIS digits sent on the trunk to the Mitel from the carrier (I X'd out the last 4 digits)

2018-10-11  16:39:55  Link 3  - From Mitel - HLen 4, ILen 10, IType 5
SAPI 0 TEI 0 C/R 0 P/F 0 NR 21 NS 18 INFO Dest PD=0x8 CR=0x026  CALL PROCEEDING(0x2)
1   00011000 Information Element: Channel Identification:
2   IE Length                   : 3 octets
3   1------- Extension bit      : Not Continued
    -0------ Interface ident.   : implicitly identified
    --1----- Interface type     : primary rate
    ---0---- Spare
    ----1--- Preferred/Exclusive: exclusive
    -----0-- D-channel indicator: not the D channel
    ------01 Info. chan. sel.   : as indicated in the following octets
3.2 1------- Extension bit      : Not Continued
    -00----- Coding Std         : CCITT Std
    ---0---- Channel indicated  : by following octets
    ----0011 Chan/Map type      : B-chan units
3.3 1------- Extension bit      : Not Continued - Single channel
    -0000001 Channel Number     : 1

2018-10-11  16:39:55  Link 3  - From Mitel - HLen 4, ILen 5, IType 5
SAPI 0 TEI 0 C/R 0 P/F 0 NR 21 NS 19 INFO Dest PD=0x8 CR=0x026  ALERTING(0x1)

2018-10-11  16:39:59  Link 3  - From Mitel - HLen 4, ILen 5, IType 5
SAPI 0 TEI 0 C/R 0 P/F 0 NR 21 NS 20 INFO Dest PD=0x8 CR=0x026  CONNECT(0x7)

2018-10-11  16:39:59  Link 3  - To Mitel   - HLen 4, ILen 5, IType 5
SAPI 0 TEI 0 C/R 1 P/F 0 NR 21 NS 21 INFO Orig PD=0x8 CR=0x026  CONNECT_ACK(0xf)

2018-10-11  16:40:02  Link 3  - From Mitel - HLen 4, ILen 9, IType 5
SAPI 0 TEI 0 C/R 0 P/F 0 NR 22 NS 21 INFO Dest PD=0x8 CR=0x026  DISCONNECT(0x45)
1   00001000 Information Element: Cause: 
2   IE Length                   : 2 octets
3   1------- Extension bit      : Not Continued
    -00----- Coding Standard    : CCITT
    ---0---- spare 
    ----0000 Location           : User
4   1------- Extension bit      : Not Continued
    -0010000 Cause code         : normal call clearing                         

2018-10-11  16:40:02  Link 3  - To Mitel   - HLen 4, ILen 5, IType 5
SAPI 0 TEI 0 C/R 1 P/F 0 NR 22 NS 22 INFO Orig PD=0x8 CR=0x026  RELEASE(0x4d)

2018-10-11  16:40:02  Link 3  - From Mitel - HLen 4, ILen 5, IType 5
SAPI 0 TEI 0 C/R 0 P/F 0 NR 23 NS 22 INFO Dest PD=0x8 CR=0x026  RELEASE COM(0x5a)

EDIT TRACE TSP L2L3 4 1 2 1

 HDLC CC on link 3 trace disable .

 HDLC VERBOSE on link 3 trace disable .

[petr.necas]

Interesting... No output at all?

Yes, it is strange, no output at all. When a working circuit was plugged to port 1 (7 1 2 1) the output was similar to yours. Telco company is now comparing the setup of both circuits. If they do not find anything, I will have to ask the site to renew SWAS ask Mitel for help on this.   

[sarond]

I'm thinking this is a Telco problem.

It doesn't look like the system is receiving anything on the 2nd PRI.
You have proven your programming is ok on the first port.

Sounds like a routing issue on their end.

[petr.necas]

Telco changed something on their side and the new circuit connected to 2nd port started receiving phone calls. I don't know whether it was something on Telco side or something was different in the configuration of both ports (Dual Framer).

Thanks to everybody who responded to this topic.