Call Hunting - If line in use

I’m trying to hunt through a bunch of extension if the line is in use.

Example:

Exten1
Exten2
Exten3
Exten4

If Exten1 is on the phone, and someone calls that exten, have it hunt to Exten2. If Exten2 doesn’t pick up, have it keep ringing.

Right now I do

exten => _.,1,Dial(SIP/Exten1) exten => _.,n,Dial(SIP/Exten2) exten => _.,n,Dial(SIP/Exten3) exten => _.,n,Dial(SIP/Exten4) exten => _.,n,Playtones(Busy)

If a call egresses from the asterisk to the endpoint it works perfectly, but some endpoints don’t report the channel as busy on outbound calls (ingress calls from the endpoint to the asterisk) and will accept a second call.

I was wondering if there was any way to check the status of the channel (see if its in use) and hunt the call based on that, not relying on the endpoint.

I was reading about Channel Status with AGI, but I’ve seen people have mixed experiences with it.

Or another way of doing it.

I know the optimal solution would be the endpoint report the channel as busy on a second call, but unfortunately not all endpoints do this (xlite for example)

Why not just set up a queue??

http://www.voip-info.org/wiki-Asterisk+call+queues

You could simply check the $DIALSTATUS variable after you call each station. (Details here: http://www.voip-info.org/wiki-Asterisk+variable+DIALSTATUS )

You could then execute other dial commands based on the result.

One thing to think about, is your SIP endpoints. Many can accept multiple incoming calls, and even if they’re limited to 1 line, they will do the SIP equivalent of “call-waiting” and at least be friendly to the incoming call. It won’t necessarily refuse the call attempt.

Returning a “busy” is a fairly special condition. It identifies a station that is not only in-use, it’s ignoring all of the other multi-tasking features that have been developed to get around that. (Things like voicemail, call-waiting, and three-way calling.)

You should look closely at your SIP endpoints to see what settings can be made on them to limit the number of simultaneous calls they will accept.

@Asteriskdude: Isn’t call queues more for like a call center application? Someone calls in, hits the queue until an operator is available? I need it to hunt through a bunch of extentions (that will be broken into analog channels to plug into a legacy PBX)

@Dufus: Checking $DIALSTATUS wouldn’t work because the endpoint is still accepting the call. I edited my context’s so that the first thing it does (even before checking for voicemail) is to check the huntgroup. It by-passes all the provisions to keep a Busy from happening (like you said, voicemail, call-waiting, three-way, ect) because I want a Busy if the line is in use. I’m trying to get this to work like traditional POTS huntgroup. (The call goes to the first line, if theres someone on it, it goes to the second, if someone is on it it goes to the third, ect ect until it finds an open channel)

I was able to get the endpoint to report back a 406 (“Busy Here”) when a second call comes down the line. It works, but it really bothers me to depend on the endpoint for routing decisions.

What I was hoping for is a way to incorporate the same type of info I get from “show hints” in the CLI into my dialing plan so if there is already a call, I’ll get a “InUse” or “Busy” response, if theres no call in progress I get an “Idle” ect. Kind of like querying the D channel of a PRI on a TDM circuit to get B channel states.

I tried ChanIsAvail, but I always get back a 0 for ${AVAILSTATUS} if the channel is registered and a 5 if it isn’t.

I would think there would have to be a way to check from within the dialplan the state of a channel and only send a call if the asterisk reports the state as Idle.

I was looking at incorporating groups into my dialplan, but that just seems like a pain.

Mind you, I’m using this Asterisk in a carrier environment (not a ITSP, but a normal CLEC), and will be delivered to the client as normal TDM lines.

We put in some type of circuit between us and the client (DSL, T1, Ethernet ect), and then install CPE that breaks the SIP channels into a POTS or PRI handoff (like an Adtran TA900).

Our next step will be to use a media gateway to convert the SIP calls into TDM calls and deliever PRI right to our customer [what ever happen to that DS3 card digium promised us?]).

I see your point about routing decisions based on the endpoints, but the alternatives aren’t much better. Like routing all of the voice streams through the asterisk box so it has awareness of the state of every call. (Not very practical.) Or setting a call-in-progress variable in the dial plan. (Hoping that there are never any lost messages that would unset the variable and allow the next call.)

VOIP is a connectionless system, so we have to deal with all of the idiosyncrasies. It’s not going to behave the same way TDM systems do, and many of the feature solutions created for TDM systems, (like station hunting) simply have no place in the VOIP world.

Additionally, the SIP message set remains a bit anemic. Until it’s beefed up with all of the possible challenge/response messages everyone wants, you’re going to have to make do…

I see what you mean dufus, and I guess I will just make do. It’s working now, so as long as the endpoint reports the 406 on a second call, I should be good.

One comment though. You said,

I don’t entirely agree with this. I’ve found VOIP as a great way to transport voice calls, not necessarily using VOIP as a benefit to the enduser, just a easier way to transport the voice calls to them. VOIP is a hell of allot more efficient at transporting voice calls then legacy TDM circuit switching and you get more bang for your buck putting IP and VOIP traffic over the same T1 then you would with separate Voice and IP T1’s or a Integrated T1 (which is the least efficient in my opinion).

Look at BT (British Telecom), they are overhauling their whole network to due pure VOIP transport for Voice calls, but still deliver the traffic as TDM to the customer.

For a new Voice carrier just building out their network, its allot more inexpensive (well once you get over the CALEA stuff) and efficient to transport all calls internally as VOIP then TDM. On the other hand, TDM still owns what…85% of the market at least? If you want a robust offering, with backwards support for legacy PBX’s, you have to build support for TDM features over VOIP.

I guess I should have been a bit more clear about my statement. :smile:

My point was simply that VOIP endpoints are designed to be vastly more functional than a single line telephone. Many of the past limitations of single line telephones, (such as being limited to a single incoming call) don’t exist in most VOIP endpoints.

So, the features and functions that were designed to get around the limitations of analog telephone lines tend to fit very poorly into a VOIP environment.

Here’s an example of what I mean:

Yesterday, if you wanted to be able to get 4 simultaneous incoming calls to a phone, you needed a key system, 4 incoming lines, and line hunting to move calls to an unused line. (That way you didn’t have to publish 4 different numbers. Just the first number in the group.)

Today you can simply buy a 4 line VOIP phone and accept 4 incoming calls from one system registration.

I realize that this may be a bad example, since you are trying to use line hunting for call distribution, and not multiple call consolidation, but it’s the point I was trying to make. The limitation doesn’t exist, so, the feature isn’t going to work the same way. Ironically, you ended up creating an artificial limitation to make your solution work.

We have to think differently when designing VOIP features and solutions, and not expect TDM features to work the same way when we try them out on VOIP systems. That’s likely to mean we’re going to have to rely more and more on the endpoints.

Point taken.

I guess thats why most carriers I work with keep the TDM guys as far away from the VOIP guys as possible :stuck_out_tongue:

dufus, thanks for taking the time in humoring me, it’s been much appreciated.