Have upgraded to 4.0

[ipo412]

I have upgraded to 4.0 (I know, I know... no need to flame)

Everything except one thing seems to be working, however the one thing that isn't working is some hunt group forwarding. I will explain.

Previous Results: (Running v3.2)
1. External call comes in
2. Incoming Call Route sends call to 7100 (Reception HG)
3. Reception HG overflows to 7101 (ReceptionBkup HG and HFwdAADay)
4. If no one in ReceptionBkup answers, HFwdAADay sends the call to UFrwdAADay
5. UFrwdAADay sends call to VMPro using unconditional fwding

Now 1-3 are completing, 4 does note seem to transfer the call to the HFwdAADay HG.

Here is the Monitor output that I think is important:

14268953mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: TimerExpired cause=2
14268953mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: ActionNoAnswerTimeout()
14268954mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: Retarget NOANSWER EXCEPTED=00000020 INCLUDED=00000020 valid=0
14268954mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: RetargetNoAnswer on HUNTGROUP=ReceptionBkup. Ring Attempt 0 All Extensions Attempted

14268954mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: AddHGTarget ReceptionBkup (depth=1) allowq=0 type=CMNTypeUnknown
14268955mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: OV visable. VM NOT visable:Timer running

14268955mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: FindNextInServiceHgInHgIncludedList: Resolved HFwdAADay

14268955mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: PrimeForHGTarget: HFwdAADay orig=0 targets_inc(0x20)
14268956mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: AddHGTarget HFwdAADay (depth=2) allowq=0 type=CMNTypeUnknown

14268956mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: AddHGTargetRingGroup HFwdAADay ring_attempt_count 0
14268956mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: HFwdAADay: Not using 7132: LongestIdleInfo Uninitialised

14268956mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: OV visable. VM NOT visable:Timer running
14268957mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: FindNextInServiceHgInHgIncludedList: Resolved No Alternative!

14268957mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: PrimeForHGTarget: Reception orig=0 targets_inc(0x20)
14268957mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: AddHGTarget Reception (depth=3) allowq=0 type=CMNTypeUnknown

14268958mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: AddHGTargetRingRotary Reception ring_attempt_count 0
14268958mS CMTARGET: 1.19.1 121 Q931 Trunk:1 CHAN=1: ADD USER: Receptionist depth=4 disallow_cw=1 dnd=0 real_call=1 type(CMNTypeUnknown) incl(0x20) excpt(0x3c), allow_redir(1) remote=00000000

14268961mS CMExtnEvt: ElizabethI: CALL LOST (CMCauseRetargetNoAnswer)
14268961mS CMExtnEvt: ElizabethI: Extn(303) Calling Party Number(18473098358) Type(CMNTypeUnknown)

14268961mS CMExtnEvt: LongestIdleInfo::ResetLongestIdleTime: Pending Idle
14268962mS CMCallEvt: 253.1432.0 -1 ElizabethI.0: StateChange: END=X CMCSRinging->CMCSCompleted


I think the important line is: HFwdAADay: Not using 7132: LongestIdleInfo Uninitialised (7132 is UFrwdAADay)

Does anyone have any ideas? I am at a loss.

 

[kwing112000]

One thing i have seen in the past is anything longer that 12 letters in the name may cause issues. I have hunt group ques not work when the name was 13 letters long. Just something in the names i saw. I was in a class with a high level Avaya engineer and he stated this as well.

 

[intrigrant]

HFwdAADay: Not using 7132: LongestIdleInfo Uninitialised (7132 is UFrwdAADay)
Is 7123 a user? Is the type of the group Longest Waiting? If so then you cannot forward unconditionnaly to another target, only sequential and rotary type of groups can do that.

 

[ipo412]

intrigrant,

7123 is a user (UFrwdAADay)

HFwdAADay is a HG that is set as Collective (previously called Group)

-T

 

[intrigrant]

Ah, change it to Hunt.

 

[ipo412]

intrigrant,

I changed it to 'Sequential' (Hunt) with a similar result. (BTW, this is how it was setup after the upgrade.)

Here is a snippet from the SysMon:

AddHGTarget HFwdAADay (depth=2) allowq=0 type=CMNTypeUnknown
AddHGTargetRingRotary HFwdAADay ring_attempt_count 0
HFwdAADay: Not using 7132: LongestIdleInfo Uninitialised
OV visable. VM NOT visable:Timer running

Any other thoughts? Or another way I can do this?

-T

 

[ipo412]

-- update --

I have not solved this issue, but I did find something.

I changed the membership of the HFwdAADay hunt group to my extension (removed UFrwdAADay) and set my extension to unconditional fwd to the proper ext and it worked. I cannot see any difference between my ext (309) and 7132.

 

[ipo412]

*** SOLVED ***

I hate these kind of solutions, but here it is.

I had do delete and re-create all of my "Fwd" type user accounts (Not ALL user account) but all accounts that fwd to auto-attendants. For me it wasn't a bid deal, only 5 accounts. I hope this helps someone else.

 

[dencom]

When you want to forward a call to another huntgroup, using uncondionally forwarding.....you cannot. This is a bug....cq35625

Arnoud

 

[ipo412]

dencom, thanks. The hunt group is not using unconditional forwarding, the user is. The issue is resolved.

 

[sincman2001]

is HFwdAADay a HG or a user?

 

[ipo412]

HFwdAADay is a Hunt Group.

We labeled our Hunt Groups to start with H and the users to start with U.

 

[jimmynovacom]

have the same exact problem, but recreating the users didn't seem to help.

do you have users that forward unconditional to a short code like *91 which then is defined as Auto Attendant and AA:something ?

 

[ipo412]

Jimmy,

I the users do forward to ShortCodes. The short code in my case is 7152 and the destination is "#Short Codes.AAMain".

hth