I have a cp application that has 3 transfers from the main menu. If the location the call is to be transferred to is busy, the caller hears one ring, the is disconnected? What have I done wrong?
one ring and a disconnect it not usually as application problem, a little hard to program one to do that, even if you try. in the transfer internal? if not a ncos block on the sets for the mail interaface can cause problems.. wheni have that type of problem i make sure i can transfer to that number, or build a temp application and test transfer to my set then to the needed dn.. another question, do you have applications that are transfering to the same type number?
I found that one of the tranfer locations was a phantom number in dcfw to a menu. I fixed that one. I now have the problem only with calls that are transfered to extension that are on ACD sets. I think the problem occurs when the phone is in MSB. ONe of the phones has a hunt locaiton and one doesnot.
the pratial ringback may be cause via a transfer delay, and your transfering to a bust station. add hta and a hunt dn to that set to make sure the problem is just when transfering to a busy station, you should be able to set a treatment for failed or busy on the call box
Okay, back from vacation. Still having the problem. I have programmed the set in question, ext 1813, to HTA, FNA, Hunt to voicemail, FDN to voicemail. MWA, LHK to include the personal extension.
Review of problem: Call goes to menu. Caller selects option 5 that is a call transfer block to ext 1813. If 1813 is available, call is transferred. If 1813 is busy, call is disconnected. If 1813 is called directly, call is treated properly.
lhk, are all the dn's in that chain marped on that set? problem i have found.. lhk 3 key 3 is marped on an analog that someone forwarded to a bad number.. keys 0 and 1 busy, call is presented to key 3, the marp on the analog tries to forward to a number that reaches the busy.. the hunt on the original sets condition is never met
RCO 0
HUNT 1000
LHK 3
PLEV 02
SPID NONE
AST
IAPG 0
AACS NO
ITNA NO
DGRP
PRI 01
MLWU_LANG 0
DNDR 0
KEY 00 ACD 1810 0 5131
AGN
01 NRD
02 MSB
03 SCR 1813 1 MARP
CPND
NAME ODC FRONT DESK
XPLN 14
DISPLAY_FMT FIRST,LAST
04 TRN
05 MWK 1000
06 AO6
07 AWC
DATE 25 OCT 2005
TYPE ACD
CUST 0
ACDN 1810
MWC NO
DSAC NO
MAXP 10
SDNB NO
BSCW NO
ISAP NO
AACQ NO
RGAI NO
ACAA NO
FRRT 19
FRT 2
SRRT 20
SRT 30
NRRT
FROA NO
NCFW 1000
FNCF NO
FORC NO
RTQT 0
SPCP YES
OBTN NO
RAO NO
CWTH 1
NCWL NO
BYTH 3
OVTH 4
TOFT NONE
HPQ NO
OCN NO
OVDN
IFDN
OVBU BSY BSY BSY BSY
EMRT
MURT 10
RTPC NO
HOML NO
RDNA NO
ACNT
NRAC NO
DAL NO
RPRT YES
RAGT 16
DURT 30
RSND 4
FCTH 20
CRQS 100
IVR NO
OBSC NO
OBPT 0
CWNT NONE
couple of prompts i will look up before posting, they may be the problem.. fyi lhk does not hunt past a feature key and should never be set on an acd agent.. a little surprised that two calls to that station at the same time doesn't ini the switch...
Wow! in 24 years of programming, never heard that! I have many acd sets with an LHK of something other than 0. This has me worried.
As to the Call Pilot thing, I set the busy treatment on the call transfer to express message to the mailbox. It seems to be working. Have I created a bigger problem?
I agree with Nancy24. On most ACD sets I've seen built the LHK is equal to the last SCR keys, hunting and forwarding doesn't apply to ACD. Your right about not hunting past a feature key but it also depends on where the SCR key is in the layout of the set and LHK value. I'll check the NTP's but don't recall any mention of hunting or forwarding programed on acd sets as causing system to crash. Can you post the bulletin or NTP that has this information. I'd like to know for the future when a customer has a number on an acd set that they want to go to mail. Would you have to set up a dummy TN to accomplish the Hunting and forwarding? If so, how does this effect the message waiting key?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.