External Calls going to the Attendant Console

[jarruda]

Hi folks,

I have two scenarios (that seems to be related) that I want to change but not sure how to.

Case 1: An external call is received by a Trunk Circuit (E1-R2) with a busy analog extension as destination. The analog extensions hear the call waiting tone for some seconds and after a period of time the external call is redirected to the Attendant Console.

Case 2: An external call is received by a Trunk Circuit (E1-R2) with a non-busy analog extension as destination. The analog extensions rings and the call is answered. The analog extension initiate a "blind" transfer to another non-busy extension. The new extension rings several times but no one answer this call. The external calls then goes back to the original called extension. This extension will ring for some seconds and after a period of time, if no one answer it, the external call is redirected to the Attendant Console.

Not sure what is the feature that is creating this behavior (Recall or Intercept maybe) and how to disable it.

Can anyone help me?

 

[tampasteve1]

It sounds like calls are being routed to the attendant if they are not answered. If a call is not answered after a certain amount of time (programmable) it goes somewhere, usually the attendant or voice mail. I believe that it could be changed to ring forever if that is what is desired.

 

[donb01]

Considering we're in the Hicom forum, I'll assume your on a 4000, since you didn't say.

In Case 1, there is a parameter on the Basic 3 tab alled "Delayed CFW on Busy". Make sure that is not checked, and then if the extension is busy the caller will get a busy signal.

In both cases, have you tried setting up system call forwarding on the extensions so they go where you want them to if they are busy or not answered?

 

[jarruda]

Hi, sorry I forgot to mention, this is on a Hipath 4000 system.

There is no call forwarding (unconditional, busy or not answered) at all configured on this extension so it might be something else that is getting the external call on both cases and sending them to the Attendant Console.

 

[jarruda]

Found another clue.
Looking at the AMO VFGR i found that my Attendant Console Group have the following config:
| IS INTERCEPT DESTINATION FOR THE FOLLOWING ITR GROUPS |
| 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |

As its impossible to delete the ITR group 0 (the one my extensions and external trunk are using) from it, as a test I created another Attendant Console Group using the AMO VFGR with a fake/invalid number and set it as the INTERCEPT DESTINATION for ITR GROUP 0.

With this config, both Case 1 and Case 2 scenarios will result in a busy signal when the call is supposed to be sent to the Attendant Console group (as it is a fake/invalid number).

So clearly this INTERCEPT thing is what is affecting both Case 1 and 2, the question is how to disable this behavior (without doing this ugly hack)?

If someone have any idea....
Thanks.

 

[donb01]

If I was going to do what you did I wouldn't have screwed around with ITR group 0 just in case something else relied on it, and would have simply assigned the phones in question to ITR 1, and messed with the destination for ITR 1. But otherwise, the sabotage you did will effectively correct the problem - nothing will ever go to the attendant unless specifically forwarded there, or someone calls the attendant extension.....

It would have been a more elegant solution to put a forwarding destination on the phones. Other things besides just ringing intercept to the attendant, such as calls left on hold too long can do that, etc, depending on the system settings. In those cases now the caller will be on hold and then suddenly get a busy signal and wonder why,

 

[sbcsu]

The intercept to the operator can be removed as follows:
Look at the Trunk concerned
Find out the COT and COP

To supress ALL recalls to the attendant
CHA-COT:XX,COTADD,RCLS;

Also remove the default 'recalls to operator' as follows:

CHA-COT:XX,COTDEL,IIDL,INDG,IONS,ITB,IVAC,IBSY;

That will remove 'Intercept when dialling incomplete', 'Intercept if no digits dialled', intercept if override not successful, intercept when all trunks busy, intercept when vacant (no number assigned to a DDI number), intercept when busy.

Let me know if this is not clear
Regards

 

[jarruda]

sbcsu,

Thanks for your reply.
In fact before posting here I was following the documentation breadcrumb trail and I saw those COT parameters.
As you can see bellow, in the COT being used by this trunk (COT 6) none of the "Intercept...." (IIDL,INDG,IONS,ITB,IVAC,IBSY) parameters are enabled.
Yet, I tried to add the RCLS (Supress all recalls to the attendant) (which is now removed), but it won't change the described behavior.

(I have one doubt here, the changes in the COT are effective immediately? Or the PENs need to be deactivate/activate or other operation to apply?)

Any other idea?

COT: 6 INFO: VOIP
DEVICE: INDEP SOURCE: DB
PARAMETER:
TRUNK CALL TRANSFER XFER
TRUNK SIGNALING ANSWER ANS
LINE WITH MFC SIGNALING MFC
CHANGEOVER FROM HOLD TO RING TONE CHRT
CALL EXTEND ONLY FOR CALL STATE CEOC
CALL EXTEND FOR BUSY, RING OR CALL STATE CEBC
NETWORKWIDE CALL FORWARDING PERMITTED FWDN
DON'T RELEASE CALL TO BUSY HUNT GROUP BSHT
CAMP-ON ON DID CALLS KNDI
IDENTIFICATION OF AC ATDI
DESTINATION NUMBER WITH PREFIX DIGITS TO CDR DPRE
CALL EXTENSION BY AC TO BUSY STATION WITH CAMP-ON CECO
AC WITH REVERS CHARGING ACRC
CCT-NUMBER (TACSU) IS USED AS A-NUMBER ON INCOMING SEIZURE CCTN
TRANSFER ALLOWED WITHOUT DISCONNECT SUPERVISION TWDS
NO TONE NTON

Regards

 

[sbcsu]

Hi,
COT Changes are instant, no requirement to reset the trunk.
Ensure that the trunk has cot 6
CHA-TDCSUEN=X-X-X-X,COTNO=6,COTX=6;

RCLS Does stop recalls to attendant.
Something else is wrong with the system setup.
Could be a ZAND parameter but I have no access at the minute.
It may be happening because it is a SIP trunk ?
Can you get the trunk supplier to trace for you to see what is happening ?

 

[jarruda]

Hi sbcsu,

The trunk have COT 6 for sure, I triple checked it.

It could be something else in the Hipath setup as you mentioned since the described Hack above worked as a workaround.
I did get traces on the SIP side, there is no signaling being done when the call is intercepted by the attendant. So its truly a Siemens only operation.

If you found something else I'll appreciate since I'm not very happy with the actual hackish solution.

Regards,

 

[sbcsu]

A couple of things to check:

Turn off intercept in FEASU
CHANGE-FEASU:TYPE=D,CM=ICPTDID;


Ensure that the tested extensions do not have DND turned on as they could intercept to Operator then.
DELETE-ACTDA:TYPE=STN,STNO=XXXX,FEATCD=DND;

 

[jarruda]

Hi sbcsu,

I did tried with intercept feature deleted from FEASU and checked that the tested extensions do not had DND enable but event then it keep doing the attendant intercept.
Very weird... any other clue?

 

[sbcsu]

Hi,
Temporarily REG-SA; and then delete all the hunt groups on the system (except DECT handover if you have the DECT)
then try scenario 1 again.

What software version do you have ?
Comwin / Macro / Retrieve system variant