locked
Lync Voice Routing changes - not updated RRS feed

  • Question

  • I have recently been performing a number of dial plan changes in a Lync 2010 configuration and after each dial plan change I ran a test case in the dial plan section to see if the change was working ok ... all appeared fine. After ensuring I had commited any changes I went to test the voice routing from alive system. However, I then ran into issue as the change didn't have any impact and only after performing the following did the change kick in:

    1 - Restart mediation server
    2 - Logout and back in of Lync client

    Anybody else come across this? It there a replication issue from FE to the co-located mediation server?

    Thanks

    Jed

    Wednesday, December 22, 2010 1:34 PM

All replies

  • You should only have to completely exit the Lync client and restart it.  Or wait for the client to download the changes to the dial plan
    Mark King | MVP: Lync Server | MCTS:UC Voice | MCSE: Messaging | MCITP:Enterprise Messaging | www.unplugthepbx.com
    Wednesday, December 22, 2010 2:52 PM
  • OK, I'll have to try again to see that I tried that combination as I didn't fully know the logic of how the normalisation takes place. I assume this means normalisation actually takes place on the client via the downloaded rules and not on the server . Any idea how long it takes before the client downloads the dial plan updates?

    Thanks

    Jed

    Wednesday, December 22, 2010 4:28 PM
  • Hey Jed,  I don't know the exact time...but it is about 5 minutes.  In the documentation on technet, it says to allow 5 minutes for changes to take place.  I'm like you....i want changes immediately, so I start popping services and restarting the client as well trying to speed it up. 
    Friday, December 24, 2010 1:03 PM
  • i have a similar issue

    normalization and routing are two different things - routing should take place immediately i would think

    i'm having some issues with voice routes that tests OK however actual call routes different

    i have two media gateways one towards a PRI and one towards a PBX

    i changed a route from going from the PRI to the PBX

    i have even fully restarted both front ends with the co-located mediation (these are load balanced)

    this is nuts - the system is in production and i can't just restart servers and mediation services willy nilly to get a routing rule changed

    i have also tested using full E.164 numbers so i'm not relying on any normalization

    wouldn't routing information be obtained from the frontend or mediation server for the client? or is the client still relying on the downloaded cached info on the client side like the downloaded GAL.

    regardless of the softphone i also tried from an IP phone

    opened a case with MS - update to follow on this one

    Jens


    Monday, December 17, 2012 9:49 PM
  • Jens,

    When you are making changes are you ensuring that replication is taking place properly? I have hit issues where even what you would consider to be a local change is blocked due to repliaction failing. Even if you run the powershell or contral panel changes directly on the FE/SE server, the change still has to go through the replication process. Replication can be broken in different ways, the one instance I had was the file share permissions being corrupted,

    Jed


    Jed Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Tuesday, December 18, 2012 8:07 PM
  • Jens,

    When you are making changes are you ensuring that replication is taking place properly? I have hit issues where even what you would consider to be a local change is blocked due to repliaction failing. Even if you run the powershell or contral panel changes directly on the FE/SE server, the change still has to go through the replication process. Replication can be broken in different ways, the one instance I had was the file share permissions being corrupted,

    Jed


    Jed Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Tuesday, December 18, 2012 8:07 PM
  • Jens,

    When you are making changes are you ensuring that replication is taking place properly? I have hit issues where even what you would consider to be a local change is blocked due to repliaction failing. Even if you run the powershell or contral panel changes directly on the FE/SE server, the change still has to go through the replication process. Replication can be broken in different ways, the one instance I had was the file share permissions being corrupted,

    Jed


    Jed Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Tuesday, December 18, 2012 8:07 PM
  • By the time MS finally called me i had found the issue and rectified it myself.

    The changes actually did take place i was just looking there first since i'm running multiple load balanced front ends and testing from an outside client thru edge servers etc...

    we all know how "expeditious" Lync can be on updating configuration changes - he he

    Here was the actual issue i was dealing with

    I did find that the Voice Routing Test engine would allow and test full regular expressions with \d{2}  or  [0-9]  

    However the actual Voice Routing engine itself only runs on pre-fixes

    Threw me for a loop until i stopped using real regular expressions in my routing patterns

    Jens

    Tuesday, December 18, 2012 8:25 PM