I know this question has been raised and I have spent a great deal of time reviewing the posts to see if anyone has solutions that I have not already checked. We are a Nortel Partner, now Avaya and develop third party software as PC Based Attendant Consoles. With our software we provide a logging feature that captures all messages between the PC, the M2250, or PCCIU, and the PBX. In our logging messages, I do get a set Lamp "BUSY" which we react to. I am extremely familiar with how the Busy/ Night works and how the handsets and headsets may play a role in the activation. From a PBX programming perspective, would there be anything that might do this, e.g. AFNT/ AFBT or others.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
M2250 goes into Position Busy unexpectedly
- Thread starter 1911
- Start date
The only things that I know of that will put a console in Busy are:
~~If another Operator puts their console into Night, then takes theirs back into Day - the remaining consoles will be in Busy.
~~If a headset is disconnected, unplugged, or otherwise turned off, the console may go into Busy.
~~If the console is unplugged, disabled, etc.
There is no CLS or programming value that results in the console going into Pos Busy.
--
Nortel Resources at GHTROUT.com | Connect with me on LinkedIn
--
~~If another Operator puts their console into Night, then takes theirs back into Day - the remaining consoles will be in Busy.
~~If a headset is disconnected, unplugged, or otherwise turned off, the console may go into Busy.
~~If the console is unplugged, disabled, etc.
There is no CLS or programming value that results in the console going into Pos Busy.
--
Nortel Resources at GHTROUT.com | Connect with me on LinkedIn
--
- Thread starter
- #3
I have thought of all of those and check all, but may somehow the customer has intermittant power. I understand that if the Attendant Forward No Answer Timer and Attendant Forward Busy Timer is configured, if the console goes idle for a specific period. it will go into Position Busy. I'm checking that as well, but was wondering if there might be anything else. You're not familiar with anything. Thanks, I appreciate the feed back. If and when I solve, I'll Post.
tnphoneman
Vendor
I believe that a supervisor console can also put all consoles into the night mode. Don't have the books in front of me.
Signature==========================================
XtremeMaintenance.com
XtremeSeoConsulting.com
Signature==========================================
XtremeMaintenance.com
XtremeSeoConsulting.com
Any console can put all consoles in Night - it sucks
--
Nortel Resources at GHTROUT.com | Connect with me on LinkedIn
--
--
Nortel Resources at GHTROUT.com | Connect with me on LinkedIn
--
- Thread starter
- #6
Not to be too simple here but we have had to replace the handset and/or cables before due to loose connections. I spent a lot of time looking at other stuff before I checked cables and it ended up being that - so lesson learned for me a few years ago was start with the basics. I used to start looking at programming and things of that nature. I agree it could be a power issue too.
- Thread starter
- #8
You might want to troubleshoot each console individually, as the problems they are having could be different issues for each one. One issue we have had in the past, is that the prongs on the headset adapter get "dirty". Cleaning them has cured several issues similar to what you describe. If you have Amphenol connectors, make sure they are tight and in good shape. If you have headsets and use the bases, not just a direct connection, make sure the batteries are not getting weak.
- Thread starter
- #10
Again, thanks for the insight, but because we ate a Nortel/ Avaya partner and develop third party software for use with the M2250 and PCCIU, we have a logging file that captures all the messages which travel from the PBX, M2250 and PCCIU to the PC that has our software. If a Busy or Night is depressed, we see the message, if a handset is disconnected purposely or by an intermittant connection, we see a specific message, and if the devices are powered down purposely or intermittantly, we'll see a message. At this point none of that is occurring. What we are seeing is a transmitted message from the switch which we get as a Receive message to go to Position Busy. That's why I was looking for something that might be occurring from the switch possibly because something isn't programmed correctly or we are unaware of. Thanks.
We do not use night service on the consoles here, anyone know how that would affect the consoles? Not sure if it puts the consoles in to nights or if it just reroutes calls prior to them getting to the consoles. Does not seem to me that would cause intermittent issues unless there are 3 listings for night service, and I do not know if that is even possible.
- Thread starter
- #12
We don't see a lot of Night use either, busy into Night as the operators leave for the day or it's a 24 hour operation. What we see with our logging is if they are using our software package and an operator presses the Night, a xmit key depression for Night occurs, then a set lamp busy on, then set Night lamp on, all other consoles then get a set lamp busy on, then set lamp Night on. When Night gets pressed again to come out, a xmit Night key depression occurs then a set busy lamp off, set lamp Night off, but all other consoles get essentially a set lamp busy on until they come along by pressing a key to xmit a busy off. So if we're looking at messages from one console that has a set busy lamp that doesn't coinside with a key depression we'll track it down by reviewing the other consoles log file to see if it corresponds.
I read your post about 3 times now and it seems like your situation is referring to what GHTROUT already posted:
~~If another Operator puts their console into Night, then takes theirs back into Day - the remaining consoles will be in Busy.
So yes only 1 of your consoles will show the key depression while your other consoles will remain in busy until someone comes along to press the key. Is that your issue? Or can you explain it differently because that is what it sounds like you are talking about (to me at least).
~~If another Operator puts their console into Night, then takes theirs back into Day - the remaining consoles will be in Busy.
So yes only 1 of your consoles will show the key depression while your other consoles will remain in busy until someone comes along to press the key. Is that your issue? Or can you explain it differently because that is what it sounds like you are talking about (to me at least).
- Thread starter
- #14
The issue is there are only certain conditions that are required for a console to go into PB. You select the Busy button or someone puts the console in night then thake them out of night, all consoles go to busy. There are messages that travel between the PCCIU and the switch that confirm those conditions. The problem is although it seems to be going into Busy because someone put in in night then removed it, but the messages are NOT there to support that. If the messages were there, then on that console, I would first see a message telling the console to go to night. then I would see a message taking it out of Night and putting it in busy.What I'm getting is The console will be idle, no Night mode, then this console with just get a message to go busy.
Right which that makes sense to me because someone puts console 1 in night so consoles 2 and 3 go to night (busy) but then someone takes console 1 out of night but consoles 2 and 3 will remain in night (which means no messages between the PCCIU and the switch) UNTIL someone comes and presses night again on console 2 or 3 to remove the 'busy'.
At least that is my interpretation of what GHTROUT was saying - maybe I am wrong. I don't have enough console experience to tell you one way or the other. Just trying to make sense of this for everyones sake. Is the above assessment true? I assume you want messages to show for your PCCIU for console 2 and 3 but the reality is that you aren't going to have any messages based on the design of the console night operation and its messages to the switch, right?
At least that is my interpretation of what GHTROUT was saying - maybe I am wrong. I don't have enough console experience to tell you one way or the other. Just trying to make sense of this for everyones sake. Is the above assessment true? I assume you want messages to show for your PCCIU for console 2 and 3 but the reality is that you aren't going to have any messages based on the design of the console night operation and its messages to the switch, right?
- Thread starter
- #16
I believe I we have it figured out. It really helps if the customer provides you with the correct information and of course follows the required rules.
If you have an M2250 which has keys, every key depression send a message to the switch and the switch acks back with confirmation, e.g. You press Loop 0, message goes out and one comes back to light up the arrow and gives you an open loop.
With the PCCIU, it's the same, but the messages are initiated from a PC keyboard mapped to the same feature or Loop. With our software we see all those messages.
So, by reviewing all the messages we can determine exactly what activity is occurring on each console.
If Console 1 presses the Night key we see a xmit then a confirmation to set the system Night from the switch by receiving a set busy on, set night on. On Console 2 you would not get a xmit, but you do get a set busy on, set night on. It doesn't get an xmit because console 2 didn't perform the action, it's just responding.
If all Consoles are in Busy except one and it then presses the Busy, you see the xmit Busy, then a busy on, Night on message, while the other consoles just get the busy on, night on. When a console takes the system out of Night, you see the night xmit, which then gets a confirmation busy off night off, but the other consoles get a message that says night off busy on. Then as the operators want to take them out of bust you see there xmit Busy then a confirmation of busy off.
We all understand how it works and in our customers case all those messages are occurring according to protocol, but where the problem lies is out of the blue, they'll receive a busy on confirmation from the switch that doesn't coinside to any message sent by that console or any other console.
The problem lies at the version of the PCCIU. Version 09 or less sends a polling message to the PC/ Nortel PC Console software confirm it's availability. The PC console software responds. If not it thinks the console is out of service and will put it in Busy. the Newer Third party softwares made don't ack back to that message so the consoles would go into Busy at first, but then Nortel took the Polling message out in PCCIU versions 10 or later. So if a customer is using the PC Console software, they need a PCCIU version of 09 or less. If they are using most other third party software apps, they'll need the version 10 or greater. So, in a nut shell the customer has the wrong version of PCCIU to work with our software. We jus couldn't ever get them to tell us that. Thanks again.
If you have an M2250 which has keys, every key depression send a message to the switch and the switch acks back with confirmation, e.g. You press Loop 0, message goes out and one comes back to light up the arrow and gives you an open loop.
With the PCCIU, it's the same, but the messages are initiated from a PC keyboard mapped to the same feature or Loop. With our software we see all those messages.
So, by reviewing all the messages we can determine exactly what activity is occurring on each console.
If Console 1 presses the Night key we see a xmit then a confirmation to set the system Night from the switch by receiving a set busy on, set night on. On Console 2 you would not get a xmit, but you do get a set busy on, set night on. It doesn't get an xmit because console 2 didn't perform the action, it's just responding.
If all Consoles are in Busy except one and it then presses the Busy, you see the xmit Busy, then a busy on, Night on message, while the other consoles just get the busy on, night on. When a console takes the system out of Night, you see the night xmit, which then gets a confirmation busy off night off, but the other consoles get a message that says night off busy on. Then as the operators want to take them out of bust you see there xmit Busy then a confirmation of busy off.
We all understand how it works and in our customers case all those messages are occurring according to protocol, but where the problem lies is out of the blue, they'll receive a busy on confirmation from the switch that doesn't coinside to any message sent by that console or any other console.
The problem lies at the version of the PCCIU. Version 09 or less sends a polling message to the PC/ Nortel PC Console software confirm it's availability. The PC console software responds. If not it thinks the console is out of service and will put it in Busy. the Newer Third party softwares made don't ack back to that message so the consoles would go into Busy at first, but then Nortel took the Polling message out in PCCIU versions 10 or later. So if a customer is using the PC Console software, they need a PCCIU version of 09 or less. If they are using most other third party software apps, they'll need the version 10 or greater. So, in a nut shell the customer has the wrong version of PCCIU to work with our software. We jus couldn't ever get them to tell us that. Thanks again.
- Status
Similar threads
- Locked
- Question
