[cisco-voip] Fwd: Monitor Two VM boxes/extensions

Wed Oct 26 14:58:46 EDT 2011

You could setup 1510 as a call handler (or a normal box) but for which
the messages go into 1500 instead (instead of storing messages in the
1510 box, it just delivers the messages to 1500).  Main disadvantage is
that it would have two separate greetings, but it would work.

Matthew Ballard

Network Manager

Otis College of Art and Design

mballard at otis.edu

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of David Zhars
Sent: Wednesday, October 26, 2011 11:50 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Fwd: Monitor Two VM boxes/extensions

---------- Forwarded message ----------
From: David Zhars <dzhars at gmail.com>
Date: Wed, Oct 26, 2011 at 1:35 PM
Subject: Re: [cisco-voip] Monitor Two VM boxes/extensions
To: Lelio Fulgenzi <lelio at uoguelph.ca>

Yes 1510 is an alternate extension.  Yes, Unity is the auto attendant.
So I guess what you are saying is if someone calls in from the outside,
Unity gets the call (being the auto attendant), and it routes to the
"main" extension for that number being chosen....I think I am seeing it.
I see how that would be FAD, but

We wanted 1510 to be his "private" number.  I have set 1510 up as a full
fledged extensions, with it's own VM and all.  But that requires him to
login to two VM accounts, not what we want.

Is there no way to have this work like we want?  1500 always routes to
secretary, 1510 is callable from inside and outside and rings at 1510,
voicemail for both extensions is obtainable from one login??

Thank you!

On Wed, Oct 26, 2011 at 1:16 PM, Lelio Fulgenzi <lelio at uoguelph.ca>
wrote:

It's not strange. It's behaving as designed. ;)

Is 1510 an alternate extension on the 1500 voice mail box? You didn't
answer that part. By the sounds of it, you're using Unity/Connection as
the auto-attendant.

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it. 
                              - LFJ (with apologies to Mr. Popeil)

________________________________

From: "David Zhars" <dzhars at gmail.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca>

Sent: Wednesday, October 26, 2011 2:15:02 PM

Subject: Re: [cisco-voip] Monitor Two VM boxes/extensions

1500 and 1510 are extensions in UCM.  On his phone, 1500 is his primary,
1510 is secondary.  Internally if I ring 1510, it rings at 1510 on his
phone.  (If I ring 1500 it CfwdAll to his secretary, exactly as we
want).

Just strange that if you call in from the outside world, and enter 1510
at the "you can dial your extension at anytime" prompt, it rings at
1500, fwding to his secretary).

On Wed, Oct 26, 2011 at 1:11 PM, Lelio Fulgenzi <lelio at uoguelph.ca>
wrote:

If 1510 is an alternate extension on 1500 VM box, then that is working
as designed. Calls to alternate extensions will always ring the primary.

If this is not the case, you'll have to provide additional information.

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it. 
                              - LFJ (with apologies to Mr. Popeil)

________________________________

From: "David Zhars" <dzhars at gmail.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca>, cisco-voip at puck.nether.net
Sent: Wednesday, October 26, 2011 2:00:13 PM
Subject: Re: [cisco-voip] Monitor Two VM boxes/extensions

OK, so I am back with this issue!  Now I have another problem....

When you dial our main number from outside, and enter extension 1510, it
is ringing him on 1500.  Any reason what that would be?

Thanks.

On Mon, Oct 17, 2011 at 2:16 PM, Lelio Fulgenzi <lelio at uoguelph.ca>
wrote:

Another method to deliver 'secret' extensions is to use *XX codes via
translations. This way, you don't have special search spaces. Everyone
can dial the secret extension by dialing the prefix. Only the
translations need to have access to the secret partition. 

Sent from my iPhone

On Oct 17, 2011, at 3:04 PM, Chris Martin <clm.ccie at gmail.com> wrote:

	One solution would be to setup IP Manager Assistant (IPMA), it
has two different modes of setting it up you can find setup guides in
the UCM Features and Services Guide.  You could do a "fake" extension
through cti/dn and call forward all to the secretary but that has its
own downfalls.

	Another way would be through use of partitions and calling
search spaces.  Could create a 1500 DN for the secretary in an internal
partition, then a 1500 for manager in his own partition, which only mwi
and his secretary can call directly. That keeps from people calling the
manager directly, yet when they call 1500 it goes to the secretary.

	HTH,
	Chris

	On Mon, Oct 17, 2011 at 1:01 PM, David Zhars <dzhars at gmail.com>
wrote:

	I have a user, he has ext 1500.  But he gets a lot of calls, so
he CfwdAll to his secretary.  Then we made him a second extension, 1510,
so when she gets a call and he wants to deal with it, she can transfer
to 1510.  Of course if he doesn't answer it, then he has voicemail in
his 1510 box, as well as the ones the secretary forwards to 1500.

	Is there a nicer way to do this?  Can't I make 1500 sort of a
"fake" extension that will always ring at the secretary, and "John"
would only have to check 1510 for voicemails?  UCM 8.0 and Unity 8.0

	Dave

	_______________________________________________
	cisco-voip mailing list
	cisco-voip at puck.nether.net
	https://puck.nether.net/mailman/listinfo/cisco-voip

	_______________________________________________
	cisco-voip mailing list
	cisco-voip at puck.nether.net
	https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20111026/4bd77542/attachment.html>