Night Service in the middle of the day

[BunchOfSavages]

Hi All

IP Office 403DT V3.0(580)- users are complaining that incoming calls to the hunt group are randomly being diverted to the Night Service Fallback Group - in the middle of the day.

I've checked the Time Profile - Which is 8:30-17:00 Mon-Fri.
I've checked the Service Mode. Which is "In Service"
I've manually checked the group is out of nightservice *21*ext#
It still happens.

Any one come across this? Know how to solve it?

Attached is an extract from SysMonitor - showing a call coming in at 14:34 and being diverted to the Night Service incorrectly.

On an unrelated issue - can anyone please explain why in the CallStatus utility I'll sometimes see NoUser() calls that are thousands of minutes long with no number? It's very annoying - and prevents the unit from rebooting when free.

Thanks for any help.
AJ

 

[CarGoSki]

Check incoming call route to see if a fallback extension is programmed. Also you can setup and run sysmon to capture the event. Then you will know what happened.

 

[BunchOfSavages]

I've looked at Incoming Call Route; there is no Fallback Extension.

There is no Night Service Profile specified for the Incoming Number - what's the difference between Time Profile on the HuntGroup and the Night Service Profile on the Incoming Number, which is best to use?

Its also not clear - Does the Night Service profile in Incoming Call Route specify when the line is IN Night Service, or when the light is OUT of Night Service. i.e. if I wanted the Night Service Destination to be ext 301 between 5pm and 8am how would my Night Service profile be configured?

Could you please provide instructions/link to instructions on how I'd setup and run sysmon to capture the event?

Thanks,
AJ

 

[CarGoSki]

Time profiles can be explained as "do this during this time" or known as a true or 1 event.
So if you have a time profile assigned to an incoming route then it is true during the time profile and would route to the destination selected during that time profile.

I typed time progile three times in one sentence. -10 points for me.

Run sysmon, enter in the address of the pbx, set up the logging and let it run. You can probably find other sysmon guidance here by searching.

 

[CarGoSki]

Hmm.. I see that you have already included an excerpt from sysmon. In that excerpt CalledNum=9210 so it routed to dest=FSHUNTGROUP

It does appear to say that the group is operational:
NS HG:125 FSHUNTRGOUP out_of_time=0


The rest appears to say that it routed the call to a night destination.

75842538mS CMTARGET: ADD HG:125 HFSNightService (depth=2 B=0)
75842538mS CMTARGET: CHK HG EXCEPTED:125 HFSNightService count=0
75842539mS CMTARGET: ADD USER:125 FSNightService(301, state=Idle) (depth=3 B=0) cw=0
75842539mS CMTARGET: ADD TARGET:125 number=NightServiceNumber type=100 depth=4 nobar=1 setorig=0
75842540mS CMTARGET: SYS SC:125 NightServiceNumber 0 sc=type=Dial code=?, num=.
75842540mS CMTARGET: LCR NOT MATCHED:125 (cpn=NightServiceNumber)

 

[BunchOfSavages]

That's my understanding of the log - but I can't understand why it routes the call to the NightServiceNumber when the Hunt Group is within working hours.

I've disabled the Time Profile for the Hunt Group for the time being - and I'm having the users manually enable and disable Night Service to see if the problem still continues.

I may be able to use the Night Service Profile for the incoming call route rather than the Time Profile on the Hunt Group as it's only external calls that I really need to route.

Can anyone confirm this will work and that I'd specify the out of hours time, i.e. 00:00-8:29 and 17:00-23:59 for the Night Service Profile to be in effect.

Thanks all for your help and comments!

 

[hairlessupportmonkey]

so whats the time on the IPO - is it getting random time off the network somewhere?

ACSS - SME
General Geek

 

[BunchOfSavages]

SysMonitor is showing the correct date & time... as far as I know the handsets also show correct date & time. I assume this means the IPO unit is correct?

 

[CarGoSki]

Does the group fail in the same manner when you dial it directly?

This will determine if the failure is trunking or the group.

I suppose it is possible that the time profile is causing the error but I did not see time profile decisions in your sysmon traces.