Friday, June 20, 2008

ISDN Caller ID and Cisco ISDN routers

We recently had a ISDN-2e line installed at work. But I forgot to ask BT (British Telecom) for 'caller ID' aka CLID to be enabled. BT terminology for this is the 'Calling Line Identity Presentation' or CLIP service, and BT will only enable it if you specifically ask for it, and there is an additional charge for the service.

Without the number of the calling party, the Cisco router does not know which 'Dialer profile' to associate with the incoming call, and rejects the call.

I kept a record of the log from the Cisco router, before and after enabling CLID, so here we can see the differences.

While doing the testing & troubleshooting, I had debugging enable on the cisco router as follows:

#show debug
Dial on demand:
Dial on demand events debugging is on

The following ISDN debugs are enabled on all DSLs:

debug isdn error is ON.
debug isdn event is ON.
debug isdn q931 is ON.

First an incoming data call, before BT enabled CLID on the ISDN line:

ISDN BR0 Q931: RX <- SETUP pd = 8 callref = 0x01
Sending Complete
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Called Party Number i = 0x81, '67xxxx'
Plan:ISDN, Type:Unknown
ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x14 calltype 1 HOST_INCOMING_CALL
ISDN BR0:1: Incoming call rejected, unbindable
ISDN BR0 **ERROR**: host_incoming_call: DIALER ERROR 0x1: b channel 0, call id 0x14
ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x14 calltype 1 HOST_DISCONNECT_ACK
ISDN BR0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x81
Cause i = 0x8095 - Call rejected

After BT enabled CLID, which was done within a couple of hours, the log shows this:

ISDN BR0 Q931: RX <- SETUP pd = 8 callref = 0x01
Sending Complete
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Calling Party Number i = 0x2183, '142761xxxx'
Plan:ISDN, Type:National
Called Party Number i = 0x81, '67xxxx'
Plan:ISDN, Type:Unknown
ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x17 calltype 1 HOST_INCOMING_CALL
BR0:1 DDR: Caller id 142761xxxx matched to profile
%DIALER-6-BIND: Interface BR0:1 bound to profile Di1

I also tried making a voice call to the ISDN number, which I knew would fail, just to see what it looked like. Here is before CLID was enabled:

ISDN BR0 Q931: RX <- SETUP pd = 8 callref = 0x01
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Called Party Number i = 0x81, '67xxxx'
Plan:ISDN, Type:Unknown
ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x11 calltype 2 HOST_INCOMING_CALL
ISDN BR0 **ERROR**: host_incoming_call: Received a call with a bad bearer cap from <unknown> on B1

And here is a voice call, after CLID enabled:

ISDN BR0 Q931: RX <- SETUP pd = 8 callref = 0x01
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Calling Party Number i = 0x2183, '142768xxxx'
Plan:ISDN, Type:National
Called Party Number i = 0x81, '67xxxx'
Plan:ISDN, Type:Unknown
ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x19 calltype 2 HOST_INCOMING_CALL
ISDN BR0 **ERROR**: host_incoming_call: Received a call with a bad bearer cap from 142768xxxx on B1

By the way, the Cisco router was a 1721 using IOS v12.3

#show version
Cisco Internetwork Operating System Software
IOS (tm) C1700 Software (C1700-Y-M), Version 12.3(26), RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by cisco Systems, Inc.
Compiled Mon 17-Mar-08 14:24 by dchih

ROM: System Bootstrap, Version 12.2(7r)XM1, RELEASE SOFTWARE (fc1)
System returned to ROM by power-on
System restarted at 12:53:16 GMT Wed May 21 2008
System image file is "flash:c1700-y-mz.123-26.bin"

cisco 1721 (MPC860P) processor (revision 0x100) with 28231K/4537K bytes of memory.
MPC860P processor: part number 5, mask 2
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 FastEthernet/IEEE 802.3 interface(s)
1 Serial(sync/async) network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)

Thursday, June 12, 2008

Oracle, Access & ODBC: Problems & Solution

I was using Microsoft Access, in this case Access 97, to connect to an Oracle 10g database, using the ability of Access to set linked tables using an ODBC data source.

For the client, I was using the Oracle Instant Client v10.1.0.4 and setting an environmental variable NLS_LANG.

I was seeing two problems. First, when trying to link to the tables/views on the Oracle server, after selecting the ODBC data source DSN, Access would list all the tables/views on the Oracle server, but It would only display the first character of the name of the tables/views, making it impossible to find the correct table/view.

Second, when I tried setting up the Oracle linked tables in the Access MDB file on another PC, where everything was working ok, and then going back to the original problem PC and opening same MDB file, when opening the Oracle linked tables, all rows and all fields contained #Deleted.

I did a Google and found this Microsoft KnowledgeBase article - Q913070:
#Deleted is displayed in the records when you open a linked ODBC table from an Oracle 10g database in Access 2003, in Access 2002, or in Access 2000


To cut a long story short, I had set the client side environmental variable
NLS_LANG = ENGLISH_UNITED KINGDOM.WE8ISO8859P1

but this did not match the setting on the Oracle database, and I was advised
by our Oracle DBA that I should have been using:
NLS_LANG = ENGLISH_UNITED KINGDOM.WE8MSWIN1252


Apparently, our Oracle DBA had changed the NLS_CHARACTERSET of the database at some stage in the past.

After I corrected the value of NLS_LANG, everything starting working ok. It seems WE8MSWIN1252 is a binary super set of WE8ISO8859P1.

See these links for further background: