From: Alan Benjamin (abenjami@cisco.com)
Date: Tue Jun 17 2003 - 09:14:37 GMT-3
Exactly. The command forces a delay (in seconds) between all outbound dial
attempts--and, in my case, was used to slow down the router so that
successive call attempts were not launched too soon to one another in order
to accommodate issues with the distant-end telco switch. Without the
command, the second call attempt is launched almost immediately after the
first one fails (because the channel at the other end is legitimately busy).
Take care,
Alan
At 07:53 PM 6/17/2003 +0800, wing_lam@jossynergy.com wrote:
>Thx Alan,
>
>Let me clarify, do you mean "fast-rollover delay" is used when I want to
>insert delay to wake up another B channel, while the first is already
>established. We do this because carrier switches may not process as fast as
>the router can?
>
>Thx,
>BBD (Big Black Dog)
>
>
>
>
>
>
>
> Alan
> Benjamin
>
> <abenjami@cisco.c To:
> wing_lam@jossynergy.com
> om> cc:
> ccielab@groupstudy.com
> Sent by: Subject: Re: ISDN
> timers
> nobody@groupstudy
>
> .com
>
>
>
>
>
> 06/16/2003
> 11:17
>
> PM
>
> Please respond
> to
>
> Alan
> Benjamin
>
>
>
>
>
>
>
>
>
> >Sorry for post again, as I know many of us very confuse on the ISDN timers
> >and would like to know (include me :->):
> >
> >1) What is the different between "dialer enable timeout" and "isdn
> >fast-rollover delay"? it seems both are concerning the interval to make
> >another new call after the old call torn down. What will trigger the above
> >timer?
>
>
>The "isdn fast-rollover-delay" is typically used to throttle outbound dial
>attempts when "dialer load-threshold" triggers an additional call. I've
>only used it when dialing BRI to BRI, in order to force a delay (in
>seconds) between dial attempts to overcome an issue with how a certain
>telco switch handled NI-1 compatibility.
>
>It is important to remember the process by which new calls are generated.
>Using legacy DDR as an example (which is what I was using at the time), you
>
>need to include two "dialer map" statements to accommodate the phone
>numbers associated with each B channel at the distant end. However, when
>"dialer load-threshold" triggers the second call, the "dialer map"
>statements are processed in order. This results in a call to the first B
>channel that is already busy--and, due to the legitimate call failure, the
>second "dialer map" kicks in. (I believe this behavior still exists, but
>haven't checked it in a while.)
>
>In my particular case, the remote telco switch would temporarily disable
>access to the second B channel while processing the first call attempt (to
>the first B channel where I was already connected). My router would then
>process the second call attempt, but it would arrive before the switch
>returned the second B channel to idle/available--and I would end up with a
>Q931 message to the effect of "no channel available." (It's been a long
>time.)
>
>I hope this helps to clarify the situation.
>
>Take care,
>
>
>Alan
>
>__________________________________
>
>Alan Benjamin, CCIE #11771
>Systems Engineer (AT&T Channel)
>Cisco Systems, Inc.
>499 Thornall Street, 8th Floor
>Edison, NJ 08837
>e-mail: abenjami@cisco.com
>office: 732-635-3083 cell: 732-742-2694
>pager: 800-365-4578 fax: 732-635-3099
>__________________________________
>
>at AT&T Middletown (A2-2D03)
>office: 732-420-6394
>__________________________________
>
>
>_______________________________________________________________________
>You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
__________________________________
Alan Benjamin, CCIE #11771
Systems Engineer (AT&T Channel)
Cisco Systems, Inc.
499 Thornall Street, 8th Floor
Edison, NJ 08837
e-mail: abenjami@cisco.com
office: 732-635-3083 cell: 732-742-2694
pager: 800-365-4578 fax: 732-635-3099
__________________________________
at AT&T Middletown (A2-2D03)
office: 732-420-6394
__________________________________
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:59 GMT-3