IPCC line Call-Waiting

[smallrain_2]

Hi,

The admin guide said busy trigger and max calls on ipcc extension should be assigned 1 and 2.

What would happen if they are default, which is 2 & 4, or higher number?

Thanks,

[jpsweeney77]

Heading out the door but I'll give you one scenario where Busy Trigger > 1 is bad news. Let's say the busy trigger is 2 and an auto-answer agent is talking to a customer. Someone could call their line directly and the 1st call would automatically be put on hold and the second call would be auto-answered.

Many different scenarios here but that's a big one.

[Jonathan Schulenberg]

Allowing a second inbound call to the line will most likely break reporting on that agent and possibly result in unexpected behavior system-wide. It puts you in a TAC-unsupported state as well.

The RmCm subsystem is monitoring the agent while they are on the ACD call. It is not expecting to see another inbound call to the agent through JTAPI monitoring on that line. This is the same reason why agents have fewer soft keys in their template: the subsystem doesn't expect those events and tends to break when they happen. That is frequently manifested as a "call stuck in queue" in the database.

Lastly, even if none of that happened, the subsystem will not offer the agent a second call anyways since they would be in a Talking state.

[geoff]

>"Heading out the door but I'll give you one scenario where Busy Trigger > 1 is bad news. Let's say the busy trigger is 2 and an auto-answer agent is talking to a customer. Someone could call their line directly and the 1st call would automatically be put on hold and the second call would be auto-answered. "

Ever the skeptic ... but is that really true?

I've never tried exactly that, but have a similar example.

Agent has two lines: CC line is auto-answer on headset, no call waiting; private line has no auto-answer, call waiting, Unity.

Agent is on a call on their private line and has left themselves in the ready state (naughty). Router delivers a call to an auto-answer line, but it does not auto-answer - it simply rings the line. That's how it works - I've seen it many times, and was pleasantly surprised it did this as I expected something worse.

So I would need to see a demo.

Regards,

Geoff

[jpsweeney77]

Geoff, I must confess that this was many years ago in the product infancy and have since always had that scenario in the back of my mind. It is certainly possible that this was changed at some point along the way. I always welcome an excuse to play in the lab so I'll report my findings when I get a minute to run through it.

In the example you reference, is the auto-answer enabled in both UCCE and the UCM line setting?

[geoff]

No auto-answer on the private line.

Regards,

Geoff

[Jonathan Schulenberg]

This is a UCM setting. Note that there is a Service Parameter that messes with the behavior of auto-answer. This could explain why you have a slightly different recollection (but would not play out as you described).

Alternate Idle Phone Auto-Answer Behavior Enabled

This parameter determines whether lines on an idle (not in use) phone that are configured for auto-answer will use the standard auto-answer feature behavior, or will use an alternate behavior defined by this parameter. The alternate behavior effectively disables auto-answer when a call is on hold or incoming because it allows users to choose whether to answer a call that is ringing on a line that has been configured for auto-answer. Valid values specify True (disable auto-answer when a call is on hold, a call is incoming or outgoing, or a call is connected) or False (do not change the standard behavior of the auto-answer feature, which means that calls will be auto-answered when the line is idle, ringing, or has a call on hold and not auto-answer when a call is connected or outgoing). This parameter proves useful in situations where a phone has been configured with multiples lines, one or more of which have the auto-answer feature configured. For example, a phone has two lines. Line 1 has been configured for Auto-Answer, line 2 has not. By setting this parameter to True, you disable the standard auto-answer behavior so that in the case where the user has a call ringing on line 2 and another call ringing on line 1, the user has the choice of whether to answer line 2 before answering line 1 (which would otherwise auto-answer, thereby eliminating any choice on the user's part). If this parameter was set to False, in the same scenario, line 1 would always auto-answer and the user would not have the opportunity to answer line 2 first.

This is a required field.

Default: False

[geoff]

Well done, Jonathan - that's exactly right. I knew I did something else. The default of "false" is not the best for a contact center environment.

Regards,

Geoff