Forwarding External Calls

[G.Fiszt]

Hey guys,

I'm trying to create an forwarding like this:
The extension will forward just the incoming external calls, but the received internal and received transferred calls remains normal.
That's the easy part...

I've created a FWD on AMO ZIEL:
ADD-ZIEL:TYPE=FWD,SRCNO=9040,SI=VCE,DESTNOF=9000,DTYPE=CFU,ITYPE=EXT,CFVAR=SYSTEM;

And activated on AMO ACTDA:
ADD-ACTDA:TYPE=STN,STNO=9040,FEATCD=FWD,CFVAR=SYSTEM,SI=VCE;

The forward works just fine, the problem comes now:

When any other extension tries to transfer an external call to the forwarded extension, the call ends going to the destination of the forwarding.
Ex: any extension receives an external call and try to transfer it to 9040, but the transfered call ends up going to 9000.
The question is.... There is a way to configure an forward on 9040 on a way that he can receive transferred external calls?

 

[sbcsu]

So the internal calls are to be diverted but the external calls are to ring the phone ?

 

[G.Fiszt]

Actually the internal calls are to ring on the phone, and the external calls are to be diverted.
This is working, but when another extension dials to 9040 (internal) and tries to transfer an external call, this call goes to 9000, but it was supposed to ring normally on 9040.

This is the context: The user of the extension 9040 cannot receive external calls directly, these calls are to be diverted to 9000. But it can receive all other calls (internal, transferred internal, transferred external...).

It seems that the HiPath 4000 identifies that an external call is being transferred, and diverts the call.

 

[sbcsu]

It is probably a cop/cot issue
You need a minimum of the parameter 'XFER' in the COT of trunk.
Also you could try introducing the call - wait for answer then hang up or scroll to transfer to try transferring the call.

 

[G.Fiszt]

Even when the user tries to introduce the call, the system diverts it.
For example: If the extension 9001 answers an external call, and then try to transfer it to 9040, when the person on the extension 9001 dials 9040, the system diverts the call to 9000 and the extension 9040 doesn't even ring.

I verified the following AMOS:
COT, COP, COS (extension and trunk), ZAND, ZANDE and FEASU, but I didn't find anything that can be changed in order to solve this issue.

The configured COT has XFER. I found two FEASU parameters but I'm not sure what they do and whether I can activate or not.
The parameters are XFBACALL and XFBADIAL.

I'm starting to think that this is a characteristic of the equipment

 

[sbcsu]

Here are the COT parameters that I have on a random ISDN trunk, your mileage will vary especially if you are located in North America.
You could setup a test COT and move the circuit into that test COT and retest.
If still not working you could then move it back to the original COT.
Example
CHA-TDCSUEN=1-X-X-X,COTNO=XX,COPNO=XX,COTX=XX;



RECALL IF USER HANGS UP IN CONSULTATION CALL RCL
TRUNK CALL TRANSFER XFER
TRUNK SIGNALING ANSWER ANS
CALL EXTEND ONLY FOR CALL STATE CEOC
CALL EXTEND FOR BUSY, RING OR CALL STATE CEBC
CPS 6 SET WITH CONNECTION TYPE "CO" CPS6
DON'T RELEASE CALL TO BUSY HUNT GROUP BSHT
SEND NO NODE NUMBER TO PARTNER LWNC
INCOMING CIRCUIT FROM SYSTEM WITHOUT LCR NLCR
INCOMING CDR BY ZONE OR FROM LINE ICZL
INCOMING CDR ACTIVATE PER TRUNK ICZO
USE DEFAULT NODE NUMBER OF LINE DFNN
INCOMING CIRCUIT FROM SYSTEM WITHOUT LCR (DATA) NLRD
CDR FOR BREAK OUT TO CARRIER CDBO
DONT SEND DIV_LEG OPERATIONS, BASED ON DSS1 AND QSIG DSDL
CLINAMETR (CLI NAME TRANSLATION) USED FOR TRUNK CLNA
CLIACT (ACTION BASED ON CLI) USED FOR TRUNK CLAC
NO TONE NTON

 

[Moriendi]

I think this is normal operation.

Instead,

1 - When transferring to the forwarded extn, dialling the fwdignor code will override that forward. But users will need to remember to do it.
2 - If only a few users are transferring to the extn, they could use a DSS key which will also override the forward
3 - Could also remove the external forward, and give that phone a COS with DIDBLK so an external caller can't dial it directly. 4K will release incoming call but you could make it intercept to atnd if required.
4 - Could also remove CPS 6 from WABE which is similar to DIDBLK but with a different release.

(3) is probably easiest.

 

[G.Fiszt]

Thank you guys.

I tried that COT but didn't work.
I also think that option 3 is the easiest. How can I intercept to ATND before DIDBLK disconnect the call?

 

[sbcsu]

To intercept calls to the Operator you need to add intercept parameters to the COT of the trunks concerned.
IVAC, IBSY, come to mind - you need to read up on these and their impact on your telephony network before you activate them.
Do you have a local maintainer that could call in to advise ?

 

[G.Fiszt]

I can contact Siemens, but the process is kind of slow, but maybe these parameters can help, I'll check them.

 

[Moriendi]

You want intercept when unauthorized "INAU" to catch the DIDBLK calls at atnd.

 

[donb01]

I'm late to the game here, but if an external call comes in to the phone and you have forwarding set up it will forward as desired. If an internal call comes in and you have no forwaring set up it will ring through as desired.

If another phone TRANSFERS an external call to your phone it is STILL an external call and it will follow the forwarding for an external call. I try to explain this to people who demand strange forwarding on phones because they are too cheap to put a butt in the seat - you never quite know what you're going to get in that situation.

The other thing that is not common knowledge is that if you forward your phone to another phone the system will first check to be sure it CAN forward the call before it tries to do it. If that target person is on the phone and there is no forwarding set up on the target phone (i.e. the caller would get a busy signal) the system DOES NOT forward the call - it will sit and ring on the original phone forever or until the caller hangs up!

Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA

 

[G.Fiszt]

It's difficult to understand why these people can't seat and answer the phone indeed, the system is smarter than they are.
But I think that INAU and DIDBLK will solve the issue transferring the call to the ATND.

 

[sbcsu]

If the operator gets the call they can override any external forwarding by using the console step/ring function or by dialling the FWDIGNOR prefix before dialling the extension.

 

[G.Fiszt]

Thanks everybody, I appreciate your help, the configuration is working!

The destination of the FWD wasn't the ATND configured on the system, in that case, this is what has to be done:

Add INAU to the COT, DIDBLK to the COS and check if the parameter ICPTDID is active on FEASU;
Change the extensions' ITR (beware of VBZ previous configs)
Create a new NAVAR, including on it the destination of the FWD;
Create a VFGR without any ATND, activating the fixed night service on AMO ACTDA;
Create a VFGKZ for the new ITR

In this case, when an external call enters to the "forwarded" extension, the DIDBLK blocks it, the INAU transfers it to the VFGKZ based on the ITR configured. Then, when another extension needs to transfer an external call to the "forwarded" extension, it works normally.