09 April 2014

Security Announcement - ice is NOT affected by OpenSSL bug Heartbleed.

Written by Martin Borowski, Posted in Troubleshooting, Microsoft, Lync, Technology

Heartbleed is a security bug in OpenSSL, the most popular software code that encrypts and protects sensitive data such as passwords and banking info. Websites that use this code show a green lock in the URL bar. According to researchers at Codenomicon, a Finnish firm, this bug can be exploited by malware and cyber criminals - they could look at the memory of the bug-affected code, enabling them to grab the keys needed to decode and read data.

We are happy to announce that the versions of OpenSSL that ComputerTalk uses in ice Contact Center solutions are not affected by this vulnerability.

If you wish to check if the web services you're using are vulnerable to this, you can test it here: Visit the Heartbleed test site

Information about Heartbleed came from http://www.cbc.ca/news/technology/heartbleed-web-security-bug-what-you-need-to-know-1.2603988

01 April 2013

Attendees cannot join your Lync web conference?

Written by Dennis Menard, Posted in Troubleshooting, Lync


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:

01 August 2012

UCMA apps, load testing, and timeouts

Written by Chris Bardon, Posted in Troubleshooting, Lync

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.

27 July 2012

UCMA Startup errors - when everything else doesn’t work, check the hosts file

Written by Chris Bardon, Posted in Troubleshooting, Microsoft, Lync

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)

05 December 2011

Troubleshooting UCMA applications - Microsoft Lync, DNS entries, and failed calls

Written by Chris Bardon, Posted in Troubleshooting, Microsoft, Lync

UCMA application troubleshooting

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.