Normalization rule works once, then fails RRS feed

  • Question

  • I have a set of normalization rules to handle 4 ranges of 4 digit extensions

    The rules are as follows:
    ^(8\d{3})$ Normalizes as +1555555$1
    ^(42\d{2})$ Normalizes as +1222222$1
    ^(43\d{2})$ Normalizes as +1333333$1
    ^(44\d{2})$ Normalizes as +1444444$1

    All rules except for the 8xxx work reliably as expected.
    The 8xxx rule has a very odd behavior - extensions matching it will normalize once, then fail.

    For example, I dial 8181. It normalizes to +15555558181. I complete my call to that number, hang up, then have to call it again. I type 8181 in the MOC, and this time, instead of normalizing, it returns "No results found". I have to quit the MOC and reopen it to get the normalization rule to work again.

    This only happens with the 8xxx rule.
    It is consistent in that it will normalize one time, then return "No results found" on subsequent attempts to normalize.
    This happens on multiple clients.

    I'm baffled.

    Anyone have ideas of why this is happening & how to remedy?
    Thursday, June 18, 2009 9:15 PM

All replies

  • Are you seeing any difference if you do it like this?
    ^8(\d{3})$ Normalizes as +15555558$1
    ^42(\d{2})$ Normalizes as +122222242$1
    ^43(\d{2})$ Normalizes as +133333343$1
    ^44(\d{2})$ Normalizes as +144444444$1

    - Belgian Unified Communications Community : http://www.pro-exchange.be -
    Friday, June 19, 2009 12:06 PM
  • Thanks
    I'm checking this

    Can you explain why this might work instead of including the constant in the regex sampled value?

    I've seen odd behavior out of the MOC normalization on a few occasions. It seems like the regex evaluation engine in the MOC is a little buggy. Is that true? Maybe it needs a little more testing?
    Friday, June 19, 2009 3:19 PM
  • I tried this change to no effect

    I'm collecting debug logs from the client. Maybe I'll see something there...
    Friday, June 19, 2009 5:11 PM
  • I have never seen any Normalization issues not honoring the Rules.
    What version are you running?
    Have you applied the latest fixes?
    - Belgian Unified Communications Community : http://www.pro-exchange.be -
    Monday, June 22, 2009 8:43 AM
  • Hi,
    It could be either the client or the server. To eliminate the server, my suggestion is to download and install the OCS R2 Resource Kit utilities on the front-end server. This will give you a utility called "Enterprise Voice Route Helper".

    You can enter in a "dialed number" like 8181, select a policy & location profile, then simulate dialing the number. It will show you which normalization rule it matches, along with which route it will take (or which user's extension it matches).

    This utlitity is really helpful for diagnosing normalization rule issues on the server side. Even if it doesn't solve your issue here, it's a good resource to know how to work.

    But if I had to guess, it sounds like your problem has more to do with the client. You shouldn't really ever see it work once and then not again. What version of the MOC client do you have running? I would definitely make sure it's current on patches.


    Matt McGillen, PointBridge - https://blogs.pointbridge.com/Blogs/mcgillen_matt/default.aspx
    Friday, June 26, 2009 3:39 PM