cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
898
Views
6
Helpful
5
Replies

ISDN Error

cpartsenidis
Level 1
Level 1

Hi everyone,

I've got an ISDN problem which has arise the past couple of weeks at a customer.

The customer has a 2811 CCME with IOS

c2800nm-adventerprisek9-mz.124-11.T2.bin

and three VIC2B-NT/TE cards.

All incoming calls are routed to a unity express module on the router where an auto attendant answers the calls.

The problem is that at random times, when there's an incoming call, the caller does not hear any ringing and the call doesn't go to the auto attendant.

I've set all incoming calls to be routed to an internal extension (thinking it might be a unity express problem) but I have the same result.

If I go to the BRI interface and issue a 'shutdown' and then 'no shutdown', the issue is resolved and incoming calls are answered correctly.

An additional debugging performed showed the following error:

Jan 14 09:02:17.816: ISDN BR0/0/1 Q931: RX <- SETUP pd = 8 callref = 0x5B

Sending Complete

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x89

Exclusive, B1

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x00A3, N/A

Plan:Unknown, Type:Unknown

Called Party Number i = 0xC1, '211030'

Plan:ISDN, Type:Subscriber(local)

Jan 14 09:02:17.816: ISDN **ERROR**: Module-CCBRI Function-_SetNewChan Error-Cannot get an idle channel from chan mgt. Data- 0, 2

Note that during the time the problem is evident, outgoing calls work properly.

Any ideas or suggestions?

Many thanks

5 Replies 5

paolo bevilacqua
Hall of Fame
Hall of Fame

Hi, the image you are running has many bugs for the voice part, really too much to list here (cfr release notes).

If you upgrade to 12.4(11)XJ4, or 12.4(11)XW5, chances are the issue will be resolved.

Note these releases are not less stable by any mean that generic T release, actually the opposite, being platform specific, bug fixes are incorporated much sooner. Again the proof is in the release notes.

Hope this helps, please rate post if it does!

I'll try upgrading to release c2800nm-adventerprisek9-mz.124-15.T1.bin and see how that goes.

Expect my feedback soon

Many thanks!

Sure. Just be advised that 12.4(15)T1 has bugs not fixed in XJ4 or XW5, for the reasons explained above.

Check for example CSCsi94745 that prevents you from forwarding to PSTN number unless a workaround is used.

Bevilacqua,

Your point is taken. The problem is that I can't take the risk and load an 'unofficial' stable release on the router, so I placed 12.4.15.

If the problem persists, I'll then be forced to move to the versions you suggested.

Many thanks.

Hi,

Understand what you are saying, but please note that all of 12.4(x)Tx, 12.4(11)XJx and 12.4(11)XWx, do have a status of "ED" meaning "Early Deployment". In that sense, these have the same "risk status", but 12.4(15)T1 has added features not having anything to do with voice, and is the first maintenante release (the 1 after T).

While 12.4(11)XJ4 means is the fourth maintenance release (the 4 after XJ), hence more has more bugs fixed and is reccomended not only by self, but by the cisco TAC as well.

There is nothing unofficial in both T and XJ/XW or whatever, again the "risk status" according to cisco, is reflected in the LD status.

Then, if you look at 12.4(x) mainline (no T or other letters), the status is LD meaning "Limited Deployment". That is also is different and lesser than "GD" or "General Deployment", a status that no 12.4 version has reached yet.

Of course the problem with LD or GD is that often these don't support the software or hardware features that you need.

Hope this can help in the issue of the releasing system.