DN rings correct Ext but forwarding reports different DN to VM

[R6Wraith]

Long time reader first time poster. Everyone in here always has some great advise and I just want to say thanks first to everyone that has posted all these great solutions and advise that has helped me many times.

I have a client that has a MICS T1R1 with 12X0 and 2 x 0x16's with a 12 port Voicegate System. Everything was working fine until a recent upgrade to an additional 0x16's and software update on the Voicegate. I truly believe the problem lies within the voicemail but I just need some ideas as to where to start looking.

Basically a caller hits the AA (full AA) and caller enters the Extension (222), the call is transferred correctly to 222 and the extension rings. Then the Call Fwd kicks in and transfers to the VM Port 1 (254) but as an example, the caller gets Ext 223 voicemail. When looking at the digit grabber (built into the VM) the system VM port 1 is seeing the call transfer to 222 but forwarding back from 223, hence why it gets 223's voicemail.

This doesn't happen ALL the time and is intermittent, with no pattern. I have verified the DN's for the voicemail and system work. The manufacture has suggested that the phone system is misreporting the DN throughout the system, but I don't buy this. When transferring calls internally and when calling in it ALWAYS goes to the proper extension. The problem lies when the extension forwards to the voicemail ports and the voicemail thinks it sees it coming from another extension hence why it apparently is sending to the incorrect mailbox.

I have even gone as far as punching down on the voicemail ports and see what a phone (M7310) passes when it forwards from the above example. It reports the forwarding properly.

So, has anyone ever had a situation where you call Intercom 222 and it rings 223? If so how can you fix it? I need to know since the manufacture is claiming that is what happening but it all my testing I can't see how.

 

[bkrike]

I am not familiar with the voicegate (Nothing Beats Full Integration with Norstar.)

Regarding your question --calling 222 and having 223 ring: It could happen with answer DN's. Have you checked that?

 

[trabra]

How are the Voicegate ports (12 Ports) connecting/Integrated into the Norstar?

 

[R6Wraith]

Not and answered DN senario. The Voicegate basically works like this.

12 ports = 12 M7310 phones.

So 1 Dialogic Card (emulates M3710 handset)has 4 ports on it. If you hook up a M7310 to the Port/DN (just as normal) the button programming and everything is there. It's a "smoke and mirrors" trick basically. It works just like someone was sitting at that VM port and manually transfering calls but done by a computer. So more of an "analog" integration.

It's not a ringing problem, it's transfering / forwarding with CFNA and the MICS is apparently reporting the DN it came from inproperly to the Voicemail.

I agree Norstar with Norstar is better, however the VG has been working pretty good. These are the stupid this that occur every once and a while I guess.

Thanks for the reponses BTW.

 

[hawks]

Have you tried it with a Hard Call Forward?

 

[R6Wraith]

Not yet. Just to clarify you mean acutally put the bad extension on manual Call Forward to see how it behaves? I will give that a try.

Any other ideas?!?! My client has been great up to this point. Now they are starting to demand some solutions. You know how it is.

 

[DonRight]

This is a fascinating scenario. Just a thought - perhaps it is nothing of relevance. Is 222 associated with port 102 and 223 with port 103? Have the DN's moved to different ports with time via set relocation? For that matter, is set relocation left on as a rule?

I have come across issues re set relocation and third party applications.

 

[telemarv]

I have several Norstar with Voicegate VMS. Althought they are good systems, Voice gate can be unstable. Often really weird, whacky and intermittent things begin to happen over time. Although I've never seen your particular problem, it does surprise me. Its a DOS based operating system and requires the occasional reboot. Reboot should clear it.

Make sure up do a proper shut down first (Control F10). How old is the PC and what software is it now running?

 

[R6Wraith]

System ironically had a motherboard update to allow the expansion of the 3rd dialogic card which was done by the manufacture. Reboots don't seem to solve it. I have rebooted several times. Running Ver 3.11. It is still an intermitent problem but one that frequents everyday.

There is no set relocation that I am aware of. Not turned on in the programming. I believe the 222 is 102 as this is just the example, but the ports are correct to the DN's fromt he ones that I checked.

Thanks again!

 

[telemarv]

Since this is an upgraded system (3rd board) have you tried taking those ports out of the Norstar hunt group (stop the forwarding from port 8 to 9) and seeing if that makes a difference. Or even try removing the 3rd board from the PC completely. Maybe the 3rd board is causing the trouble. Don't suppose you noticed if it is one particular port that is acting up. if its intermittent its probably on of higher ports having trouble as the lower ports are used first and the higher ones are only used when the lower ones are busy.


From my memory latest software release is 3.21. You might want to try a software upgrade. You also might want to play with the channel settings. There are frequency and dtmf duration adjustments on channel by channel basis. Because it sounds like the outbound signalling is correct but inbound is being misread. But you might want to talk to Voicegate tech support for help with that.

Another you can try is changing the call transfer mode (in COS) to 0 (BNA) instead of 2 (Blind transfer) which is default. In BNA mode the voicegate will monitor the station and not release the call until it is answered. This way you're not relying on the Norstar CFNA/CB to return the call to the voicemail. Its resource heavy because the port is tied up longer. You'll have to change the Nortsr call forwarding to none for this to work. But it might solve your problem by letting the voicemail keep track of the call.

Also have you tried rebooting the Norstar?

 

[R6Wraith]

I have spoken to most of the tech support staff about this problem, all I get is the answer of how the phone system is causing this, which I don't buy at all. Seems the easy answer in my opinion. It is not one particular port or card and I have rebooted the phone system a couple of times with the voicemail.

I do however like the BNA option. I will try that for sure when I head back to the clients place. The channel setup has been confirmed correct by 3 different tech's at Voicegate, so I am confident everything is ok there, but again you never know.

 

[R6Wraith]

This is a follow up for anyone that may ever run into to my situation. I have solved the issue!

It apparently, as I expected an intereting issue with version 3.11 when upgraded with a KSU that had set relocation, if it was ever turned on and or used. Even though now it is turned off.

I in turn re-numbered the DN's from 225, 226, etc to 701, 702, etc (random number). Since the old DN's where not technically in the original default port on the KSU (physical wiring) the VoiceGate seemed to have issues grabbing the information from the KSU.

The VoiceGate instantly started working properly. I spoke with The guys at VoiceGate multiple times with regards to this issue. I confirmed this situation at another site with a completely different KSU and software revision, but with a 3.11 upgrade. I did the exact same solution and it worked as well.

As I have been told in the 3.11 documentation it refers to make sure that set relocation is not turned on but it has been discovered that even it has EVER been turned on and the Voice mail ports have been swapped by the use of set relocation that it will cause such problems.

I hope this helps someone in the future since this was a long process of elimination for both myself and the manufacture. The previous versions of the software apparently wasn't as sensative as 3.11 is now.

 

[bkrike]

Thanks for closure...it rarely occurs here. People usually get their answers, and never post again till they have another question.

 

[FletcherP]

Set relocation is the worst feature that anyone can use on a regular basis. Only use it to relocate a set for a short time until you can get to the site and move the cross connects. You can also lose VM ports if you use it to move sets all the time.