ISDN Problem "Bearer capability not implemented"
Sam Purtell
I was wondering if someone may be able to help with this problem.
Both routers have an ISDN BRI interface using Cisco switch type basic-net3.
(ETSI)
The ideal situation is for router A(local) to dial router B (remote).
Router B has no problems dialing and connecting to router A.
However when A dials B there is no progress
(Yes, We have checked we are dialing the right number :))
The weird thing is that we had Router B set up on a spare ISDN connection
in the local office right next to Router A while we configured and tested
it.
Everything worked fine.
It is only now that it is 800 miles away we cannot dial to it.
Debug isdn q931 gives us
01:16:16: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 69 changed to up
01:16:16: ISDN BR0: TX -> SETUP pd = 8 callref = 0x35
01:16:16: Bearer Capability i = 0x8890
01:16:16: Channel ID i = 0x83
01:16:16: Called Party Number i = 0x80, '0249303206'
01:16:17: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xB5
01:16:17: Channel ID i = 0x89.
01:16:18: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xB5
01:16:18: Cause i = 0x83C1 - Bearer capability not implemented
01:16:18: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x35
01:16:18: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0xB5
I would like to know where "Bearer capability" is implemented.
Is it some function of the terminal equipment or the Telco ISDN switch?
The Telco tells us all is fine with their part. I am dubious but am not
totally
sure. Would appreciate any feedback.
Meantime will hunt down some ETSI specs.
TIA
Sam
Jay R. Ashworth
> Both routers have an ISDN BRI interface using Cisco switch type basic-net3.
> (ETSI)
> The ideal situation is for router A(local) to dial router B (remote).
> Router B has no problems dialing and connecting to router A.
> However when A dials B there is no progress
> (Yes, We have checked we are dialing the right number :))
>
> The weird thing is that we had Router B set up on a spare ISDN connection
> in the local office right next to Router A while we configured and tested
> it.
> Everything worked fine.
> It is only now that it is 800 miles away we cannot dial to it.
*This*, right here, is your problem.
> Debug isdn q931 gives us
>
> 01:16:16: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 69 changed to up
> 01:16:16: ISDN BR0: TX -> SETUP pd = 8 callref = 0x35
> 01:16:16: Bearer Capability i = 0x8890
> 01:16:16: Channel ID i = 0x83
> 01:16:16: Called Party Number i = 0x80, '0249303206'
> 01:16:17: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xB5
> 01:16:17: Channel ID i = 0x89.
> 01:16:18: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xB5
> 01:16:18: Cause i = 0x83C1 - Bearer capability not implemented
> 01:16:18: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x35
> 01:16:18: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0xB5
>
> I would like to know where "Bearer capability" is implemented. Is it
> some function of the terminal equipment or the Telco ISDN switch? The
> Telco tells us all is fine with their part. I am dubious but am not
> totally sure. Would appreciate any feedback. Meantime will hunt down
> some ETSI specs.
An ISDN expert or a Cisco expert (I am neither) will no doubt chime in,
but I'd bet cash your problem is that you configured the units either
for 64K data, which the *long distance* carrier in question doesn't
provide, or even possibly for 56K data, and they don't provide that
either.
What you probably *need* to configure for is 56K Data Over Voice... but
there's no guarantee that you'll get reliable links from that, long
distance.
Cheers,
-- jra
--
Jay R. Ashworth j...@baylink.com
Member of the Technical Staff Baylink
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
David Lesher
>An ISDN expert or a Cisco expert (I am neither) will no doubt chime in,
>but I'd bet cash your problem is that you configured the units either
>for 64K data, which the *long distance* carrier in question doesn't
>provide, or even possibly for 56K data, and they don't provide that
>either.
>What you probably *need* to configure for is 56K Data Over Voice... but
>there's no guarantee that you'll get reliable links from that, long
>distance.
I disagree. Just get a carrier that is 64K clean. Using DOVBS will
likely be more grief.
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
John McHarry
Ashworth) wrote:
>What evil lurks in the hearts of men? Sam Purtell knows:
>> Both routers have an ISDN BRI interface using Cisco switch type basic-net3.
>> (ETSI)
>> The ideal situation is for router A(local) to dial router B (remote).
>> Router B has no problems dialing and connecting to router A.
>> However when A dials B there is no progress
>> (Yes, We have checked we are dialing the right number :))
>>
>> The weird thing is that we had Router B set up on a spare ISDN connection
>> in the local office right next to Router A while we configured and tested
>> it.
>> Everything worked fine.
>> It is only now that it is 800 miles away we cannot dial to it.
>
>*This*, right here, is your problem.
>An ISDN expert or a Cisco expert (I am neither) will no doubt chime in,
>but I'd bet cash your problem is that you configured the units either
>for 64K data, which the *long distance* carrier in question doesn't
>provide, or even possibly for 56K data, and they don't provide that
>either.
>
Well, sort of. At least a few years ago at least some of the BOCs
required that IXCs set up separate interconnects for ISDN service
classes other than simple voice. This was partly because they didn't
have the cards to convert everything, and partly because there is a
per trunk charge, whether it is used or not. This had the effect of
choking inter-LATA ISDN data capability. This certainly put smaller
carriers out of the market. Perhaps the big kids are now dropping it.
There isn't a lot of market for ISDN these days.
(All this presumes the original post was US. YMMV.)
_______________________________
people who might like some spam:
7073...@compuserve.com alb...@silhouettes-inc.com in...@atlantistech.com
Dave Phelps
There may be some others. When you place an ISDN call, the originating side specifies the type of
call it is placing (bearer capability), the local CO must allow it, the far end CO must allow it,
and the far end answering device must allow it. If you post on comp.dcom.sys.cisco, you will
probably get a better answer. There are usually some Cisco guys lurking who know these codes from
your debug off the top of their head and can tell you exactly what it means. That failing, you may
want to open a case with TAC.
Dave Phelps
Phone Masters Ltd.
tippe...@nospam.com
nospam=bigfoot
PRDoran
wrote:
I'd go back to the carrier and ask them to put a protocol analyzer on
the call. Many times when you ask them to test the line the just look
to see if they can see the terminal devise. We had the same problem
with a setup in Ottawa and it took 5 calls to AT&T before they did
anything, of course they never said they found the problem we just
stopped getting the message and the calls started connecting. I am
assuming that you did check your far end device to make sure it wasn't
sending the d channel message<g>.
Paul
ken
"Sam Purtell" <s...@hitech.net.au> wrote in message
news:98891379...@clover.origin.net.au...
Bearer Capability i = 0x8890
88 CCITT coding; Unrestricted digital information
90 64Kbit/s circuit mode
Channel ID i = 0x83
Basic rate, any B channel
Channel ID i = 0x89
Basic rate, B1 channel only
Cause
83 C1
3 No Route to destination
65 Bearer capability not implemented
HTH
Myron Harvey
wrote:
>Hi
Have you checked to see if you have a long distance provider specified
for the isdn line? When I signed up for an isdn line, default was
none.
Sam Purtell
Thanks to everybody here and in comp.dcom.sys.cisco who has responded to my
post
The general consensus was that maybe
We did not have 64K capability through our long distance carriers.
We do, and there is really only one choice here in Australia.
Also we are able to dial from router B to router A no worries.
We had restrictions on long distance calls from our A end service.
We asked the Telco a number of times to check that.
We checked it ourselves by dialing ISP's access servers in the same
area and got call connected OK (failed authentication naturally but
proved a point)
The problem lies in the ISDN switch network.
Well yes :)
.
In Australia we have a very hard time convincing the
carrier (Telstra) that they have a problem and generally
have to go to great lengths to prove a point.
We are currently shipping another router to the remote
site so when asked "did you check your equipment"
............ well you get the picture.
I guess the one consolation is that because router B
can dial router A without a care in
the world, the network can actually operate. There would be a bit more
teeth gnashing if this
was not the case. :)
Thanks again to everyone. I am now familiar with some q931 codes.
(would learn nothing if everything worked 1st time)
Cheers
Sam
-dps
like the us then::
0. There really isn't anything strange about the call working from Z to A,
but not A to Z. Routing entries in the telco's switches are static and are
probably setup so calls going from Z to A travel over different trunk-groups
than calls going from A to Z.
1. Any decent telco should be able to pull CDRs (Call Detail Records) on
the failed call. They should be able to pull a CDR from each switch the
call travels over and find the switch that failed the call. Specifically
request this to be done.
2. If #1 cannot be done, have the telco capture SS7 messages between their
switches to see where the call is failing.
3. Most telco switches have loop-back phone numbers associated with them.
Have the telco dispatch to the A site with an ISDN test set and have them
place a call to the loop-back number of Z's local telco switch. This would
make them acknowledge that their network is failing the call.
Unfortunately, it sounds like your telco doesn't have any competent
technicians otherwise they would have solved this already. Good luck!