Gordon Rowell wrote:
> Hmm, I know quite a few who have no such restriction. People with
> "continuous" connections will typically want the link up ASAP, so yes
> it would need to be configurable.
>
> IIRC, the Australian charging regime is still:
>
> - $0.xx per call flagfall (xx =~ 20)
> - no further charges for local calls (i.e. untimed in most cases)
> - expect a redial every 2-3 days
Yes, we would only like this option over weekend....we have a
"call-more" service, where if you dial-up over weekend you x-amount no
matter how long you stay on-line.
The only problem, is that we try not to work over week-ends!
> So, a "continuous" connection works very well in Australia, _unless_
> you have misconfiguration at your end or the ISP end (yes, you need a
> second phone line - and most businesses can spring to that cost). In
> this case, things can get expensive as you continually _connect_ to the
> ISP and then get dropped by the authentication. One thing which would
> help here would be diald back-off in the event of continued failure.
>
> IIRC (and my memory is fuzzier here), the U.K. charging regime is:
>
> - #0.yy per call flagfall
> - charging boundaries at a, b, c, etc. minutes
> - longer calls are effectively cheaper per minute
>
> Other regimes have:
>
> - no per call flagfall
> - untimed local calls
>
Basic business hours here have a per call charge.
During business hours:
-pay for initial call
-pay per-minute there-after
-you pay the same per call no matter how long you connect
After hours:
-pay for initial call
-pay per-minute there-after
-call charge per-minute is less that business hours
So we don't want to be dialing every 5-10 minutes.
So we are getting charge heavily for every call that is initiated...
If the call only lasts 10 seconds, you still pay the full minute.
I tend to chose medium for my offset.... seems to be the best.
>>Would this be better suited to console-setup or the server-manager?
Personally, I feel it should be in the console-setup....as it is now.
> I'd prefer to think about the underlying configuration first and then
> decide where the configuration screens would live.
Regards
Brandon Friedman
Cell:083 408 7840
E-mail: [EMAIL PROTECTED]
www.bfconsult.co.za
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
