KB3055014 and KB3085500 introduces an unknown xml “400 Bad Request” issue

I noticed recently on several client troubleshooting (using the Snooper tool) on a particular “400 Bad Request” message that appears on the end calls.
After several cumulative updates (CU) history regression testing, I found that this behaviour started appearing with the latest two CU (or correctly, the security updates):

  • KB3055014 – security update for Microsoft Lync 2013 (Skype for Business): August 11, 2015
  • KB3085500 – security update for Microsoft Lync 2013 (Skype for Business): September 8, 2015

If you have any of those updates, you will find the 400 error message on every call (PSTN or Skype) when the called party disconnects. Here’s an example of the same call I made to a PSTN number:

  • Until the July 2015 update, the client will send an “error” report in xml format for the front-end server
    ClientErrorReport-Jul2015Req
  • After the August/September 2015 updates the same report is now different (similar response as a Skype-to-Skype)
    There’s a <progressReport/> ending without any initial <progressReport>
    ClientErrorReport-Aug2015Req
  • The server detects this incorrect xml format and that’s why you see the “400 Bad request” and a “Client.BadCall” fault
    ClientErrorReport-ServersBadXML

For the end-user there is no visible or functional impact.
I still don’t know if there are any impacts for the backend services. The call diagnostics for CDR and QoE diagnostics are correctly sent on another SIP message.

Advertisements

2 thoughts on “KB3055014 and KB3085500 introduces an unknown xml “400 Bad Request” issue

  1. Romain 02/12/2015 / 13:52

    Hi Luis,

    I face the same issue.
    A user told me that he gets disconnected randomly from this audio of a Skype meeting. When I check his sip logs I can see :
    SIP/2.0 400 Bad request

    Client.BadCall

    Did you get more information about this issue? Did you find a solution to solve this issue?

    Regards,
    Romain

    • LuisR 02/12/2015 / 14:06

      I didn’t received any issues from users regarding this.
      The fact is that any normal disconnection also generates the error, so I expect that any other unexpected disconnection will also generate that one.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s