Dialup congestion and winter weather (fwd)
An important question to ask people reporting this type of problem is are they getitng a normal busy (all modems busy) or a fast busy (telco out of circuits). Two very different problems. An ISP can work on fixing the first, but the second is a telco with a shortage of circuits between the customer and the isp.
It seems like a lot of people are at home, dialing into the Internet today. There is a major ice storm in the middle of the country, and its pretty much a holiday week elsewhere. Traffic seems to be moving on the major backbones, but some folks in the midwest report some problems dialing in from home.
-- Richard Shetron multics@ruserved.com multics@acm.rpi.edu NO UCE What is the Meaning of Life? There is no meaning, It's just a consequence of complex carbon based chemistry; don't worry about it The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.
Also sprach multics@ruserved.com
An important question to ask people reporting this type of problem is are they getitng a normal busy (all modems busy) or a fast busy (telco out of circuits). Two very different problems. An ISP can work on fixing the first, but the second is a telco with a shortage of circuits between the customer and the isp.
Maybe, maybe not. In the pretty common case of an ISP fed by ISDN PRI, its been our experience that once all of the channels on all of the available PRI to the ISP are in use, the telco will generate an all circuits busy type of response as the PRI are trunk-side, so the switches typically treat them as inter-switch trunks being filled, not end lines to the ISP being full. The end result being that an end-user can't always tell if a fast-busy indicates a telco problem or a capacity problem at the ISP. The work-around available to the ISP is to set the last line/channel (assuming you're using a first-available type of hunt rather than a circular or something else) to reject calls with a cause code of 17 (User busy) which will generate a normal user busy signal when the rest of the trunks are full. How you do this on your RAS equipment is implementation independant of course. If anyone is interested, I can give pointers to do this on 3Com Total Control chassis.
It seems like a lot of people are at home, dialing into the Internet today. There is a major ice storm in the middle of the country, and its pretty much a holiday week elsewhere. Traffic seems to be moving on the major backbones, but some folks in the midwest report some problems dialing in from home.
We've, for a long time, tried to add whatever extra service we could right before bad winter weather approached. I remember one time, several years ago, I added a tenth again of our then-current hunt-group size of modems to our hunt group in anticipation of snow that night. We filled those lines that night when we had not be filling the lines before that capacity was added. So...winter weather spikes in usage have been around for a while...and it makes sense...you've got greater difficulty getting out and about, so many people take the path of least resistance and play about online. *shrug* -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Jeff Mcadams writes:
its been our experience that once all of the channels on all of the available PRI to the ISP are in use, the telco will generate an all circuits busy type of response as the PRI are trunk-side, so the switches typically treat them as inter-switch trunks being filled, not end lines to the ISP being full.
As always YMMV. The result is affected to a great extent by provisioning. Which is obvious and yet hasn't been mentioned. One way causes a call setup request to be sent even though the switch knows that there are no available B channels, which permits the terminal to make it's own decision as to the disposition of the call, e.g., refuse it with cause code 17 which _should_ cause some switch in the call path (the originating one usually) to generate a normal busy tone.
Also sprach Mark Milhollan
Jeff Mcadams writes:
its been our experience that once all of the channels on all of the available PRI to the ISP are in use, the telco will generate an all circuits busy type of response as the PRI are trunk-side, so the switches typically treat them as inter-switch trunks being filled, not end lines to the ISP being full.
As always YMMV. The result is affected to a great extent by provisioning. Which is obvious and yet hasn't been mentioned.
I'll buy "YMMV", but I've never run into this situation, and I'm a bit skeptical.
One way causes a call setup request to be sent even though the switch knows that there are no available B channels, which permits the terminal to make it's own decision as to the disposition of the call, e.g., refuse it with cause code 17 which _should_ cause some switch in the call path (the originating one usually) to generate a normal busy tone.
OK...so...if I have 20 PRI spread across 10 pieces of RAS equipment, and thus, consequently at least 10 D channels (more likely 20 since NFAS is a pain to manage IMO), which D channel is the setup request sent to? My understanding is that the switch will typically find a B channel that's unused, and send the setup request down the corresponding D channel. If no B channels are unused, then the switch would have no way of knowing which D channel to pick to send the setup request. I certainly won't say that there aren't provisioning setups that would do this correctly, but it would be beyond my knowledge as to how that would be set up, that's for sure. Now, if you're using SS7, or SIP or something like that...all bets are off, I've never worked with them, so have no knowledge of how they work. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
participants (3)
-
Jeff Mcadams -
Mark Milhollan -
multics＠ruserved.com