[cisco-voip] MWI with overlapping numbers
Ryan O'Connell
Roconnell at unislumin.com
Sun Mar 11 22:01:02 EST 2007
Hi Justin
I would like to hear more about your comments you made about problems
with CTI and AC line status. How will this be a problem?
Also Dan, why introduce a Gatekeeper how will this help on a centralized
design, I'm not doing any intercluster trunks?
Ryan
________________________________
From: Dan Cavanaugh [mailto:dcavanaugh at gmail.com]
Sent: Friday, March 09, 2007 10:26 AM
To: Justin Steinberg
Cc: Ryan O'Connell; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] MWI with overlapping numbers
Total agreement with Justin. What you have done at this point is
introduced layers of translation and complexity that don't need to be
there. A nice design is exactly what Justin suggests below, with the
addition of a GateKeeper. The Gatekeeper will add the filter you need
to determine if an extension is on your cluster.
On 3/6/07, Justin Steinberg <jsteinberg at gmail.com> wrote:
You will notice other problems with this approach such as:
CDR issues since CDR is not partition aware
CTI issues
AC issues with line state updates
I think it would make life easier to use E164 numbers as the DN and use
translation patterns within each site to translate four digits to E164.
Just my thoughts, and I do realize making this conversion would be a
real pain. :)
Justin
On 3/6/07, Ryan O'Connell < Roconnell at unislumin.com
<mailto:Roconnell at unislumin.com> > wrote:
Fixed it
The fix was to change the MWI CSS to search the translation
Table instead of each sites local partition. And to change the MWI
notification in Unity back to "X"
Ryan
________________________________
From: cisco-voip-bounces at puck.nether.net on behalf of Ryan
O'Connell
Sent: Tue 3/6/2007 3:07 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] MWI with overlapping numbers
Hey all,
I'm stuck on this one. Here is the scenario.
IPT customer, with lots of phones. They are using a Centralized
model where CallManger and Unity are at the head office providing
services for head office and all branch locations. This is a big
customer and DN overlapp is a real issue so they decided they wanted to
go 4 digit dialing within a given site, and 10 digit dialing between
sites.
No problem
* I setup each location with a different
<sitename>Oncluster Partition and added 4 digit DN's to these
partitions.
* phones can dial each other using 4 digits within a site
* when they dial another site the must dial 11 digits.
example to dial Edmonton they dial 917808885180
* A translation pattern is used to strip the pattern and
search the correct sites partition then strip the 91780888 off the
number leaving 5180
* For centralized voicemail, I used different
"VoiceMailProfiles" to prefix the numbers going into Unity so when
someone from Edmonton dials into Unity 780888 is prefixed to the 5180
putting them into the correct mailbox.
* To light MWI lamps, I had to turn Multitenant Mode on so
that VM Ports can see the translations created and all works fine
HERE is the problem
* When someone has the same last 4 digit dn's at different
sites, MWI only works for the site who's partition comes first in the
MWI CSS
Example Calgary phone with DN 4035555180 and an Edmonton Phone
7808885180
* Unity mailbox are as follows Calgary user is 4035555180
and the Edmonton User is 7808885180
* both message notification feilds under each subscriber
have been changed from the default X to 5180 because the actual
extension is only 4 digits not 10 (I THINK HERE IS MY PROBLEM BUT DON'T
KNOW HOW TO FIX IT)
* I leave a message for the Edmonton user
* MWI outbound ports use the Translation pattern to
translate 7808885180 to 5180 in the edmOnCluster partition. And tell the
phone to dial the lamp code
* The MWI-ON CSS has partitions in the order of
cgyOncluster - then edmOncluster. It doesn't know better it just matches
5180 to the cgyOncluster and the lamp turns on.
I know you may need a decoder ring to understand this email, but
any help is appreciated
Ryno
________________________________
Privileged/Confidential Information may be contained in this
message. Disclosure to any person other than the named recipient is
unauthorized. If you are not the intended recipient, please delete all
copies of this information and kindly notify the sender by reply email.
Opinions, conclusions and other information in this message that do not
relate to the official business of UNIS LUMIN Inc. shall be understood
as neither given nor endorsed by it. UNIS LUMIN Inc. and any of its
subsidiaries reserve the right to monitor all e-mail communications
through its networks. Thank you.
_______________________________________________
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
--
Dan Cavanaugh
dcavanaugh at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20070311/166368f2/attachment-0001.html
More information about the cisco-voip
mailing list