This seems like a simple query but I can’t find any workaround, options etc that might help!
Firstly setup details: SIP Server 8.1, Interaction Workspace 8.1.3.
Basically when agents are in some not ready status (ACW or other), they obviously don’t receive any customer calls via URS.
But they can still call each other and potentially transfer customer calls, even though they are not ready.
Can this be controlled so that internal calls are also blocked if the agent is not ready?
All business calls are blocked if an agent is in NotReady state. So,try to set inbound calls as a business (TServer configuration/option)
I already tried setting inbound-bsns-calls, outbound-bsns-calls and internal-bsns-calls to true.
The only one that had any effect for this scenario was internal-bsns-calls, but the only effect was that it put the agents into ACW after the call - it still allowed the call to be made…
What do you want? Agent cannot call if he is in NotReady state or cannot receive calls in this state?
What I’d like is that if the receiving agent is in Not Ready then the calling agent should not be able to place a call to them.
In theory the consultation call is a business call…so shouldn’t be shown at the GAD for transfering (if you enabled GAD for showing only available agents) (and if you are using GAD)
The calls are SIP, if somebody sends an INVITE to the other extension SIP Server doesn’t do any routing validation on that moment…unless they have a feature like that but never read it
have you tried option reject-call-notready?
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
When set to true, a call attempt to a DN at which an agent is in a Logout,
NotReady, or AfterCallWork state will be rejected, and the Invalid
Destination State (93) error message will be generated.
there is another one useful option - reject-call-incall, sometimes customers ask us about this ability as well…
Perfect, thanks - exactly what I was looking for!
:o interesting…
I need to read the last documentation completely again…
Yeah I completely missed it in the deployment guide as well - should have searched for “reject”!