Lync 2013 Mobile Clients and Apache Reverse Proxy

Just a heads up: You may be experiencing issues using the new Lync 2013 mobile apps if your reverse proxy is Apache. I don’t have a solution at this time, but have confirmed replacing Apache with IIS ARR works just fine in the same environment. All other external web services and the old 2010 mobile clients work properly, but we observed the following behavior on the 2013 apps:

  • First client sign-in attempt fails, but second sign-in succeeds.
  • Presence for contacts is very slow to load.
  • Client sign out generates an error that the connection to the server was lost.
  • Voice and video calls will not connect.

There are no clues in the server-side logs, but if you review the mobile client logs you’ll find the following error after Apache sends the mobile client a response:

ERROR TRANSPORT TransportUtilityFunctions.cpp/1749:Accept-types (application/ not found in Content-Type response from server (text/plain).  Not decoding.

Deciphering this, the client is expecting an HTTP header to be returned with the a Content-Type of application/ to be returned with the server response. The mobile client logs also show the HTTP headers in each response, which include the following:

HttpHeader:Content-Type text/plain

Since the UCWA MIME type is not a default registration on Apache the server instead reverts to its default behavior of sending text/plain for any content type it does not understand. The response being returned as text/plain causes the mobile client to error out and disconnect the request.

We attempted to register the MIME type with the following command, but it proved unsuccessful.

AddType application/ .xml

Maybe some other Apache guru can share a fix here, but I wanted to save others the troubleshooting time if you see this issue.

Sharing is Caring   


Comments from the Peanut Gallery

  1. Luca Vitali

    Hi, we have the same issue!
    Thank you for thies post, I hope someone could fix it.

  2. Mario

    Any news about this issue?

    I have the same problem…

  3. Tom Pacyk

    Hi guys, I don’t have a fix at this time, but it appears the issue may be limited to Apache while running on Windows. Drago Totev has confirmed it works fine with Apache running on Ubuntu.

  4. Mario

    In our Windows server and Apache we weren’t able to work with Lync 2013 mobile (voice and video didn’t work).

    The problem was due to content type.

    In a windows environment, you see the entry:
    DefaultType text/plain
    in httpd.conf and this is the problem.

    In an Ubuntu environment instead, you see the entry on a .conf file:
    DefaultType None

    So, this is reason that Lync 2013 mobile works on Ubuntu.

    We set
    DefaultType None
    in our windows environment, and it works!

    Best regards,

  5. Neeraj

    Thanks Mario,

    Setting DefaultType to “None” on Ubuntu also fixed our issue with iOS and Android devices.

    However, Windows Phones are still unable to connect in and are getting 401 errors.

    Anybody care to share the Apache config file from a fully-working server?


  6. Wolfgang

    Would be interested in that too. Only getting problems on WinPhone 8. All other platforms ware working. Cannot sign in 401.

  7. Robert Panduru [MSFT]

    The issue is known, and manifests itself under multiple forms in the Lync for Mobile client running under iOS. The error E2-1-5 (hex.: 0x22010005, dec.: 570490885, desc.: E_ResponseUnknown) following the event mentioned in the article is typical for this problem.

    The erratic behavior is determined by the Apache reverse proxy who stamps a Content-Type text/plain header on all responses lacking this header. Missing the Content-Type header is considered valid as long as the messages have a Content-Length equal to 0. The client expects either the “application/” content type header or none at all.

    The solution recommended by Mario and Neeraj can be applied from Apache v2.2.7 on. For previous versions of Apache, consider upgrading or moving to one of the reverse proxy products qualified for Lync 2013:

    Infrastructure qualified for Microsoft Lync

Chime In