0 Replies Latest reply on Mar 28, 2013 2:37 PM by deonlyons

    Incoming calls are disconnected immediately when callls established or busy signal - ATLAS ADTRANS 890

    deonlyons New Member

      Hello

       

       

      I need some assistance,  I have been going back and forth with the Telco Verizon and Cisco as far as where the problem lies and why calls are being immediately disconnected or why we are receiving busy signals on inbound calls.

      The called number is 310-575-6000 the calling number in this example is 310-575-6045  and 310-738-9515.  We have this problem regardless of area code or provider the inbound call is coming from.

       

      Verizon PRI Connects ---> ATLAS ADTRANS 890 Connects--->Cisco Voice Gateway

       

      When performing a debug isdn q931 on the Cisco Voice Gateway we get the following output

       

              Progress Ind i = 0x8088 - In-band info or appropriate now available

      017479: Mar 20 14:12:58.758: ISDN Se1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x4F4A

              Bearer Capability i = 0x8090A2

      Standard = CCITT

      Transfer Capability = Speech

      Transfer Mode = Circuit

      Transfer Rate = 64 kbit/s

              Channel ID i = 0xA1838D

      Preferred, Channel 13

              Calling Party Number i = 0x0083, '3107389515'

      Plan:Unknown, Type:Unknown

              Called Party Number i = 0x80, '6000'

      Plan:Unknown, Type:Unknown

      017480: Mar 20 14:12:58.782: ISDN Se1/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0xCF4A

              Channel ID i = 0xA9838D

      Exclusive, Channel 13

      11-DC-VGTW02#

      017481: Mar 20 14:12:58.894: ISDN Se1/0:23 Q931: TX -> ALERTING pd = 8  callref = 0xCF4A

              Progress Ind i = 0x8088 - In-band info or appropriate now available

      017482: Mar 20 14:12:58.926: ISDN Se1/0:23 Q931: TX -> CONNECT pd = 8  callref = 0xCF4A

      017483: Mar 20 14:12:58.942: ISDN Se1/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x4F4A

      017484: Mar 20 14:12:59.042: ISDN Se1/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x4F4A

              Cause i = 0x8290 - Normal call clearing

       

      The Cisco Voice Gateway indicates the Telco Verizon is sending a disconnect immediately after the call is established.

       

      Cisco is pointing the finger at  Verizon.

      Verizon is pointing the finger at ATLAS 890

       

      I have installed a syslog server on my computer and captured the event logs from ATLAS 890 and included them in this post as an attachment.  If anyone could please assist me in this situation and shed light on what could be causing this issue I would greatly appreciate the help.

       

      Note: The Cisco Voice Gateway is an H323 gateway connecting to Cisco Call Manager version 9.1.1, isdn switch type primary-ni

       

      ive tried changing the switch type with no improvement - below is a snippet of the event log that is attached

       

      3/20/2013 9:23:51 PM [502] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|===================================================
      3/20/2013 9:23:51 PM [507] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| IE - 08 CAUSE Len=2
      3/20/2013 9:23:51 PM [506] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| M - 45 DISCONNECT
      3/20/2013 9:23:51 PM [505] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| Prot:08  CRL:2  CRV:947F
      3/20/2013 9:23:51 PM [504] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| Ctl:INFO     Ns:22   Nr:108
      3/20/2013 9:23:51 PM [503] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|Sent = Sapi:00  C/R:R Tei:00
      3/20/2013 9:23:51 PM [501] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Message|Sl 3|4|Sent = 00 01 2C D8 08 02 94 7F 45 08 02 80 E2
      3/20/2013 9:23:51 PM [500] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Message|Sl 3|4|Sent = 02 01 01 D8
      3/20/2013 9:23:51 PM [499] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| 07
      3/20/2013 9:23:51 PM [498] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| IE - 14 CALL STATE Len=1
      3/20/2013 9:23:51 PM [497] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|             1E Diagnostic:
      3/20/2013 9:23:51 PM [495] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|             80 Location:U
      3/20/2013 9:23:51 PM [509] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|             E2 Cause:WRONG_MESSAGE
      3/20/2013 9:23:51 PM [496] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|             E4 Cause:INVALID_ELEM_CONTENTS
      3/20/2013 9:23:51 PM [517] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Message|Sl 3|4|Sent = 02 01 01 DA
      3/20/2013 9:23:51 PM [494] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| IE - 08 CAUSE Len=3
      3/20/2013 9:23:51 PM [485] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Message|Sl 2|1|Recd = 02 01 01 1C
      3/20/2013 9:23:51 PM [523] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| M - 4D RELEASE   
      3/20/2013 9:23:51 PM [522] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| Prot:08  CRL:2  CRV:147F
      3/20/2013 9:23:51 PM [521] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| Ctl:INFO     Ns:109   Nr:23
      3/20/2013 9:23:51 PM [520] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|Recd = Sapi:00  C/R:C Tei:00
      3/20/2013 9:23:51 PM [524] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| IE - 08 CAUSE Len=2
      3/20/2013 9:23:51 PM [518] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Message|Sl 3|4|Recd = 02 01 DA 2E 08 02 14 7F 4D 08 02 80 E4
      3/20/2013 9:23:51 PM [510] From: (10.16.31.34) Fac:16 Sev:6 Msg >>> ADTRAN[ADTRAN]:L2-Message|Sl 3|4|Recd = 00 01 01 2E
      3/20/2013 9:23:51 PM [516] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| M - 0F CONNECT_ACK
      3/20/2013 9:23:51 PM [515] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| Prot:08  CRL:2  CRV:147F
      3/20/2013 9:23:51 PM [514] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4| Ctl:INFO     Ns:108   Nr:23
      3/20/2013 9:23:51 PM [513] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|Recd = Sapi:00  C/R:C Tei:00
      3/20/2013 9:23:51 PM [512] From: (10.16.31.34) Fac:16 Sev:5 Msg >>> ADTRAN[ADTRAN]:L2-Formatted|Sl 3|4|===================================================

       

       

      PROBLEM SOLVED!

       

      I would like to thank PATRICK  from the ADTRAN team for helping me solve this one:

       

      It appears that Verizon is sending the "INVALID_ELEM_CONTENTS" in response to the "INBAND AUDIO AVAIL" alerting message.

      In the case of the 6000 number, the CONNECT comes within the same second as the alerting message, so Verizon's "INVALID_ELEM_CONTENTS" actually comes after the CONNECT message, which makes it wrong. If the Cisco can delay answering the call for a second or two, then the timing will work out so Verizon can send INVALID_ELEM_CONTENTS before the CONNECT and the call will process correctly.

       

      Hope this helps,

      Patrick

       

       

       

      It turns out since we have UCCX which is a Cisco Call Center, ( and the telco appears to have changes something) we were require to put  a 1 second delay between the start of the UCCX script and answer.   Once we added a 1 second delay in the answering mechanism of automated contact center the issues was resolved.

       

      Thanks!

      Message was edited by: deonlyons