Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Legend Mail 007 Setup Problem 4

Status
Not open for further replies.

tdaugirdas

Technical User
Mar 17, 2003
2,575
US
I've a got a guy trying to setup a Legend 007 MLM on a system with a Magix 4.0 processor - with a problem. The007 answers outside line calls immediately vs. the normal 4-ring delay. It's a simple setup. Calling Group 770 has the 4 vm ports. They are "rotary enabled". It's a square system set-up. One Cover Group (#30)is set up with all the extensions in it. 770 is set up to provide coverage for Group 30. The lines are set to all loop start with reliable disconnect set to "Yes". We can't figure out what he has done wrong. He has one mail box set up on the first extension (#10)and a single greeting. What can we check? I have a similar test system setup with another 007 - following the same steps - and the VM picks up only after 4 rings - which is what should happen. Any ideas of what to check?
 
Are the lines assigned to the calling group?

Does 10 have a GROUP COVER DELAY set?

I would be willing to bet he has the lines assigned to all extensions, including the voice mail.

Also, the 007 MLM DOES NOT NEED ROTARY ENABLE, only the MERLIN MESSAGING. (Of course, that has nothing to do with this issue.)



 
Jack: On my test system - I have tried to emulate his problem. But, whether I assign lines to the VM Group or not, the outside line rings 4 times before VM picks up. I have no delay set in the system or VM. On his system, the VM always picks up on the first outside line ring - and we can't figure out why. My test VM is "clean" - no programming done to it; no mail boxes set up; no greeting. I assume he must have set something in the VM system that is causing it to pick up immediately versus waiting 4 rings...Thanks...Tom
 
Actually, if you have it set up with the lines assigned to the VM group, there should be no delay.

The way I do it is to EITHER:

1) Set up a phantom group with the lines assiged to it with OVERFLOW to the VM Group.

- OR -

2) Set up an extension that has line ownership of the lines and then tweak it's Group COver Delay to do what I want.

I like 2 better, but it usually means wasting a PHANTOM attendant port.


 
When you say "It's a square system set-up", is it in KEY mode, as opposed to Hybrid/PBX? If so, you have the lines assigned to the VM ports with immediate ring.
 
Merlinman: I heard of the "phantom" group method, not the second way to get a delay. TouchToneTommy: My test system is square and in key mode and the lines are assigned to the VM group - but I still get 4 rings before VM picks up. The system in question is square, but I am not sure if it is key mode. I still don't understand why my test system rings 4 times before pick-up, and the system in question gets answered on the first ring. Logically, the VM should be factory set to wait a reasonable number of rings (for someone to answer) before going to the AA for pick-up. But logic and Avaya don't always go together!
 
Logically, the voice mail ports should answer as soon as a call is presented to them - otherwise you would be waiting a number of rings before answer when you were just calling in to pick up messages. In other words, it doesn't know how to treat a call until it answers and receives the mode codes. Thats why you must find some mechanism to keep the lines from reaching the AA for a certain number of rings by way of a phantom calling group, or phantom extension. In the Partner world, it's as simple as programming a "VMS Hunt Delay" from 0 to 6 rings and day or nite mode.

Now, have you called each of your voice mail ports directly to make sure each one is answering? Is the hunt linear and the first port not picking up, thus ringing 4 times and hunting to the next port?

 
The 770 VM Calling Group in my "test" system is set up as a linear hunt group and group type is set to Integrated VM. Maybe, it answers on the 4th ring because I have not set anything up in the 007 Module. I will setup one voice mail box and a greeting - and see if it still answers on the 4th ring versus the first. Does the "business day schedule" have any impact on ring delay transfer to VM? (i.e., immediate at night or when closed vs. a delay in transfer during business open hours?) I'll report back once I set up a voice mail box and greeting.
 
Hi Merlinman and Brian: I set up a test mail box (ext 10) and set up a system greeting. The voice mail acts as it did before - an incomming call rings 4 times, then is answered by the AA and a message can be recorded. The message light gets "lit" and when the message is deleted it "turns off". So - everything works as expected without having to setup a second "dummy" voice mail group. I am going to have my customer default his voice mail system and see if that solves his immediate answer issue. If not - I will back asking for advice. Merlinman - in setting up a second "phantom" group, I understand that you also need to setup a "phantom" mailbox with the same number and "point it" to the auto attendant. What does "point it" to the auto attendant involve? How do you do that?
 
Brian: My test system was a newly defaulted one, until I setup the mailbox and greeeting. I undersatnd the factory default is "immediate" vs. "delayed" answer - so it should have been set to "immediate". I tried the test with another fully defaulted 007 VM - and again an outside call will ring 4 times before the AA answers - which is how it should be - I think. I am having the cistomer send the Vm back and am sending him a replacement (my test system). Thanks guys - but I am still confused!
 
That is odd. I just tested a 007 today and it did answer immediately. All I have set up is calling group 770, group type, and assigned the first line to calling group 770. It answered before the second ring ended.

I have a quick reference on our website for Merlin Mail setup on a Legend system. It may be a little dated depending on your Legend's release, but give it a look and see if it helps.

Brian Cox
 
Brian: Your instructions match pretty much what I did. The only thing I did not do is set a cover delay - which is a default of 3 rings, but the VM answers only after 4 rings. Maybe, it's the Magix 4.0 processor that is making the difference. However, I sold the customer the same 4.0 Magix processor.

I will try the same setup with one more re-initialized MLM 007 and see what happens.
 
Brian and Jack: I tried the same setup in my test system with 2 other "virgin" MLM 007's - and they all work the same - I get 4 rings on internal and external calls before VM picks up - which is what the customer wants. So, I sent the customer another 007 MLM - one of the ones I used in my test system. However, he had the same result as before - VM picks up on the first ring. We even tried to set up a "phantom" overflow group with a 20 sec delay - and still the VM picks up on the first ring. Could it be a "bad" processor? I'm pulling my hair out!! The tech is at my customer now. I am having him switch the slot on the VM, default the processor and start over - just in case it is a "bad" slot issue - but don't know what else to try outside of sending him another Magix processor. HELP!!
 
Guys - THANK YOU ALL - Finally figured it out. My "test" system really wasn't being picked up by AA1 - in the way I had set it up - it just appeared that way because the VM answered on the 4th ring. I set up another test system matching the customer's configuration - and lo and behold - as soon as I attached the lines to the VM Calling Group 770 - I had the "immediate" answer he was experiencing - but this time the answer was by the AA - with a different set of prompts. I then found an earlier post by TouchtoneTommy and found that when we set up the "overflow" group - we neglected to set "Number Based Overflow" to 99. We had only set the "Time Based Overflow" to 20 seconds. This resolved the problem - and everything is working as it should. THANKS AGAIN ALL..Tom
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top