Adtran
Help
The Adtran community holiday season is starting next week! The holiday period will span from December 21, 2024 to January 6, 2025. During this time, responses to feedback form submissions may be delayed. If you are encountering product issues, you can reach out to Adtran support at any time.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
deonlyons
New Contributor
‎03-21-2013 01:18 AM

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

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

ADTRANS_890-Syslog_3202013_92553_PM.txt.zip
0 Kudos
Reply