jamesd@techbook.com (James Deibele) (11/03/90)
I would like to set up a sequence whereby someone calling number X
would start at the top of a group of phone lines. These would be
given out to 2400 baud callers. Number Y would be given out to people
who wanted to use Telebits, and would be part of that same sequence.
(So people with 2400 baud modems would fill up the 2400 baud modems
before falling through to the Telebits.)
This seems reasonable to me. However, experimenting with my current
hunt group, it seems that if I call any other number besides X, I will
get a busy signal or a ring for that one line only --- in other words,
if I call X+1 and it's busy, I will not get X+2. Is this a reasonable
conclusion, or have I somehow made a mistake while testing? (I've
done testing where I could see the modems as I was dialing, to see if
they were all really busy.)
I have GTE phone service, but I'm afraid I don't know what the local
switching equipment is. It seems as those there can be only one
"magic number" on a hunt group, but I'd really like to be told I'm
wrong ...
jamesd@techbook.COM ...!{tektronix!nosun,uunet}!techbook!jamesd
Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503 646-8257
"Sitting on the console all day, watching the news scroll away ..."William.Degnan@f39.n382.z1.fidonet.org (William Degnan) (11/05/90)
>This seems reasonable to me. However, experimenting with my >current hunt group, it seems that if I call any other number besides X, I >will get a busy signal or a ring for that one line only --- in other >words, if I call X+1 and it's busy, I will not get X+2. Is this a >reasonable conclusion, or have I somehow made a mistake while testing? You have made a natural error while testing. It seems that you can't test hunting from a server within the hunt group. If you call from a line that is not part of the hunt group, it should perform as expected. Perhaps the designers never thought we'd want to call ourselves to check translations? Disclaimer: Contents do not constitute "advice" unless we are on the clock. William Degnan | wdegnan@mcimail.com Communications Network Solutions | !wdegnan@at&tmail.com -Independent Consultants | William.Degnan@telemail.com in Telecommunications | UUCP: ...!natinst!tqc!39!William.Degnan P.O. Drawer 9530 | ARPA: William.Degnan@f39.n382.z1.FidoNet.Org Austin, TX 78766-9530 | Voice +1 512 323 9383
vances@xenitec.on.ca (Vance Shipley) (11/05/90)
In article <14273@accuvax.nwu.edu> James Deibele <jamesd@techbook.com> writes: >if I call X+1 and it's busy, I will not get X+2. Is this a reasonable >conclusion, or have I somehow made a mistake while testing? One common mistake made when testing hunt groups is to use a member of the hunt group to make the test calls. If you call line X from line X you will get a busy, it will not hunt. vance [Moderator's Note: I don't think you are correct. I think anywhere you enter the loop if that line is busy (i.e. you are in fact calling from it) the incoming call will continue forward in the hunt group. The exception would be as Mr. Levenson points out in the next message. PAT]
dave@westmark.westmark.com (Dave Levenson) (11/05/90)
In article <14273@accuvax.nwu.edu>, jamesd@techbook.com (James Deibele) writes: > I would like to set up a sequence whereby someone calling number X > would start at the top of a group of phone lines. These would be > given out to 2400 baud callers. Number Y would be given out to people > who wanted to use Telebits, and would be part of that same sequence. > (So people with 2400 baud modems would fill up the 2400 baud modems > before falling through to the Telebits.) > if I call X+1 and it's busy, I will not get X+2. I think your present hunt group is arranged for night service. With that option, callers to numbers other than the first one don't hunt. It is typically used on PBX trunk groups. During the day, the whole group is answered by the PBX attendant. At night, each trunk is hard-wired to a specific station. Night callers are given the night number associated with a station. If the station is busy, they don't hunt to another station. Your local telco can probably re-arrange the hunting to do what you want. Dave Levenson Internet: dave@westmark.com Westmark, Inc. UUCP: {uunet | rutgers | att}!westmark!dave Warren, NJ, USA AT&T Mail: !westmark!dave [The Man in the Mooney] Voice: 908 647 0900 Fax: 908 647 6857
TERRY@spcvxa.bitnet (Terry Kennedy, Operations Mgr) (11/05/90)
In article <14335@accuvax.nwu.edu>, our Moderator writes: > [Moderator's Note: I don't think you are correct. I think anywhere you > enter the loop if that line is busy (i.e. you are in fact calling from > it) the incoming call will continue forward in the hunt group. The > exception would be as Mr. Levenson points out in the next message. PAT] I know of several methods of setting up "hunt groups". Not all of these are available on all switches: o Single-entry hunt - A single number is used to enter the hunt group, with the remaining numbers not hunting. On older (step-by-step) gear, the additional numbers may not even be directly dialable. o Linear hunt - The group may be entered on any of it's members. If all lines from the entry one through the end are in use, a busy signal is issued (the group does not loop back to the front). o Circular hunt - like linear, but it will loop from the tail to the head if necessary. o Call Forward Busy - If the line is busy, calls are forwarded to another number. On switches which allow recursive forwarding, one can construct large hunt groups this way. o Call Forward Busy / No answer - Adds the ability to hop to another line if one of the numbers doesn't answer. o Automatic Call Distributor - Calls to a single number are routed pseudo- randomly to various numbers in the modem pool. Some of these are only useful for _large_ pools of numbers (ACD), while others don't scale well to larger groups (CFB, CFB/NA). Again, depending on the switch, you may not be able to verify the hunt from within the group. Also, if you've ordered a two-line hunt group, or find one, it may be set up CFB rather than true hunt, especially if the customer has other features on the line, like 3W calling, speed dial, etc. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, US terry@spcvxa.spc.edu (201) 915-9381
dave@westmark.westmark.com (Dave Levenson) (11/05/90)
In article <14335@accuvax.nwu.edu>, vances@xenitec.on.ca (Vance Shipley) writes: > One common mistake made when testing hunt groups is to use a member of > the hunt group to make the test calls. If you call line X from line X > you will get a busy, it will not hunt. This is not always a mistake. When I had a two-line hunt-group in Summit, NJ, (we were then served by an elderly 5-crossbar switch, 201-273 for those who care) that was the case. Hunting did not work if the call was originated within the hunt-group. In the 1AESS which later replaced the 5-crossbar switch, hunting did work when the call originated within the group. I don't know whether this is a 'feature' of 5-crossbar, or a translation option that happened to be changed along with the massive changes that accompanied the CO cutover (back in about 1980, as I recall). Dave Levenson Internet: dave@westmark.com Westmark, Inc. UUCP: {uunet | rutgers | att}!westmark!dave Warren, NJ, USA AT&T Mail: !westmark!dave [The Man in the Mooney] Voice: 908 647 0900 Fax: 908 647 6857
lars@spectrum.cmc.com (Lars Poulsen) (11/08/90)
In article <14367@accuvax.nwu.edu> William.Degnan@f39.n382. z1.fidonet.org (William Degnan) writes: > It seems that you can't test hunting from a server within the hunt > group. ... > Perhaps the designers never thought we'd want to call ourselves to > check translations? As has been noted already, this varies. This is not a bug, it is a feature. It allows you to test the individual lines of the group by calling each one in turn. When I first encountered hunt groups, in a modem pool, in a foreign country, many years ago, only the lead number would hunt; the subordinate numbers behaved normally. Thus, you could test all numbers except the lead number. Disabling the hunt for calls originating within the group is a simple way of achieving this test capability (although it would seem to require a bit of computer processing to implement). Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
jamesd@techbook.com (James Deibele) (11/09/90)
In article <14366@accuvax.nwu.edu> TERRY@spcvxa.bitnet (Terry Kennedy, Operations Mgr) writes: >In article <14335@accuvax.nwu.edu>, our Moderator writes: >> [Moderator's Note: I don't think you are correct. I think anywhere you >> enter the loop if that line is busy (i.e. you are in fact calling from >> it) the incoming call will continue forward in the hunt group. The >> exception would be as Mr. Levenson points out in the next message. PAT] > I know of several methods of setting up "hunt groups". Not all of >these are available on all switches: Thanks for an informative posting on hunt groups. Unfortunately, it seems that GTE has what you described as "single-entry hunt" where there's only one number per hunt group and the rest of the numbers can't hunt. Or that's what GTE tells me this time. I think I'll call back and talk to one or two more people to make sure that's correct. It would be nice if there was a "wizard" number that you could call and find out whether something was technically feasible or not. I have this nagging feeling that there's probably a way of doing what I want, but that the first- line people aren't used to handling things that way. They do have a "call when busy" feature (if number X or Y or Z is busy, call number A), but it's several dollars a line per month while the hunt group is free. Thanks to the people who suggested possible problems when calling from within the hunt group. That wasn't the situation in this case (I was calling from another phone line), but I confess that I never would have thought of such a thing as causing a problem. Public Access UNIX (503) 644-8135 (1200/2400 N81) --- Read alt.books.technical
BRUCE@ccavax.camb.com (Barton F. Bruce) (11/10/90)
In article <14335@accuvax.nwu.edu>, vances@xenitec.on.ca (Vance Shipley) writes: > One common mistake made when testing hunt groups is to use a member of > the hunt group to make the test calls. If you call line X from line X > you will get a busy, it will not hunt. You may have observed this on a #5 x-bar. The LDN, even, dialing itself will get a busy, so it is not a night answer issue in this case.
john@bovine.ati.com (John Higdon) (11/11/90)
James Deibele <jamesd@techbook.com> writes: > Or that's what GTE tells me this time. I think I'll call > back and talk to one or two more people to make sure that's correct. > It would be nice if there was a "wizard" number that you could call > and find out whether something was technically feasible or not. Even if GTE set up a "wizard" line, the information that would be dispensed would be misleading, harmful, and just plain wrong. As you have already discovered, the temptation with GTE is to use the "mass action" theory which holds that if you make enough inquiries and average the responses, the answer that emerges will approach the truth as the number of attempts approaches infinity. Not true. It is a bad theory when applied to GTE. It is likely that NONE of the responses obtained from GTE personel bear any resemblance to reality. From personal experience it is possible to say that if you want to determine anything about GTE's system, you will have to use a back door approach. It is necessary to befriend a sympathetic employee who will give you the straight poop. But it is a one-shot affair; usually such a person goes on to work for a real company before you get a chance to pick his brain again. John Higdon | P. O. Box 7648 | +1 408 723 1395 john@bovine.ati.com | San Jose, CA 95150 | M o o !