[cisco-voip] MWI with overlapping numbers
Dan Cavanaugh
dcavanaugh at gmail.com
Tue Mar 13 14:34:04 EST 2007
Ryan,
-Yes each location has there own customized translation pattern to
expand a 4 digit call to a full 10 digit extension.
- Funnny you should ask. No I don't like to send the @ route to the
GateKeeper. I like to be more specific. I have been thinking of adding
that to the design but I would prefer to perform more testing. I would love
to finally be able to bring up my missed call log, see a missed call from an
E164 number, hit the dial key and have it route the call correctly. The
typical user doesn't like to see the prepended 91 in their call logs. I
agree.
-Wow you have put a lot of thought into your dialplan, good for you. I
only configure zones for DID numbers. The sites operate just as you
described. I put non DID extensions into a seperate partition. Then give
them a fake E164 number beggining with a 1. 111.901.4567. The remainder of
the number can mirror the DID(s) for the site. You want to plan ahead to
make sure you will never have overlap in Unity. CallManager ois finished
here.
-Centralized Unity just works. No translations, no masks. The CSS for
Unity includes all SITE-DID partitons as well as SITE-NonDID partitions.
There is no overlap so Unity is capable of sending MWI On/Off as well as
transferring to all extensions. This also serves as a back door transfer to
non DID extensions.
-CAC is used here. The LOCATIONS in CallManager are enforced and you
have additional bandwidth policing at the GateKeeper.
Everything just works!
On 3/12/07, Ryan O'Connell <Roconnell at unislumin.com> wrote:
>
> Dan,
>
>
>
> I like it, very slick. Thank you for putting such detail in your response
> as well. I hope you don't mind me asking a few more questions I'm intrigued
> now. Besides I'm still early in the design phase and you may sway me to
> alter my plans.
>
>
>
> - In your design you have all your internal DN's set to be E.164numbers. Are you using some sort of Translation patterns at each of the
> sites to maintain 4 digit dial within a given site?
>
> - I don't have a lot of experience with Gatekeepers so let me ask
> you this when using a Gatekeeper controlled trunk is it just one route into
> CallManager like a default route? Using your example: User dials
> 91.6025028867, the RG-1 strips predot and sends it to Gatekeeper. I assume
> there is a default route command that sends all 10 digit numbers to CCM.
> Once it gets there since the Trunks Inbound CSS has all "SITE_EXTENTIONS"
> partitions so therefore the call completes.
>
> - What about non-DID's at remote sites do you have them in another
> partition or something that the Gatekeeper can't see? Example at your remote
> site you don't use DID's so do you still assign them a E.164 number? What
> happens if that E.164 number is an actual number for MacDonalds at that
> remote location but it happens to be the same number that you assigned to a
> non-DID at the remote location?
>
> - What about voicemail, I'm not sure if you're using centralized
> voicemail with Unity but that is what I'm using. How are you handling Trap
> connections and MWI for remote locations? Do those outbound Unity ports have
> the same CSS that you applied to your Gatekeeper controlled trunk?
>
> - With your design are you still using CAC?
>
>
>
> Aren't Dialplans fun!!
>
>
>
> Cheers Ryan
>
> ------------------------------
> *From:* Dan Cavanaugh [mailto:dcavanaugh at gmail.com]
> *Sent:* Mon 3/12/2007 6:33 PM
> *To:* Ryan O'Connell
> *Cc:* Justin Steinberg; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] MWI with overlapping numbers
>
>
> The GateKeeper helps you perform a basic translation. The way I have it
> configured is each site on the network uses (2) route lists, SITE-RL and
> SITE-GK-RL. All local route patterns, local 7 digit, 911, etc. use the
> SITE-RL which points to the local VG. You are done there. Any
> 91.[2-9]xx[2-9]xxxxxx dial pattern is routed to the SITE-GK-RL. Keep in
> mind that ALL your extensions at all sites are the full E164 number,
> 6025028867. A user dials 91.6025028867, not knowing if this number is on
> your network or a local McDonalds. The SITE-GK-RL consists of (3) route
> groups and does the following:
> (RG-1) Strip the preDot and send it to the GateKeeper. The GateKeeper
> will maintain ranges of extensions available on the CallManager cluster or
> multiple clusters(60250288..). The GateKeeper controlled trunks to
> CallManager will have a CSS that has access to all SITE-EXTENSIONS
> partitions. If the 10 digit number matches a defined range on the
> GateKeeper, the call is placed ON-Net. If this request fails, --> RG-2.
> (RG-2) Send it to GateKeeper. The GateKeeper will maintain a list of
> 91xxx....... routes. The xxx will be the local area code for each gateway
> registered to GateKeeper. If the GateKeeper has a gateway registered for
> 91602......., the call will be routed to a gateway on the network and the
> call will be placed as a local call. If there is not a registered gateway
> with the 91602 zone defined, -->RG-3.
> (RG-3) Finally send the call to the local VG as a long distance call.
>
> You said you weren't doing any intercluster trunks. The only trunk needed
> would be to the GateKeeper. It would take place of your CSS and PT
> manipulations. This is very modular and scalable in design. It also allows
> you to just plug in another site(or company) overnight without further
> thought about overlapping dialplans. Users don't need to be notified about
> dialing rules for ON-Net vs. OFF-Net calls, they just simply call each other
> the same way they always have. What it does not accomplish is the silly
> abbreviated dialing between sites. Everyone would love to dial across the
> nation using only 4 digits. This is a pipe dream and you will spend many
> nights undoing what you thought would scale for your company.
>
>
>
>
> On 3/11/07, Ryan O'Connell <Roconnell at unislumin.com> wrote:
> >
> > 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> 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
> >
>
>
>
> --
> Dan Cavanaugh
> dcavanaugh at gmail.com
>
>
--
Dan Cavanaugh
dcavanaugh at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20070313/8b0f432d/attachment-0001.html
More information about the cisco-voip
mailing list