Author Topic: Dropped calls from one MCD but not the other MCD  (Read 5646 times)

Offline mszodiac

  • Sr. Member
  • ****
  • Posts: 232
  • Country: ca
  • Karma: +7/-0
    • View Profile
Dropped calls from one MCD but not the other MCD
« on: February 21, 2014, 11:30:27 AM »
Hello.  This is a really strange problem for us. 
We call into an external IVR system but the calls get dropped approximately after 60 seconds.  Here's the network setup:

IP set is connected to MCD1 which has all the users. 
MCD1 connects to MCD2 via IP/XNET trunking.
MCD2 is the PSTN gateway.
Both MCDs are in the same cluster.

If I register my IP set to MCD2, I can call the IVR system and complete the entire call without any problem.  Is there a system timer, that's ending the call prematurely? The CCS trace shows network disconnect.  Here's the trace of a failed call.


Trace from MCD1
                                                                                                           
08:27:52 RIX DPN PBX3 460 351 D** B** A CCM     *58*CP*G#                       
08:27:52 ROX DPN PBX392 1808 1516 D** B** A CCM     *58*CP*G#                   
08:27:56 ROX DPN PBX3 725 662 D** B** 2C ISRM_I                                 
           ;10;*1#*50*3679#*58A*Cc*4*3679#*100*iNOC Test#                       
08:27:56 ROX DPN PBX3 725 662 D** B** 28 SSRM_I                                 
           *19*Z#*58*Ca*1*Z#*58*CW*XBXv@@@@D|emC@#                             
08:27:56 ROX DPN PBX3 725 662 D** B** 29 SSRM_I                                 
           *58*C6*001#*58*CL*E*311*3679*Q3114364*A#                             
08:27:56 ROX DPN PBX3 725 662 D** B** 17 SSRM_C  *58*C4*4*1#18775712639         
08:27:56 RIX DPN PBX3 725 662 D** B** 7 NIM     *51*7#                         
08:27:58 RIX DPN PBX3 725 662 D** B** 13 NIM     *240*`XD#*58*Ca*2#             
08:28:57 RIX DPN PBX3 725 662 D** B** 2 CRM/CIM ;2;                         

=========================
Trace from MCD2                                                                                                       
                 
08:27:56 RIX DPN PBX1 662 725 D** B** 2C ISRM_I                                 
           ;10;*1#*50*3679#*58A*Cc*4*3679#*100*iNOC Test#                       
08:27:56 RIX DPN PBX1 662 725 D** B** 28 SSRM_I                                 
           *19*Z#*58*Ca*1*Z#*58*CW*XBXv@@@@D|emC@#                             
08:27:56 RIX DPN PBX1 662 725 D** B** 29 SSRM_I                                 
           *58*C6*001#*58*CL*E*311*3679*Q3114364*A#                             
08:27:56 RIX DPN PBX1 662 725 D** B** 17 SSRM_C  *58*C4*4*1#18775712639         
08:27:56 RO107 DPN 2C ISRM_I  ;10;*1#*50*3679#*58A*Cc*4*3679#*100*iNOC Test#   
08:27:56 RO107 DPN 28 SSRM_I  *19*Y#*58*Ca*1*Y#*58*CW*XBXv@@@@D|emC@#           
08:27:56 RO107 DPN 29 SSRM_I  *58*C6*001#*58*CL*E*311*3679*Q3114364*C#         
08:27:56 RO107 DPN 23 SSRM_C  *58*C4*4*1#*58*C4*4*1#818775712639               
08:27:56 RI107 DPN 7  NIM     *51*7#                                           
08:27:56 ROX DPN PBX1 662 725 D** B** 7 NIM     *51*7#                         
08:27:58 RI107 DPN 13 NIM     *240*`XD#*58*Ca*2#                               
08:27:58 ROX DPN PBX1 662 725 D** B** 13 NIM     *240*`XD#*58*Ca*2#             
08:28:57 ROX DPN PBX1 662 725 D** B** 2 CRM/CIM ;2;                             
08:28:57 RI107 DPN 2  CRM/CIM ;2;                                               
08:28:57 RIX DPN PBX1 662 725 D** B** 2 CRM/CIM ;2;   


Offline jrg0852

  • Sr. Member
  • ****
  • Posts: 309
  • Country: us
  • Karma: +3/-0
  • Look out for the next tech. because it may be you!
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #1 on: February 21, 2014, 01:28:19 PM »
Under Call Duration in COS make sure the 4 settings are default, so..........10 min, 0 min, No, No

Offline wiseguy

  • Sr. Member
  • ****
  • Posts: 202
  • Country: nl
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #2 on: February 21, 2014, 01:55:15 PM »
It looks like the call is going out on Trunk 107 and the controller is awaiting a NAM ( other side is ringing) message. As it is not receiving any message it is clearing the connection. Try to find the reason why there is no response on the other side.

Offline mszodiac

  • Sr. Member
  • ****
  • Posts: 232
  • Country: ca
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #3 on: February 21, 2014, 02:59:45 PM »
@ jrg0852: COS Call Duration of the IP sets and the IP/XNET trunk are at default.

@ wiseguy: I'm puzzled as to why the other side would wait for the ringing since the call has been established but then disconnects after 60 seconds.

With my IP set connected to MCD2, my call goes through fine.  Here's a CCS trace.
                           
14:52:25 RO107 DPN 2D ISRM_I  ;10;*1#*50*3113620#*58A*Cc*4*3113620#*100*test#   
14:52:25 RO107 DPN 28 SSRM_I  *19*Z#*58*Ca*1*Z#*58*CW*cEDv@@@@BkbqMP#           
14:52:25 RO107 DPN 2C SSRM_I  *58*C6*001#*58*CL*E*311*3113620*G3114201*A#       
14:52:25 RO107 DPN 18 SSRM_C  *58*C4*4*1#818775712639                           
14:52:25 RI107 DPN 7  NIM     *51*7#                                           
14:52:27 RI107 DPN 13 NIM     *240*`XD#*58*Ca*2#                                 
14:53:38 RO107 DPN 2  CRM/CIM ;30;                                             
14:53:38 RI107 DPN 2  CRM/CIM ;30;                                             

Online ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5767
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #4 on: February 21, 2014, 03:27:33 PM »
It may be all you have to do is in the CDN of the trunk connected to the IVR enable "fake answer supervision".

Ralph

Offline mszodiac

  • Sr. Member
  • ****
  • Posts: 232
  • Country: ca
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #5 on: February 21, 2014, 04:01:28 PM »
@ ralph, we don't have access to the IVR system.  But we have a T1 ISDN link to the Telco.  No "fake answer supervision" in the circuit descriptor.

Offline wiseguy

  • Sr. Member
  • ****
  • Posts: 202
  • Country: nl
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #6 on: February 24, 2014, 05:56:44 PM »
Your call is NOT going through fine. If that would be the case you would have received a NAM message to indicate that the other side is ringing. The MCD you are on is awaiting feedback from the remote side. That is where your problem is.Can you call reversed?

Offline wiseguy

  • Sr. Member
  • ****
  • Posts: 202
  • Country: nl
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #7 on: February 24, 2014, 06:01:52 PM »
If you have an ISDN connection to your telco and it should be going out there please do an EDT TR TSP L2L3 X X X X on that link. That should be telling us what you're sending out and the responses from your telco.

Offline mszodiac

  • Sr. Member
  • ****
  • Posts: 232
  • Country: ca
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #8 on: March 04, 2014, 11:12:08 AM »
@ wiseguy:
Here's what I got with EDT trace.  I've never used this trace command before so I don't know if it has all the call details.  Although I do see we are sending the correct digits. 

1   01101100 Information Element: Calling Party Number:
2   IE Length                   : 6 octets
3   0------- Extension bit      : Continued
    -000---- Type of number     : unknown
    ----1001 Numbering plan     : Private numbering
3a  1------- Extension bit      : Not Continued
    -00----- Presentation       : Allowed
    ---000-- Spare
    ------00 Screening          : User provided, not screened
4   ******** Phone number       : [3679]
1   01110000 Information Element: Called Party Number:
2   IE Length                   : 13 octets
3   1------- Extension bit      : Not Continued
    -000---- Type of number     : Unknown
    ----0000 Numbering plan     : Unknown
4   ******** Phone number       : [818775712639]
2014-03-04  10:55:52  Link 1  - To Mitel   - HLen 4, ILen 12, IType 5
SAPI 0 TEI 0 C/R 1 P/F 0 NR 57 NS 73 INFO Dest PD=0x8 CR=0x30f8  pri_STATUS(0x7d)
1   00001000 Information Element: Cause: 
2   IE Length                   : 2 octets
3   1------- Extension bit      : Not Continued
    -00----- Coding Standard    : CCITT
    ---0---- spare 
    ----0101 Location           : Private network serving the remote user
4   1------- Extension bit      : Not Continued
    -1100011 Cause code         : Information element/parameter non-existent   
2   IE Length                   : 1 octets
.               : 2 octets
3   00------ Coding Std         : CCITT Std
    --000110 Call State         : Call present

2014-03-04  10:55:52  Link 1  - To Mitel   - HLen 4, ILen 10, IType 5
SAPI 0 TEI 0 C/R 1 P/F 0 NR 57 NS 74 INFO Dest PD=0x8 CR=0x30f8  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
    -0000110 Channel Number     : 6

2014-03-04  10:55:53  Link 1  - To Mitel   - HLen 4, ILen 13, IType 5
SAPI 0 TEI 0 C/R 1 P/F 0 NR 57 NS 75 INFO Dest PD=0x8 CR=0x30f8  PROGRESS(0x3)
1   00001000 Information Element: Cause: 
2   IE Length                   : 2 octets
3   1------- Extension bit      : Not Continued
    -00----- Coding Standard    : CCITT
    ---0---- spare 
    ----0010 Location           : Public network serving the local user
4   1------- Extension bit      : Not Continued
    -0011111 Cause code         : normal unspecified                           
1   00011110 Information Element: Progress Indicator:
2   IE Length                   : 2 octets
3   1------- Extension bit      : Not Continued
    -00----- Coding Standard    : CCITT
    ---0---- Spare              : Spare
    ----0010 Location           : Public network serving the local user
4   1------- Extension bit      : Not Continued
    -0000001 Description        : Call is not end-to-end ISDN

2014-03-04  10:56:49  Link 1  - From Mitel - HLen 4, ILen 119, IType 6
SAPI 0 TEI 0 C/R 0 P/F 0 NR 76 NS 57 INFO Orig PD=0x8 CR=0x30f9  SETUP(0x5)
1   10100001 Information Element: Sending Complete:
1   00000100 Information Element: Bearer Capability:
2   IE Length                   : 3  octets
3   1------- Extension bit      : Not Continued
    -00----- Coding Standard    : CCITT
    ---10000 Info. trans. cap.  : 3.1 kHZ audio
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
    ----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
    -0001000 Channel Number     : 8

Offline mszodiac

  • Sr. Member
  • ****
  • Posts: 232
  • Country: ca
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #9 on: March 12, 2014, 11:50:57 AM »
Calling the exact same number from our resilient system works! What's puzzling is both systems are configured the same.  On the CCS trace, it shows we are not getting an incoming NIM from the ISDN.

09:21:46 RI201 DPN A  NIM     *240*`XD#

What could prevent NIM message from being received/sent? Thanks.  This problem has been <no nice words to say >:(

Offline wiseguy

  • Sr. Member
  • ****
  • Posts: 202
  • Country: nl
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #10 on: March 13, 2014, 07:30:39 PM »
The status message after the setup is probably telling you that the number that your sending out as calling party is invalid. That is not the reason for the issue. Needs cleaning up. The bottom setup I hope is telling you that your outgoing call is set to 3.1Khz, that might be an issue. Not all equipment can handle this. Your outgoing call charactaristics are set to call by call. If your familiar with this try going to fixed. Watch out for the digit absorbtion that is related to these pages.

Offline jrg0852

  • Sr. Member
  • ****
  • Posts: 309
  • Country: us
  • Karma: +3/-0
  • Look out for the next tech. because it may be you!
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #11 on: March 14, 2014, 09:48:59 AM »
Is your CPN substitution identical?

Offline mszodiac

  • Sr. Member
  • ****
  • Posts: 232
  • Country: ca
  • Karma: +7/-0
    • View Profile
Re: Dropped calls from one MCD but not the other MCD
« Reply #12 on: March 17, 2014, 09:41:06 AM »
Our systems were running release 6.0 SP1.  The problem got fixed after we upgraded our systems to release 6.0 SP2!  :)

What's interesting is that the issue we had was reported in software load 9.0.0.41 and was resolved in the following release.  It somehow got missed in SP1 -but only on the MCD platforms and not on the virtual MCDs.  Here's the details of the bug from document 08-5104-00051_34.doc.

MN00285756   Call out PRI to IVR drops after 60 seconds
REPORTED IN SW LOAD   9.0.0.41
SYMPTOMS
Call out a Mitel PRI to a IVR system. The CO provides a call progress, but no alerting or connects message when the IVR answers. Call gets dropped after 60 seconds.

WORKAROUND
From a telnet session to 3300-call control, issue ccs disable dpns early. This command does not survive a reboot

Thank you everyone for your inputs.


 

Sitemap 1 2 3 4 5 6 7 8 9 10