[cisco-voip] MWI with overlapping numbers

[Dan Cavanaugh]

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> 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/20070309/eb4b9c2a/attachment-0001.html