locked
Performance Problem RRS feed

  • Question

  • Hello together,

    we have an performance problem with our Lync Server, everytime when we call someone we have to wait 10-20 seconds until we get a free tone.

    We have the newest Lync Client (280) and all server updates are installed, we communicate over an Ferrari Gateway, and in our enviroment we have a lync Server and an seperate edge server.

    With the Snooper I start to analysize a call and there is no error:

    07:20:02 Response successfully routed N/A N/A

    07:20:02 SIP/2.0 100 Trying lync@domain.com +49...

    07:20:07 (Out) SIP/2.0 200 OK

    07:20:18 SIP/2.0 180 Ringing

    It´s the short version of the Trace.

    Hope somebody can help :)

    Greetz

    Benjamin

     

     

     

     

    Monday, July 25, 2011 7:58 AM

Answers

  • Maybe the problem is resolved, the teamviewer on the edge listens port 443, and the edge needs this, deinstallated,

    Ports for A/V changed because of some issues with the IIS,

    now every service on the server starts and event log is clear, the performance is very high and federation call works fine

    so the tip with some edge problems seems to help, because the configuration was wrong there

    • Marked as answer by Benjamin1406 Wednesday, August 3, 2011 1:48 PM
    Friday, July 29, 2011 2:25 PM

All replies

  • I would investigate the logs from the server to the gateway and the gateway to the PRI to see where the delay is occurring. i.e. is the Mediation failing to send any SIP traffic for 11 seconds, or is the gateway failing to respond for 11 seconds, etc. You'll want to pinpoint who is responsible for the delay.

    I've seen this happen with NTP problems before, but it could also be a media negotiation issue.

    Monday, July 25, 2011 10:39 PM
  • Please verity your voice routing configuration is correct in Lync control panel.

    If the problem still exist, you can try to delete the gateway in lync topology builder and publish, then add and publish again.

    The following posts gives more answers about the question, hoping it can help you.

    http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/0c22ae53-7fb7-4e9c-bed9-858243373fed

    http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/bb5af214-6984-41b8-93a8-4b629fbc7494


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, July 26, 2011 7:51 AM
  • I have logged the gateway traffic today and there is everything ok, all calls are routed under 1 second.

    Also the routing configuration at the control panel seems to be ok, numbers are in the right format and first PSTN usage is the gateway.

    We have changed the gateway and publish the topology again, same problem.

    Thanks for your help

    Tuesday, July 26, 2011 2:40 PM
  • If you see the call entering the gateway within one second, all should be fine on Lync side.

    Do you see the gateway forwarding the call immediatly to the PSTN or is there a delay?

    • If you see the call going out to the PSTN directly, I would check with the telephony provider as the delay is due to the telephony provider not responding directly. You should trace the PSTN traffic and see what happens there
    • If you see a delay in the call going out to the PSTN, there is a configuration issue on the gateway.

    Technical Specialist Microsoft OCS/Lync & UC Voice Specialisation - http://www.uwictpartner.be
    If you think my post is the answer to your question, please mark it as answer so future visitors can easily find it.
    Wednesday, July 27, 2011 8:44 AM
  • Just out of interest do you have an edge server in your topology? I have a similar problem at 2 client sites. Calls to the PSTN and Lync to Lync (although to a lesser degree with lync to lync) have a long delay (depending on where you are 10 - 15 seconds). I trolled the logs back and forth, no errors, call setup all seemed normal. I did notice some ICE negotiation etc. Just as a test I removed the Edge servers from the topology on both sites. Calls connect within 2 seconds, give it a try and see what the outcome is.

    I am now investigating how I can improve the performence of the interaction with the Edge Server. It is important to note that both CAC for bandwidth policy and the generation of your candidates will look to the edge server. I will post back if I work out what exactly what causes this issue and if I come up with a way to resolve / improve.

    Friday, July 29, 2011 4:59 AM
  • Maybe the problem is resolved, the teamviewer on the edge listens port 443, and the edge needs this, deinstallated,

    Ports for A/V changed because of some issues with the IIS,

    now every service on the server starts and event log is clear, the performance is very high and federation call works fine

    so the tip with some edge problems seems to help, because the configuration was wrong there

    • Marked as answer by Benjamin1406 Wednesday, August 3, 2011 1:48 PM
    Friday, July 29, 2011 2:25 PM