Michael,
I knew the bits and bytes didn't sound right but I couldn't remember what
the number represented.
I didn't go into it very much in detail on the news server but the issue was
a timing one. In running debug isdn q931 I could see the link connect on the
second channel but would receive an error that stated the remote site had
disconnected the call. Unfortunately, the link was open and both channels
were connected. This could be seen by looking at q921 debug packets which
never had any errors.
It made no difference which direction I called or which number dialed first.
As soon as the load threshold was achieved and the second channel came up,
no data would transverse the link. I began to look at timing issues when I
found that slowing the connection speed to 56k (even though they were 64k)
kept it up for a longer period of time (2 to 5 minutes vs. immediately upon
connecting the 2nd channels).
I ended up going into Cisco's third tier support with the results of the
debug messages and their response was basically that there can be strange
timing problems with ISDN when their is a long distance to the demarc. Also,
the phone installer said it was 1000 feet. He may have been right but it
didn't look even close to that to me.
Thanks for clarifying the dialer load-threshold setting.
David Armstrong
""michael owuor"" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
>
>
> >From: "David Armstrong" <[EMAIL PROTECTED]>
> >Reply-To: "David Armstrong" <[EMAIL PROTECTED]>
> >Subject: Re: ISDN call disconnects automatically !
>
> >
> >I had a similar problem last year. The trouble was a result of the demarc
> >being too far from the router (about 500 feet). I resolved the problem by
> >removing the "ppp multilink" statement which bound both lines (SPIDs)
into
> >one connection and let them connect separately. Also, add a "dialer
> >load-threshold 2 either" statement if this solution works for you. That
> >statement will ensure connection of each line after only 2 bytes (bits?)
of
> >data have transversed the link. This needs to be done on both ends.
> >
> >Hope this helps,
> >
> >David Armstrong
>
>
> That's interesting that a problem caused by the distance to the demarc
> should be resolved by disabling PPP multilink......but i've seen stranger
> things too.
>
> Just a note on your statement regarding the dialer load-threshold
statement:
> The number you put at the end of this statement can be of any value
between
> 1 and 255, and is not really a measure of bytes or bits. Its a value used
> when comparing the traffic load on the first B channel when deciding when
to
> activate the second B channel. For example, a value of 200 would mean that
> you want the second B channel to be activated when the load on the first
one
> reaches about 78% (200/255*100). Its needed on the dialing side. A peer
that
> only receives calls wouln't need the statement.
>
> Hans,
> Have you been able to run other debugs such as debug dialer or debug isdn
> q931? These could possible give output that could be eye-opening. The call
> here is disconnected after 120 seconds which is also the default value for
> the dialer idle-timeout. But you menioned that you do have traffic going
> across at that time. Can you post the relevant configs for both ends? If
> there's nothing wrong with them, you could be running into a bug where the
> idle timer is not reset despite interesting traffic. I don't have the ID
> right now, but know there is one.
>
> Michael a o
>
>
>
> >
> >""Hans Schimek"" <[EMAIL PROTECTED]> wrote in message
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > ISDN calls get disconncted after some time -
> > > though traffic is flowing - and the interface
> > > is NOT idle - so it should not be disconncted -
> > > or is there a timer which disconnects all calls
> > > after a while ?
> > >
> > >
> > > thanx in advance
> > >
> > >
> > > 00:42:199726942860: ISDN BR1/0: received HOST_DISCONNECT call_id
0x8012
> > > 00:42:197568495616: ISDN BR1/0: Event: Call to <unknown> was hung up.
> > > 00:42:199726942732: ISDN BR1/0: process_disc_ack(): call id 0x8012,
ces
> >1,
> > > call
> > > type DATA
> > > 00:42:197568495663: %ISDN-6-DISCONNECT: Interface BRI1/0:1
disconnected
> > > from 20
> > > 2504, call lasted 120 seconds
> > > 00:42:199726942540: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state
to
> > > down
> > > 00:42:199724968501: ISDN BR1/0: received HOST_DISCONNECT_ACK call_id
> >0x8012
> > > 00:42:197568495616: ISDN BR1/0: HOST_DISCONNECT_ACK: call type is DATA
> > > 00:42:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1,
> >changed
> > > stat
> > > e to down
> > > 00:42:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> >Virtual-Access1,
> > > chang
> > > ed state to down
> > >
> > >
> > >
> > >
> > >
> > > =============================
> > > Hans Schimek
> > >
> > > Student
> > > Fachhochschule St. Pölten f.
> > > Telekommunikation und Medien
> > >
> > > mailto: [EMAIL PROTECTED]
> > > gsm : +43 699 10605315
> > > fax : +43 3613 2311 4
> > > icq : 22308773
> > > www : www.schimek.net
> > >
> > > =============================
> > >
> > > _________________________________
> > > FAQ, list archives, and subscription info:
> >http://www.groupstudy.com/list/cisco.html
> > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> > >
> >
> >
> >_________________________________
> >FAQ, list archives, and subscription info:
> >http://www.groupstudy.com/list/cisco.html
> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
> _________________________________
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
