problem with callback on Router 3725 (digital modems )

[pavlosd]

Hello Guys,

I was following the example under http://www.cisco.com/en/US/tech/tk801/tk36/technologies_configuration_example09186a0080094338.shtml in order to setup a callback server. Unfortunately it does not work...

Attached is the conf and debug files...

Can anybody help?

Version

--------

Cisco Internetwork Operating System Software

IOS (tm) 3700 Software (C3725-IK9S-M), Version 12.3(6), RELEASE SOFTWARE (fc3)

Copyright (c) 1986-2004 by cisco Systems, Inc.

Compiled Wed 11-Feb-04 15:42 by kellythw

Image text-base: 0x60008AF4, data-base: 0x61DC8000

ROM: System Bootstrap, Version 12.2(8r)T2, RELEASE SOFTWARE (fc1)

Medousa uptime is 1 hour, 55 minutes

System returned to ROM by reload at 17:34:58 EEST Wed Jun 16 2004

System restarted at 17:36:29 EEST Wed Jun 16 2004

System image file is "flash:c3725-ik9s-mz.123-6.bin"

This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

export@cisco.com.

cisco 3725 (R7000) processor (revision 0.1) with 120832K/10240K bytes of memory.

Processor board ID JMX0817L3R1

R7000 CPU at 240MHz, Implementation 39, Rev 3.3, 256KB L2 Cache

MICA-6DM Firmware: CP ver 2940 - 7/24/2002, SP ver 2940 - 7/24/2002.

Bridging software.

X.25 software, Version 3.0.0.

SuperLAT software (copyright 1990 by Meridian Technology Corp).

Basic Rate ISDN software, Version 1.1.

2 FastEthernet/IEEE 802.3 interface(s)

8 ISDN Basic Rate interface(s)

12 terminal line(s)

DRAM configuration is 64 bits wide with parity disabled.

55K bytes of non-volatile configuration memory.

125184K bytes of ATA System CompactFlash (Read/Write)

Configuration register is 0x2102

Slot 2:MICA-6DM Firmware, Source - IOS

CP ver 2940 - 7/24/2002, CheckSum BB345F13.

SP ver 2940 - 7/24/2002.

MICA 0: HW Version 1.0, Serial Number 31892928.

MICA 1: HW Version 1.1, Serial Number 31891928.

MICA 2: Not Installed.

MICA 3: Not Installed.

MICA 4: Not Installed.

[makchitale]

The callback process looks good till timestamp 19:12:38, after the BRI attempts to callback we receive a disconnect from the telco switch:

Jun 16 19:12:38: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8 callref = 0x8C

Cause i = 0x8281 - Unallocated/unassigned number

82 - From the public network near the local user (local telco switch).

81-The ISDN number is sent to the switch in the correct format. However, the number is not assigned to destination equipment.

As a quick test, can you reverse telnet into a modem & try calling the same number “ATDT22112211” & see if the call goes through .

Thanks, Mak

[pavlosd]

Hello Mak, Reverse telneting and call from a digital modem seems to work fine as well. Find attached the reverse telnet debug traces.....

[makchitale · Accepted solution]

Here is what I see different between these 2 calls (router initiated callback & reverse telnet ATDT call)

1. The numbers that are dialed are different, 22111122 with reverse telnet & 22112211 as per configuration for callback. Will be interesting to see when you dial the 22112211 with reverse telnet session (maybe it will not make a difference but since we were getting unallocated/ unassigned number from the switch when dialing 22112211..1st set of debugs)

2. The reverse telnet logs below for atdt22111122 show that we have past the first switch (closest to the calling side) but we never reach CONNECT state on the ISDN layer so the modem handshake will not be able to ride over the ISDN connectivity (should receive a RX <- CONNECT ) & see modem waiting for ISDN connectivity (CSM_PROC_OC_ISDN_CONNECT_PENDING)

Jun 17 13:17:04: ISDN BR1/7 Q931: RX <- ALERTING pd = 8 callref = 0x95

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

Jun 17 13:17:04: CSM: MODEM_REPORT from 1/7:0, call_id=0x8024, event=0x5, cause=0x0, dchan_idb=0x6389C290

Jun 17 13:17:04: Modem 2/0 CSM: MODEM_REPORT rcvd DEV_CALL_PROGRESSING for call_id 0x8024

Jun 17 13:17:04: Modem 2/0 CSM: (CSM_PROC_OC_ISDN_CONNECT_PENDING)<--ISDN_CALL_PROGRESSING

Jun 17 13:17:05: Modem 2/0 CSM: (CSM_PROC_OC_ISDN_CONNECT_PENDING)<--MODEM_TONE_DETECTED

Jun 17 13:17:05: Modem 2/0 Mica: Detected Dial tone

Jun 17 13:17:10: ISDN BR1/7 Q931: RX <- DISCONNECT pd = 8 callref = 0x95

Thanks, Mak

[pavlosd]

Ok, here is a trace with calling itself(22112211).

Can you suggest anything?

[makchitale]

Do not see the "deb isdn q931" output in these logs.

Another way to test is reverse telnet, then ATDTxxx & we should see the RI (ring indicator) flashing on modem.

Thanks, Mak

[pavlosd]

Hi Mak,

The following rather strange problem occurs, sometimes the call succeeds and sometimes it fails. As you said, it has to do with the CONNECT state from ISDN q931. I am using isdn switch-type basic-net3 so I do not configure any values from my site the ISDN site (i.e. spid). Any ideas why it may sometime succeed and others fail? The same senario occurs with callback. If I keep trying it will eventually succeed.

Thanks.

[makchitale]

Is this in a lab environment? Do we have an ISDN simulator? If yes, there is some inconsistent behaviour in the simulator.

If no, then we need to get the ISDN provider involved. The Access server seems to be negotiating & initiating the callback.

Thanks, Mak

[pavlosd]

Hi Mak,

it's a live environment. Ok I will see what I can do. Thanks for all your time and help.