[cisco-voip] FWD one Ext to Another

Erick B. erickbee at gmail.com
Sun Jan 13 00:22:27 EST 2013


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/20130112/256e1edf/attachment.html>


More information about the cisco-voip mailing list