Call forwarding and "Busy Wrap Up" failure (Phone Manager Pro v1.4)

[Nostferatu]

Hi all.

I have recently purchased IP Office at 3 locations (Going hopefully live with 14 networked locations by the end of the year in the US and expanding internationally over 2 years) but have run into a weird and rather irritating problem.

I have a T1/PRI and we use an answering service out of hours to route calls (Management decision) so at 5pm each day we use the Phone Manager Pro(v1.4) to forward the receptionists phone (She belongs to 3 hunt groups for the various businesses streams)

Since friday whenever anybody calls the main line number they receive a busy tone when calls are set to be forwarded. Unforwarding calls fixes this... But obviously they don't get answered.

I have verified that forwarding works on alternative extensions, and ensured that the numbers being dialed for the forward are valid.

The only problem I can see is the Busy Wrap Up feature when you are a member of a call centre style group (We don't actually use this feature, but it "appeared" when this problem appeared). Enabling you some time after hanging up before taking further calls, on the Phone Manager application the Status box appears displaying "BUSY WRAP UP" even though Agent mode is not enabled, therefore not allowing the DND (Do Not Disturb)and BWU (Busy Wrap Up) toggle boxes to be displayed. Configuring the application so that she is an Agent member puts the required icons on Phone manager but the BWU icon appears to be stuck to "On" thus creating the busy signal for all further incoming calls.

Is it possible she somehow has dialed a shortcode to enable permanent Busy Wrap Up ? is there any way I can disable it for this extension on the system ?

Although not technically a major problem (Taking her out of the hunt groups and redirecting all external calls to her extension then forwarding works fine) the receptionist is tasked with answering the phone differently depending on the number dialed by the incoming caller. The purpose of the hunt groups was to display the name the receptionist needs to answer as.

Any clues/advice/bottles of rum gratefully recieved.

I have done the standard rebooting of the system, hard reset of the system, asking nicely for it to work, threatened with physical abuse, told it to behave or it will be swapped out for a Panasonic (OK... quite some bluff but hey, I'll try anything)



Nostferatu

"Yesterday is History,
Tomorrow A Mystery,
Today is a gift,
That's why they call it the Present"

 

[crashtest1000]

We have found a problem with 1.4 when you us the group forward feature basiclly it apears fail if the caller comes in on an outside line and a user has forwarded their calls off site to another outside number the call will fail.

I think we may have a work around figured out next week will post it if it works otherwise FSG have reproduced it so maybe ther be a fix soon.

 

[IPGuru]

What type of group is the receptioist in , you can only forward hunt group calls from hunt & rotory groups not Group & Idle,

BUW is a read herring i think , there has always been an automatic wrap up time in the IPO system (and NA) it is just now that it is also accessable from PM for call center use.

you may want to try using the monitor app to trace what happens to the call

 

[NuggiFirst]

On the constant BWU:

If a user is member of more than one group, then the last group on the Agent-tab needs to be enabled always, or else the BWU will fail...

The solution is simple:
Create a dummy group with all the user enabled. The group needs to have the highest number of all the groups. In this way, the dummy-group will be the last one in the Agent-tab.

 

[Nostferatu]

Thanks for the responses.

This is still a problem as of now (But has been working up till friday as noted)

To answer the questions presented.

The user is a member of two linear huntgroups. that simply recieve the inbound calls as either company a or company b which displays that as the inbound call type on the receptionists phone.

The Agent and BWU could well be a red herring, but is the only thing that appears to have changed (IE started appearing). Maybe the work around from crashtest1000 could shed some light on it.

For the time being I have to change the path of the huntgroups to the receptionists phone directly in the evenings in order for the forwarding to work. Which although doable is a severe pain in the ass.

Any thoughts are gratefully recieved.

Thanks in advance.



Nostferatu

"Yesterday is History,
Tomorrow A Mystery,
Today is a gift,
That's why they call it the Present"

 

[IPGuru]

How are you switching to the receptionist at night?
I would use a fall back group & time profile, remember that the fallback group would also have to be linier & divert hutgroup calls would need to be set on the receptionist.(although it would be less troublesome to have a dummy user in the gropu if the only reaon is to send the call of switch

I would be willing to take a look at your config if you wish
Or send you a sample one if you prefer

 

[Nostferatu]

Night service is achieved by simply using the forwarding facility in the phone manager application on the receptionists phone (Done at 5pm). Checking the forward unconditional box and including the number to be forwarded too.

This simply makes the mainline numbers respond back to any inbound calls as busy, and she is also unable to dial out at that point.

I don't have any problems forwarding you the config, but will check with our supplier first (They are also looking into the problem, but being a fond member of the Citrix forums here thought i'd see if anyone could help).

Many regards,

Nostferatu

"Yesterday is History,
Tomorrow A Mystery,
Today is a gift,
That's why they call it the Present"

 

[IPGuru]

I certainly cant see any reason why what you are trying wont work, I have a number of sites that use this method when the office is to be left unmanned.

You are remembering to leave the receptionist In Group as well as activating forward unconditional
(I take it as read that forward hunt goup calls is ticked)

as a quick thought 1.4 has the option to prevent of switch diverts, check the system telephony tab & make sure that Inhibit off Switch calls is unticked - this should be the default setting.

the only other thing I can think of is that there is somthing unusual in the US t1 setup (beeing uk bassed we dont see it here)

 

[Nostferatu]

I know what you mean IPGuru, once more I seem to find an issue defying logic... I'll double check the areas (Forward hunt group and inhibit) but am pretty damn sure they are good.

What is totally dumbfounding is that A) it worked fine for a week when first implemented and B) works fine on any other phone you wish to try...

Could it possibly be a fault with the DSS unit at the receptionists workstation ???

I'll let you know what I find on the setup.

Thanks again and regards.

Nostferatu

"Yesterday is History,
Tomorrow A Mystery,
Today is a gift,
That's why they call it the Present"

 

[Nostferatu]

Hmmm.... what would the diagnostics be if "forward hunt group calls" wasn't ticked out of interest ?

I cannot be sure if I had unchecked this whilst playing with the problem, but have rechecked it now and will see in about 40 minutes.

Nostferatu

"Yesterday is History,
Tomorrow A Mystery,
Today is a gift,
That's why they call it the Present"

 

[Nostferatu]

After switching over to the forwarding at 5pm and watching the call monitor to see what happens with incoming calls there is now a slight difference with the problem.

When "Forward Huntgroup calls" is checked the call is placed on hold for 10 seconds before getting dropped.

When "Forward Huntgroup calls" is not checked you get the busy signal.

Is this info of any use ?

Nostferatu

"Yesterday is History,
Tomorrow A Mystery,
Today is a gift,
That's why they call it the Present"

 

[IPGuru]

use Monitor not call status & ennable all the T1 settings
you should be abble to see the call getting dialed out to line & be able to identify the cause of failure.

What is the ring time of the group, the call could eb beeing recalled to the next ext before it connects.

this is why I recommend using a NS Fallback group & a dummy ext to do the off switch divert.
You can programm DSS keys to enable & dissable NS if you do not wish to use a time profile.

I can email an example if req.