Support
Community

deonlyons · ‎03-21-2013

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

SupportCommunity

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

Support
Community