locked
No matching rule has been found in the dial plan for the called number RRS feed

  • Question

  • I have a question here.

    I have a Polycom VVX311 and a Skype for Business client.

    If I call 5551234 on the Polycom VVX311, the call rings through just fine. I have a normalization rule ^.*555(1\d{3})$ that converts to $1. 1234 is successfully passed to the gateway.

    If I call 5551234 from the Skype client, I get "No matching rule has been found in the dial plan for the called number" 

    Also I see this in the logs:

    ms-diagnostics: 14010;reason="Unable to find an exact match in the rules set";source="FESERVER.DOMAIN.ORG";CalledNumber="1234";ProfileName="DefaultProfile";appName="TranslationService"

    It appears the number 5551234 is being normalized by the client to 1234 (based on the Dial Plan normalization rule), but at that point 1234 no longer matches a normalization rule. I have not seen this before. I understood that the Skype client will normalize a number before it sends it to the FE, based on the normalization rules that the client processes on login. At that point, the rule has been applied, so it does not try to "reprocess" the normalization rules on the server.

    If this is expected, it will certainly change how I understand this to work. I have to consider that all Normalization rules will hit twice. Once on the client end, before the number is sent, then once on the server.

    Can anyone confirm this behavior?

    Tuesday, August 15, 2017 6:32 PM

All replies

  • Hi Mr.Cross,

    Would you please tell us did the issue only appear on the specific SFB client?

    Did you check the Lync Configuration Information and verify that the user having problems is actually assigned the correct Dial Plan i.e. did the Lync client actually receive up-to-date in-band settings from the Front End correctly?

    I will share a document about how to create or modify dial plan for users, please refer to
    https://technet.microsoft.com/en-us/library/gg398909.aspx

    Hope this reply is helpful to you.


    Regards,

    Alice Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, August 16, 2017 6:02 AM
  • Yes, this only happened with the client - not the Polycom, even though it was the same account signing in.

    Yes, the client received the most current settings with all the normalization rules.

    There is only one dial plan - Global.

    Wednesday, August 16, 2017 9:47 AM
  • Hi Mr.Cross,

    Thanks for your response.

    You mean all users had this issue, is that right?

    If all users had the issue, please check if there are any event IDs in SFB application log, if possible, provide it for us to do further troubleshooting.


    Regards,

    Alice Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, August 21, 2017 9:25 AM
  • Yes, all users we tested had this issue and I was able to reproduce on my test account as well. There are no events in the Lync Server application log at the time of the failed calls.
    Monday, August 21, 2017 11:57 AM
  • What should the phone number be normalized to?  If it should be normalized to 1234, do you have a matching PSTN usage and route in the user's voice policy?  If it should normalize to something else, test the called number in the testing section of the dial plan settings in the control panel.

    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    Monday, August 21, 2017 5:05 PM
  • It should be normalized to 1234, and yes there is a PSTN usage and route for that.
    Monday, August 21, 2017 5:10 PM
  • Can you model it successfully using the "Test Voice Routing" tab?

    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    Monday, August 21, 2017 5:26 PM
  • Yes, the test tools work correctly (successfully), within the Dial Plan normalization, within the Voice Policy and within the Test Voice Routing.
    Monday, August 21, 2017 5:29 PM
  • Hmmm... Is this a specific dialplan?  Does it make a difference if you add the rule to the global dialplan?

    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    Monday, August 21, 2017 5:39 PM
  • There is only a Global dial plan.
    Monday, August 21, 2017 5:40 PM
  • If you dial 1234 alone does it work?

    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    Monday, August 21, 2017 5:51 PM
  • It does now, but before no, it did not, because it wasn't matching a Normalization Rule... But it shouldn't need to exist because the users are never going to dial "1234," so there wasn't a normalization requirement for it...
    Monday, August 21, 2017 6:02 PM
  • Are you resolved your issue ?
    Monday, August 28, 2017 7:10 AM
  • Only by adding a normalization rule that would hit after the normalization rules hit on the client side.

    I do not really believe this is the expected behavior, though.

    Tuesday, August 29, 2017 12:35 PM
  • Hi Mr.Cross,

    Did you mean that after you adding a normalization rule it has no issue?


    Regards,

    Alice Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, August 31, 2017 8:43 AM
  • Yes, but I do not believe this normalization rule should be required.

    The user dials 5551234. There is a normalization rule in the Global dial plan for -pattern ^5551(\d3)$ -translation 1$1, which hits.

    The call fails, and on the server it shows:

    ms-diagnostics: 14010;reason="Unable to find an exact match in the rules set";source="FESERVER.DOMAIN.ORG";CalledNumber="1234";ProfileName="DefaultProfile";appName="TranslationService"

    which tells me the normalization rule is hitting correctly, but somehow the client isn't "telling" the server that the number is already normalized.

    The rule I added that fixed this issue was -pattern ^(1\d{3})$ -translation $1

    This allowed the "1234" to pass through. But again, this means the actual number the user dialed hit the normalization rules TWICE. 

    Is that expected behavior?

    Thursday, August 31, 2017 12:47 PM