Hi,
Does anyone know where I can configure the number of lines allowed for each extension.
Currently, I am using XLite + Asterisk. If my XLite is having one active call, he is not able to take the new call unless he drops the existing active call. Even if Xlite puts the active call to hold, he still not able to see the new call, becuase Asterisk is keeping on telling “the user is on the call, please leave a message…”
Thanks
That would be a limitation of the X-lite, not of Asterisk. I’ve used softphones with the ability to have more than one line on the go at once, and had no problem. I don’t know the X-lite, but i guess it’s just not capable of it.
The interesting is that I can make multiple outbound calls from XLite. I am thinking if the restriction is really at XLite, I should be restricted for the outbound too.
But what you said also makes sense. Because the client side must indicate how many lines he can support. And I just found out that I am indeed using XPro which has multiple lines. But it is the same behavior that only one inbound call is allowed.
Well, does anyone have such experience in this subject.
interesting that you have a multi line phone that is returning a busy - we are using Eyebeam 1.10 as our primary phone for our agents, and we are continually having issues with multiple calls being delivered to agents when they are already on a call. This is especially problematic for our queue agents, as they were getting two or three calls at once because * didn’t recognize they were on a call - it was sending the next customer in line to their second or third line.
I know that incominglimit and outgoinglimit used to be the way to set this, but they have been deprecated, and I can’t get an answer from anyone on how the queue app actually works and checks for multiple calls.
If you want to chat about this more, I’d love to find out your exact config, because what you have is what we want, at least partially.
Thanks,
Wes
Thanks, I hadn’t seen those posts before.
Unfortunately, we have tried incominglimit/outgoinglimit (both of which are server-centric, not user centric, so incominglimit actually limits the number of calls incoming to the server from the user, not the other way around. outgoinglimit is what would limit the number of calls sent from the server to the agent, but it is VERY deprecated and to my knowledge never worked right). We also utilized SetGroup/CheckGroup which works pre 1.2, and the new GROUP/GROUP_COUNT functions in 1.2.
None of the above solutions works in the queue environment. I’m assuming this is because the queue application uses a separate call handling algorithm (it doesn’t use a standard context) and thus there is no way of defining a call limit, etc, for multi-line phones.
I did read a post to the Asterisk-dev mailing list where a user had patched the queue source code to include a SetGroup/CheckGroup, but I have been unable to proceed further.
It actually is a missing feature or at least an oversight the queue application, though - if you consider what a queue is supposed to do, then having logic where multiple calls are routed to agents already on calls points to a flawed logic, at least in my mind. Note that we are using dynamic agents through the AddQueueMember/RemoveQueueMember functions. This is because our managers need to be able to take people in and out of queue, and to do this, we are using the AsteriskGuru Operator Panel, as well as extensions the users can dial to take themselves in and out of queue. We are big enough (~350 seats across 7 internal divisions) that we need such tools to keep track of what is going on.
Another interesting thread about this issue:
asteriskguru.com/archives/sv … iple+calls
In any case, I am still searching for the perfect solution to this problem. A single line phone works great, but we haven’t found one that is acceptable for our needs, and our users will need to change the number of available lines throughout the day based on call load, etc - we have a very complicated environment here and working around it can suck.
In any case, thanks for the input, and if anyone has any further suggestions, I’d love to hear them!
Wes
I agree with your comments regarding the logic flaw of having multiple calls to a single agent. It simply shouldn’t be done. One agent simply can’t talk to more than one person at a time. I’m interested in the queueing functionality but haven’t looked into the details much yet.
I currently manage an Avaya S8500 and have managed many other ACD environments in the past and having multiple calls to an agent has never been something anyone wanted. What the have wanted (and I think lots of people do whether in an ACD environment or not) is to be able to become aware of the next caller in ways such as: 1) the fact they exist at all; 2) who they are. This information allows the agent to make a priority decision around whether to wrap the existing call.
Is it possible the * environment is delivering multiple calls to individual agents based on the agent being part of multiple skills? Again I haven’t dug into the queueing capability yet but otherwise can’t understand why the system would send more than one call.
[quote=“whoiswes”]Thanks, I hadn’t seen those posts before.
Unfortunately, we have tried incominglimit/outgoinglimit (both of which are server-centric, not user centric, so incominglimit actually limits the number of calls incoming to the server from the user, not the other way around. outgoinglimit is what would limit the number of calls sent from the server to the agent, but it is VERY deprecated and to my knowledge never worked right). We also utilized SetGroup/CheckGroup which works pre 1.2, and the new GROUP/GROUP_COUNT functions in 1.2.
None of the above solutions works in the queue environment. I’m assuming this is because the queue application uses a separate call handling algorithm (it doesn’t use a standard context) and thus there is no way of defining a call limit, etc, for multi-line phones.
I did read a post to the Asterisk-dev mailing list where a user had patched the queue source code to include a SetGroup/CheckGroup, but I have been unable to proceed further.
It actually is a missing feature or at least an oversight the queue application, though - if you consider what a queue is supposed to do, then having logic where multiple calls are routed to agents already on calls points to a flawed logic, at least in my mind. Note that we are using dynamic agents through the AddQueueMember/RemoveQueueMember functions. This is because our managers need to be able to take people in and out of queue, and to do this, we are using the AsteriskGuru Operator Panel, as well as extensions the users can dial to take themselves in and out of queue. We are big enough (~350 seats across 7 internal divisions) that we need such tools to keep track of what is going on.
Another interesting thread about this issue:
asteriskguru.com/archives/sv … iple+calls
In any case, I am still searching for the perfect solution to this problem. A single line phone works great, but we haven’t found one that is acceptable for our needs, and our users will need to change the number of available lines throughout the day based on call load, etc - we have a very complicated environment here and working around it can suck.
In any case, thanks for the input, and if anyone has any further suggestions, I’d love to hear them!
Wes[/quote]
Never thought about the skills, but since we’re using totally dynamic agents (there are no agent or member declarations in either agents.conf or queues.conf) I wouldn’t THINK that would be a problem with us…
It seems as though *@home 2.1 has call waiting/multiple lines turned OFF by default, which is different that previous versions. I’d be interested in knowing what changed or how they were able to acheive that, because that’s exactly what we’re looking for.
In any case, I’m still searching - hopefully one of the gurus around here can shed some light on what we might do to fix this, because while it’s not a show-stopper, it is an annoyance and has put our entire migration on hold - we’re not rolling out any more * boxes until we have a permanent fix in place.
Thanks for the input!
Wes
You may use busy level option in sip.conf to resolve this issue .
I would hope he figured it out sometime in the last 12 years 
You might want to check the date of posts you reply to.
Might be some one else looking for the same be positive. Always…