If you are a frequent user of Microsoft Lync for hosting web conferences then you must have encountered situations where the attendees cannot join the Lync web conference, or if they do, they cannot see your shared content. Another scenario, is that you get a networking error in Lync, when you try to share your content. These type of connectivity errors are often because of firewall restrictions, or incorrect network routing rules - somewhere between you and the attendee.

I have found that the Lync web client almost always works in these situations. However, attendees often have Lync installed already, so they don’t get the choice to connect via the Lync web client. According to Jeff Guillet, (http://www.expta.com/2011/12/how-to-force-using-lync-web-app.html) there is a way to force attendees and presenters to connect via the Lync web client. “To do this”, Jeff blogs, “simply add ?sl= to the meeting URL.”

For example,   https://meet.computer-talk.com/meet/dmenard/VFXXXM0Q?sl=

This will open the following form:

One of the things that often ends up coming up too late in a development cycle is testing your application under load. Sometimes we think to do this early on, but more often than not, one of the last things developers tend to do is throw traffic at an application until it breaks. The problem is, finding an issue with load at the end of a dev cycle can be very difficult to fix, and it can call into question some of the fundamental aspects of your architecture.

This was a fun round of troubleshooting. One of our developers needed to debug a UCMA application that we’ve run on dozens of other servers. He went through the steps to provision the app, just as we had everywhere else, but we got the following exception from starting the platform:

Portal failed establishing the endpoint: Microsoft.Rtc.Signaling.ConnectionFailureException:Operation failed because the network connection was not available. ---> Microsoft.Rtc.Internal.Sip.SipException: Invalid From header: Semantic error:  fTopLabel == true
   at Microsoft.Rtc.Internal.Sip.FromHeader.Parse(SipHeaderLink& headerLink)
   at Microsoft.Rtc.Internal.Sip.FromHeader..ctor(String headerValue)
   at Microsoft.Rtc.Internal.Sip.NegotiateLogic.CreateABlankNegotiate(FunctionType funcType, String negotiateData, SipResponse prevResponse)
   at Microsoft.Rtc.Internal.Sip.NegotiateLogic.StartCompression()
   at Microsoft.Rtc.Internal.Sip.NegotiateLogic.AdvanceOutboundNegotiation()
   at Microsoft.Rtc.Internal.Sip.TlsTransport.DelegateNegotiation(TransportsDataBuffer receivedData)
   at Microsoft.Rtc.Internal.Sip.TlsTransport.OnReceived(Object data)

One of the most frustrating things that you can run into when working with UCMA is starting your application, placing a call to it, and having that call fail.  As far as your code is concerned, everything is great.  Calls worked yesterday, calls work for other developers, but for some reason, your call is failing.  At this point, the only real way to track down what’s going on is to go on the server and run OCSLogger.exe and trace the call.