IPGURU please HElP

[Vmail]

IPGURU and all:

I have an issue. A customer has been installed IP412V1. 180 phones ccc,ims,the whole shabang. The issue is we have 180 phones that are DID's and set them up via thier respective DID number. IE, station 1234 is xxx-xxx-1234. I used coverage buttons along with bridged apprs, first, and this did not work as the customer wanted it to. So we have tried a workaround.

I have set all extensions from the 1234 to the exchange and extension, ie, 7671234 is old extensions 1234 new extension. All is working fine as far as calls etc. We then set the incoming call route for 1234 to go to 1234 hunt group and ring what we want etc. Then it covers to vmpro where I have under groups a leave mail for 1234 option. Outside calls work fine.

The issue is internal vmail. If I have 7671234 press *17 it goes to vmail and I can have the user press # from their extension and it is fine. But remotely they have to dial the full 7 digit extension to log in. Now if I look at sc *17 it does vmcollect and ?U which is matching username. Is there any way to have the *17 code insert the 767 before the users key in their extension of 4 digits. We are trying to make the customer end user not have to make any changes.

I know that the ?U is matching username, but can we have a sc that matches extension, and insert the 767.

I tried a new sc which i have for direct to vmail, ## is the code and it goes to vmpro where it plays, " please dial the extension you would like to leave a vmail for", then the menu collects digits and transfers to mailbox. I need it to collect digits and insert a 767 in front of what is collected?

There are 2 issues here:

1. How can I have the *17 match extension and insert 767 for all users.
2. How can I in VMPRO using leave mail action, insert a 767 in front of what is keyed in? I tried under the specific tab a 767$KEY, but its a no go.

IPGURU, I ask of your help since you are 'all knowing'

THanks,
Vmail

 

[bwilch]

I'm not sure why you set the extensions as 7 digits. On your incoming call routes, you should have been able to set the incoming number as the DID and have it point to the station, thereby avoiding this all together.

I'm not sure if I just misread something or not, but on the systems I've installed, I build incoming call route 123-xxxx and have it point to xxxx without any issues.

 

[mforrence]

The original post doesn't really say what you want to accomplish. If you detail, we may be able to offer a suggestion...

It looks like you've created a hunt group for each station - some kind of one-to-one relationship between the two. It seems that you could go back to four-digit extensions and still use hunt groups - maybe the hunt for ext 1234 would be 2234. Route DID digits to the hunt group per normal MSN configuration.

MIKE

 

[intrigrant]

Try this :

1: create a shortcode like this
SC = **xxxx
TN = ?767N
Action = VoicemailCollect

2:
maybe you can store the following in a variable using a generic action after a menu : Save:767$KEY. The result will be stored in the $SAV variable, so you should use $SAV as the target mailbox

Let me know if it works.

 

[Vmail]

Thanks all,

To clarify the issue.

We are unable to redo the entire pbx due to the nature of the customer. I am trying to come with a solution that will allow seemless integration changes. That being. How can we have *17 to a voicemail login as before, but now insert a 767 in front of the callers extension they dial in? This will fix the remote issue.

The only reason we changed to 7 digits was so that we could route the DID call to a huntgroup for differenct coverage options, not for anything else. So a call comes in DID route to HUNT GROUP that then does what needs done. Internally a call then comes into the hunt group and does what it needs to. THe only issue is for voicemail. How can we have the user still login as they did before with xxxx even though they are now 7 digit extensions.??

 

[Raffles666]

Does anybody understand this question?

What are your extn numbers? What are your h/g numbers? What have you got the i/c call routes pointing to?

Voicemail uses the persons name - so why mess with numbers?

What EXACTLY does your customer want?


Old school Alchemy engineer - trying to keep up with the times

 

[IPGuru]

oh brain hurts, Sorry but I cannot understand this one at all
There should be no need to use 7 digit extn numbers & this will realy confuse CCC

How does the customer what coverage of the exnt's & there ddi's to work?

I suygest that this site needs carfull replaning or you will be getting constant problems

 

[Vmail]

I know this is confusing. This is how it is today.....

Extn 1000 is DID xxx-767-1000. I set up coverage buttons on the secretary's phone for extn 1000. Incoming call route for the did points to 1000. All was fine. Then the secretary's didn't like not seeing BLF and/or the way the coverage button works. Each Secretary covers over 5 people so Bridged apprs won't work.

So what we are trying to do is, Renumber all extns to 7 digit 7671000 and program a hunt group 1000 with the secretary and other users into. I point the incoming call route of 1000 to the new huntgroup say 71000. Incoming calls work fine now.

The issue is the user was a 1000 now is 7671000 and I am trying to have the sc *17 insert the 767 so that they know no difference in logging into vmail.

I know that the *17 does the ?U which is the users name, and if the login from their phone they can press # when asked for extension and all is fine. But if calling remotely or from another phone, they have to insert the 767 before 1000, and I am trying to eliminate that.

Have I made any more sense?

 

[IPGuru]

if incomming calls are going to group 1000 then VM will also go to mailbox 1000 (unless you have changed this in VM pro)

If you run VM Pro in IP Office mode & add V7671000 into source numbers then you should be taken direct to your mailbox without having to add anything.
I beleave that adding a default listen start poing to a GetMail action can achieve the same thing in intuity mode