locked
Calls to PSTN gateway failing after installing latest Lync patch KB2502810 RRS feed

  • Question

  • I have recently applied cumulative lync updates that got released in April on my Lync server lab setup.

    After these installs , connectivity between PSTN and mediation server has gone down.

    I uninstalled  all the update patches from the FEs but still there is no change and I am facing the same issue.

    On Event viewer of FEs I get an error " The Gateway peer, is not responding to an OPTIONS request sent by the Mediation Server service
    Cause: The Mediation Server service cannot communicate with the Gateway Peer Service over SIP due to network connectivity issues. "

    Has anybody been able to successfully remove these patches ?

    Before uninstalling the patches , I had upgraded my mediation server alone using a .msp file. Since that is not a patch , I am not able to remove that from FEs , Can i uninstall mediation server component alone and install it back?

    If I am not able to get it working , i might have to re-install the complete setup.

    Any help would be much appreciated.

     

    Friday, May 20, 2011 3:11 PM

Answers

  • I have recently seen and resolved this issue with a customer today.

    The software version of your NET VX gateway needs to be up to date. 4.7.5v19 is suitable for the Lync CU2.

    Jim

    • Proposed as answer by Jim002 Wednesday, June 1, 2011 8:49 PM
    • Marked as answer by Lync user Wednesday, July 27, 2011 10:52 AM
    Tuesday, May 31, 2011 7:11 PM

All replies

  • ..." The Gateway peer, is not responding to an OPTIONS request sent by the Mediation Server service
    Cause: The Mediation Server service cannot communicate with the Gateway Peer Service over SIP due to network connectivity issues. "...

    As stated, check for network related issues. What type of PSTN connectivity you use at present?

     

    Drago


    http://www.lynclog.com
    Friday, May 20, 2011 3:20 PM
  • Hi

    In CU2 (aka april patches) Microsoft changed how calls are handled when the pstn gw is marked as down and not configured correctly.

    Uninstall CU2 from the mediation server reconfigure your PSTN GW and make sure that you don’t have any errors in the mediation server event log before you reapply CU2

    Please check this post for some further info on this

    http://www.ultimate-communications.com/2011/05/interoute-one-siptrunks-and-lync-cu2-update-is-a-no-go-for-now-lync-interoute/


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter
    Friday, May 20, 2011 3:35 PM
  • Hi Tommy,

    Thanks for the info . After removing the patches , i deleted all events , deleted dial plans from control panel . I added my gateway again and re-published topology but it doesn't seem to help.

    I am using port 5068 on mediation pool and 5060 on my PSTN gateway . I tried running both on 5060 and 5068 as well but that also did not help.

    Removing patches has also corrupted the ApplicationHost config file on my IIS server , I edited that manually and configured certificates again and cerrtificates atleast worked.

     

    Please let me know , if you can think of any other solutions.

     

    Best Regards

     

     

    Friday, May 20, 2011 5:46 PM
  • Ok, one by one.

    I am sure you know that, but just in case, I will ask - after changing listening ports of the mediation server and publishing the topology, do you restarting Mediation Service? As with OCS, Lync does not support "dynamic" listening port change. The service must be restarted (which invokes STOP (listeners down) and then START (listener UP) using the new port. Simply by re-publishing the topology, your test is not relevant.

    Your provider must have supplied "Trunk provisioning" letter, which typically includes SIP signaling and Media parameters (ports, protocol etc.) Examine such or contact the provider to obtain this information.

    Tommy already discovered that there is a problem with CU2 and Interoute. If you tell us who is your provider, others might also benefit from the knowledge later when the problem is resolved.


    Drago
    http://www.lynclog.com
    Friday, May 20, 2011 6:24 PM
  • Just to add to this topic title. I recently did a deployment in which the customer installed this update on a collocated Mediation server that was routing PSTN calls to an NET gateway and the same problem occurred. It appeared that restarting the Mediation service would temporarily resolve the issue but within 5 minutes outgoing calls would fail again.

    Ultimately, uninstalling the mediation server patch resolved the issue but it took me sometime troubleshooting before I found this thread and started looking into the patch as the cause of the issue. 

    Saturday, May 21, 2011 1:28 AM
  • Hi Marc,

    I am also using a NET gateway. The problem is not with the gateway as it was working fine before. I tried removing only mediation patch and restarted mediation services but this does not resolve my issue.

    I then un-installed all the patches that came with CU and restarted My FES but it still throws the same error in event viewer.

    Infact , removing these patches had added some duplicate entries in my applicationhost.config files in IIS .  Incase any one faces the issue, resolution is listed here

    http://support.microsoft.com/kb/2500441

    Since i was not aware of patch  issue , i had upgraded my Mediation server as well before removing the patches . Now i am not able to move my mediation back to a previous version,  could that be causing the issue in my case ?

    I am looking for these 3 answers to figure out my next steps.

    • I am seeing 200 Ok being sent by my gateway to FE but mediation claims that it did not receive it . How do I troubleshoot this ?  Do MTLS play any part here?

             I sniffed at FES and confirmed  that TLS is up between gateway and Lync . Also , forgot to mention that my PSTN to Lync calls are perfectly working.

    •  Can  I downgrade my Mediation server to preious version ? Installed upgrader does not give me that option . If i try to remove it , it would remove the complete mediation component
    • Can I un-install all  FES without touching AD and SQL boxes and get this thing up ? 
    Saturday, May 21, 2011 3:23 AM
  • Yes Drago, I restarted Mediation services on all FEs . Infact , my mediation takes a while before going down so I am able to make 1-2 calls and then mediation goes down again.

     

     

    Saturday, May 21, 2011 6:47 AM
  • Hi again

    I just want to add some to this, i had separate mediation servers and there is a lot easier to uninstall the CU2 patch then, as stated above uninstalling patches can screw stuff up :(

    On tip can be to remember to do restarts after you config stuff, and to rerun local setup.

    Inbound call always work but it’s only the outbound calls that will not work and after 5 minutes from a service restart when the GW is marked as down, this can be found in the event log.


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter
    Saturday, May 21, 2011 8:35 AM
  • Indeed, this tread concerned me and I double shacked my lab and production env. In production, I use standalone mediation currently connected to Broadvox directly (Mediant 1000 MSBG-SBC will be deployed next week), while the lab co-located Mediation via Medianet 800 MSBG-SBC to Broadvox as well. Both have CU 2 (applied day or two after the release) and we have not experienced the behavior described above.

     

    Drago
    http://www.lynclog.com
    Sunday, May 22, 2011 1:23 PM
  • Hi Drago.

    Good luck for you :D

    but its dependant on how your GW or siptrunk sends out the answers so this only happens in some rare cases.


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter
    Sunday, May 22, 2011 1:53 PM
  • Tommy,

    I just wanted to contribute to the knowledge base we are building here, that's all :-)

     

    Drago


    http://www.lynclog.com
    Sunday, May 22, 2011 2:04 PM
  • hehe i know.

     


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter
    Sunday, May 22, 2011 2:16 PM
  • Is there a chance that mediation server does not accept some kind of OK response to OPTIONS request? It may also be related to handling of TCP sessions for TLS. There are differences whether TLS/TCP session used for OPTIONS established by mediation server continues and is also used by the gateway to send OK response or the response is sent by trying to establish a separate inbound TCP/TLS session. This may complicate things a bit.
    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Sunday, May 22, 2011 3:13 PM
  • Yes this is actually exactly the case with Interoute, they do send back the response but in a wrong format.
    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter
    Sunday, May 22, 2011 3:15 PM
  • Can you post such a response and show which details is wrong? Just being curious - will compare it to the response our Ferrari electronic OfficeMaster gateways send.
    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Sunday, May 22, 2011 3:17 PM
  • The FROM header in the 200OK responses to OPTIONS is wrong.

     

    This is what Mediation Server sends:

     

    From: <sip:193.142.141.62:5060;transport=Tcp;ms-opaque=a608f2b222a0b01b>;epid=35D712543B;tag=427678421c

     

    This is the answer:

     

    From: <sip:193.142.141.62:5060;ms-opaque=a608f2b222a0b01b;ms-opaque=a608f2b222a0b01b>;tag=427678421c;epid=35D712543B

     

     

    That’s why Mediation Server discards the answers from the other end.


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter
    Sunday, May 22, 2011 3:20 PM
  • Ah, I see!

    Off-topic: how did you manage to use HTML in your signature?


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Sunday, May 22, 2011 3:23 PM
  • Hi Marc,

     

    Just curious , what is the release and build of NET gateway that you are using.

    Also , what is the version of  Lync server release bits ? Is it trial version or MSDN subscription ?

     

    Best Regards

     

    Wednesday, May 25, 2011 6:23 PM
  • The FROM header in the 200OK responses to OPTIONS is wrong.

     

    This is what Mediation Server sends:

     

    From: <sip:193.142.141.62:5060;transport=Tcp;ms-opaque=a608f2b222a0b01b>;epid=35D712543B;tag=427678421c

     

    This is the answer:

     

    From: <sip:193.142.141.62:5060;ms-opaque=a608f2b222a0b01b;ms-opaque=a608f2b222a0b01b>;tag=427678421c;epid=35D712543B

     

     

    That’s why Mediation Server discards the answers from the other end.


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter

    So if this is the reason that answers are being discarded, can you help with the resolution to this issue? Is there some configuration on the gateway that can be set so that it sends responses that the Mediation server is expecting? Can't help feel that Microsoft have moved the goal posts with this latest patch? Although, why does the patch only cause this issue with NET gateways?
    Friday, May 27, 2011 8:36 AM
  • ...and now I would ask - since this affects NET gateway only (based on the reports thus far), is it possible that CU2 made Lync more strict and NOW the .NET flaw is no longer tolerated? It would be nice if someone has trace from before CU2 saved.

     

    Drago


    http://www.lynclog.com
    Friday, May 27, 2011 7:57 PM
  • I have recently seen and resolved this issue with a customer today.

    The software version of your NET VX gateway needs to be up to date. 4.7.5v19 is suitable for the Lync CU2.

    Jim

    • Proposed as answer by Jim002 Wednesday, June 1, 2011 8:49 PM
    • Marked as answer by Lync user Wednesday, July 27, 2011 10:52 AM
    Tuesday, May 31, 2011 7:11 PM