CME/CUE phone second line busy/no answer to voicemail

[rywalker]

Hi,

I am having a issue with ephones and second line appearances going to voicemail.

I think the issue is that the primay line (DN) is not being remembered and thus the fowarding line to voice mail is the 2nd lines (dn).

I am wonding if a translation rule will fix the issue? If so does anybody have a working example?

If there is another way to fix please let me know

Thanks,

[Markus Schneider]

That's how it is supposed to work. In most cases, the easiest thing to do is to have the second line be the same DN as the first one. For instance

ephone-dn 1 

 number 5001 

 no huntstop 

 preference 1 

 call-forward noan 6000 

ephone-dn 2 

 number 5001 

 preference 2 

 call-forward busy 6000 

 call-forward noan 6000

Extension 6000 would be the CUE pilot number. The other reason this makes sense is that then you only have the one extension for that particular caller so you don't have to keep track if they're now extension 5001 or 5002 or whatever depending on which line they call from.

[rywalker]

I guess I am a little confused. Does CME not have the knowledge to retain the forwarding number like Call Manager? I have this working with call manger and it works.

Example DN (1) is a DID and DN (2) is for internal extensions?

I assume I could create a translation rule to retain the forwarding number when it hits DN (2) so it hits the correct voicemail DN?

If I give both lines the same DN essentially that is creating a shared line appearance or am I missing something?

Thanks for the reply

[Markus Schneider]

No problem. The CME / CUE works on the *last* redirected number. This is just like CalManager. So if A calls B which forwards (busy or whatever) to C and C forwards to voicemail, it will go to C's voicemail box.

If you'll notice in the example I gave, one of the ephone-dn's has a preference (1) and the other has none (which defaults to preference 0). What happens is that the first call is extened to the ephone-dn with perference 0, the next call will hunt to the ephone-dn with perference 1. That's why there is only one call-forward busy set on the latter ephone-dn. It would be redundant to put it on both.

If the two ephone-dn's had the *same* preference, then you would indeed set up a shared line. But if the preference is different, then they are not shared.

If you wanted to set up two different numbers pointing to the same mailbox in CUE, then you could configure the primary number and the E.164 number in CUE on that mailbox. Then they would both be associated with a single mailbox.

Another option to keep in mind for your scenario of having an internal extension and external number is the "dialplan-pattern" configuration option in CME. This is useful if you have, let's say extension 1234 that maps to 9195551234 on the PSTN. It essenatially creates a mapping in CME so that when an external call (from PSTN/another VOIP gateway/etc) comes in with a 10 digit (or however many digit) extension it can map it down to a 4 (or however many) digit "internal" extension.

[maharris]

We just recently ran across this on an install, and the 'recommended' way is the same number on both phones, with the preference. We had wanted to use a different number on the second line to pull out for hunt groups, and had actually put our second ext number in the voicemail config as the E164 number, which allowed the call to be recognized. But, we had also configred dialplan-pattern, and that caused the message button and calls transfered from another extension to the primary ext to be expanded to the full E164 number, which was now overwritten by our second ext, so we could have accomplished what we wanted by using the full E164 number as our number on our second line (except they decided they didn't need hunt groups after all, so we went with recommended method). In the course of that, I wondered how my CM managed to handle the situation. Our first lines are configured with 4 digit ext, and the second lines with 1xxxx. I discovered that I could use the message button from either line, even with no mailbox or alt ext configured for that second number, and only 4 digits were actually getting sent over to Unity. Turns out it is the voicemail mask in the voice mail profile config, which we have set up for 4 digits. I also saw a posting here recently that said that that mask only seems to work with SCCP registered vmail systems, so won't work for CUE or QSIG integrations.

Mary Beth

[rywalker]

Thanks to everyone for taking the time reply. I will try the suggestions