[cisco-voip] FWD one Ext to Another

Ryan Ratliff rratliff at cisco.com
Mon Jan 14 11:06:07 EST 2013


>  I assumed (there's that word) that applying 1212 as an alternate ext to 1702, would mean the user would STILL have to login SEPARATELY to both VM boxes to get messages.

The use of an alternate extension is for the case when there is only one mailbox in Unity, with two extensions that could be calling into it (forwarded or not).  

-Ryan

On Jan 13, 2013, at 12:22 AM, Erick B. <erickbee at gmail.com> wrote:

Yes, in unity add 1212 as alternate extension to the 1702 users mailbox and any calls for 1702 or 1212 will go to that users mailbox. The ** transfer method will still work with this to (assuming the ** pattern sends call those calls to voicemail directly on your setup)

I would use a translation pattern on CUCM to route calls from 1212 to 1702 unless you need to keep 1212 on a phone/etc for some reason. 


On Fri, Jan 11, 2013 at 6:49 PM, David Zhars <dzhars at gmail.com> wrote:
So my confusion has to extend from not having a solid understanding of an "alternate extension" in Unity.  I assumed (there's that word) that applying 1212 as an alternate ext to 1702, would mean the user would STILL have to login SEPARATELY to both VM boxes to get messages.  Are you saying that if I add 1212 as an alternate, he needs only check messages for ext 1702, and anything that went to 1212 would be in the 1702 box??  Cause that would be way easy!



On Fri, Jan 11, 2013 at 4:21 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
A translation pattern is one option, the other is a DN for 1212 (not assigned to a phone) with CFA set to 1702.  You'll want to test your usual call flows so that the fact that every call to 1702 will be a forwarded calls.  For example if you have any calling party selections on outbound gateways set to 'first redirecting number' you may end up seeing 1212 instead of 1702 as the calling party number.   Calls that end up in voicemail will also be sent to the mailbox of 1212.  

The routing rule in Unity would basically be: Any redirected call with an original called party number of 1212, send it to standard greeting for 1702.   I bet you could also just ad 1212 as an alternate extension for 1702 and you'll be set.

-Ryan

On Jan 11, 2013, at 2:51 PM, David Zhars <dzhars at gmail.com> wrote:

OK, here's my dilemma.  1212 doesn't exist as far as UCM is concerned.  I suppose I could recreate it as a CTI Route point??

Ryan, not sure what you mean about Unity sending calls from 1212 to 1702.  

Sounds like a translation pattern in UCM may be the way to go, delete the 1212 mailbox in Unity, so if someone does try and transfer a call to that VM  it would error out.  

While I want this to be easy for the end users, I also want it to be easy for me!


On Fri, Jan 11, 2013 at 2:28 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
Unity call routing rule to send calls from 1212 to 1702, should be pretty straight forward. 
-Ryan

On Jan 11, 2013, at 1:32 PM, David Zhars <dzhars at gmail.com> wrote:

Old user had ext 1212 (and this is a DID, so people can call directly from the outside).
New user has ext 1702.

What I want is:

Internally: User dials 1212, phone rings at 1702.
Internally: Reception takes a call, transfers it with TRANS **1212 TRANS, call goes to 1702 voicemail.

Externally: Someone calls 555-1212 and the call lands internally at 1702.

Some of this I know how to do, I am not sure about the transfer to voicemail of the old extension and have it land at the new ext VM.

Appreciate any help!

Dave

UCM 8.0, Unity 8.0


_______________________________________________
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/20130114/8e270105/attachment.html>


More information about the cisco-voip mailing list