locked
Beginner question: Purpose of the normalisation rule. RRS feed

  • Question

  • Hi folks,

    I'm new to the PSTN side of Lync and I'm running into what may or may not be an issue that has me curious as to the ultimate purpose of normalisation rules.

    To begin with, I thought the purpose was to take a number in any given format and produce out the other side a number format useful to your PBX configuration. To use an example, our Avaya CS1000 only routes our four digit extensions internally while the full local or international equivalents actually dial out then back in (doesn't make sense to me, but that's how the consultant put things in place; I would have thought all variants should have been captured internally).

    Because of this, I created the normalisation rules to take the number in either international, local or extension format and normalise those into extension format. If you're wondering why bother with the last case, it's because depending on the first digit the extension is being routed to a different CS1000.

    That all seemed fine insofar as if I test a number within either the normalisation rule or associated dialling plan, all the formats are "correctly" normalised to the four digit extension. However, when I then use the "Test Voice Routing" component of the Lync control panel, I find that internationally formatted numbers (including the leading +) do not match the relevant normalisation rule, and by that I mean it gives me the impression it's not even trying.

    That leads me to think perhaps I've totally misunderstood the purpose of the normalisation rule. Whereas I assumed it was a means to formatting numbers in a manner useful to us, I'm now wondering if its sole purpose is to produce E.164 numbers?

    If that is indeed the case then that's fine, it just means what we really need to do is get our CS1000 correctly configured to also accept internally dialled international and local variations of our internal range and route those the same was as the current extension dialling. Actually, there will be more knock-on effects than that, but the point is the CS1000 will be the focal point, not Lync.

    If someone can confirm whether my first or latter (or neither) assumption about the purpose of normalisation rules is correct?

    Cheers,
    Lain

    Friday, November 18, 2011 12:03 AM

Answers

  • This post clarified why I'm seeing the discrepancy between the Dial Plan test and the Voice Routing test.

    Cheers,
    Lain

    • Marked as answer by Lain Robertson Friday, November 18, 2011 9:14 AM
    Friday, November 18, 2011 9:14 AM

All replies

  • HI,

    Sole reason for the normalization rule is not only to convert dial numbers to E.164 format. It can be used to manipulate numbers the way you want them to be. If you want to send 4 digits to PBX you can use normalization rules to do so and as well as the full local and International number range. Ckeck the below technet article about the normalization rules and Dial plans.

    http://technet.microsoft.com/en-us/library/gg413082.aspx

    If you can paste the normalization rules that you created with the purpose of them, we should be able to assist you if there's any thing missing there.

    Thamara.

    Friday, November 18, 2011 12:49 AM
  • Thanks for the reply, Thamara. At least that answer verifies my thought process wasn't completely wrong. I'll try and lay out our environment as best I can along with what we're trying to achieve.

    Our objective

    Initially, we want to establish the ability for Lync users to be able to call our Avaya 1230 VoIP handsets. Given we don't run ACE, from what little we understand we don't have the ability to establish the reverse scenario, where handsets can dial Lync users, so we're leaving that out of scope for the time being.

    Our VoIP configuration

    We have three primary campuses, which I'll just refer to as Site A, B and C. Because we're in Australia, our international format is

    +61 Our international code
    8 Our area code. Technically, it has a 0 in front of it when it's just dialled as a local number, but this is dropped when formatted internationally.
    12345678 All Australian "normal" landline numbers have eight digits, meaning our campuses all conform to this convention.

    Historically, we weren't VoIP campuses, which meant we had to introduce a "fake" prefix to differentiate between two of our campuses. As such, our internal extension dialling looks like this:

    2xxx Campus A. This campus originally shared a common fourth digit with Campus B before VoIP was established nationally.
    3xxx Campus B. This campus originally shared a common fourth difit with Campus A before VoIP was established nationally.
    4xxx Campus C. The fourth digit for this campus was always "4", so nothing needed to change when VoIP was established nationally.

    When a user dials the four digit extension, the PBX looks a the first digit and routes the call to the relevant PBX. It's worth noting that Campus A and B use the same PBX, while C has its own.

    As mentioned in the first post, when a user dials the full international or national version, they route outside to the PSTN then back in.

    Active Directory

    Currently, we are only starting to explore the PSTN integration side of things, so only two of us are enabled for Enterprise Voice. We both have the internationally formatted phone numbers as our URIs, i.e. +61811110222, +61811110223 - twelve digits in total.

    Lync

    Routing

    Site A does not own the entire public four digit range, so we have a number of rules like the following: +618111102[0-9]{2}. We also have a rule for matching the appropriate four digit extension range. Here's the actual rule (with a bogus "1111" used after the +618 to hide our real numbers):

    ^((2[0-9]{3})|(\+618111101[0-9]{2})|(\+618111102[0-9]{2})|(\+618111105[0-9]{2})|(\+618111106[0-9]{2})|(\+618111107[0-9]{2})|(\+618111108[0-9]{2})|(\+618111109[0-9]{2}))

    This routes through Gateway A and for namesake I'll refer to it as Route A.

    Site B is a similar story. It does not feature in the above routing rule yet since we're not at the stage of needing to test dialling inter-campus. It also will route through Gateway A.

    Site C has it's own routing rule since it has its own CS1000 (let's call it Gateway C), but again, we are not yet testing across campuses so it's irrelevant for now.

    Voice Policies

    For now, we simply have Voice A which leverages Route A (and therefore Gateway A).

    Dialling Plans

    Dialling Plan A contains two normalisation rules: one for internationally formatted addresess - as per our URI values mentioned above, and the other being to simply match our four digit extensions - though I'm unclear if I even need this one given it's not changing anything. Both normalisation rules were designed to output the four digit extension, for which the CS1000 is already configured to route internally.

    Just to reinforce the point, the reason I need the normalisation rules to always return a four digit extension is because national or international numbers of any kind are routed out to the PSTN before being bounced back in, which obviously then incurs a local call cost.

    Summary

    So, that's about as thorough a layout as I can give for our environment and what we're looking to achieve.

    The main problem I'm trying to wrap my head around is that because we store the full international number in AD and when I run this format through the "Test Voice Routing" feature it comes back with no matching normalisation rule, I'm worried that we will be sending calls out to the PSTN rather than calling internally.

    I'm guessing the best solution is to bring a consultant back in to "fix" our CS1000 implementation, but if Lync can simply normalise everything to four digits then that's enough of a work-around for now.

    Cheers,
    Lain

    Friday, November 18, 2011 2:53 AM
  • I read another post which was handy in that it highlighted the fact you don't need to use the builder to create the regular expression. With that in mind I've changed the above normalisation rule (for Campus A users) to be as follows:

    Regular expression   ^\+61811110([1,2,5-9])(\d{2})$
    Translation rule 2$1$2

    That said, I still have the same problem where if I test the rule with a dialled number in the "Edit Dial Plan" screen it produces the correct extension, but if I run the same test in the "Test Voice Routing" section it does not match any normalisation rules.

    Cheers,
    Lain 

    Friday, November 18, 2011 6:54 AM
  • This post clarified why I'm seeing the discrepancy between the Dial Plan test and the Voice Routing test.

    Cheers,
    Lain

    • Marked as answer by Lain Robertson Friday, November 18, 2011 9:14 AM
    Friday, November 18, 2011 9:14 AM