Before we start, I highly recommend you first read Scott Stubberfield’s “Anonymous join from Skype for Business and Lync Clients” blog post: https://blogs.technet.microsoft.com/scottstu/2015/04/03/anonymous-join-from-skype-for-business-and-lync-clients/

Now that you understand the anonymous join process, we’ll go into one scenario that I’ve been tracking since Lync Server 2013 RTM (almost 4 years…).
UPDATE Sept 17,2017: Issue resolved, see: Skype for Business Anonymous Join Success When meeting organizer is disabled for federation

Scenario:

• Company A has Federation Enabled
• User at Company A has an External Access Policy set to have Federated User Access disabled
• This User schedules a meeting and sends the invite to an external participant
• External participant is running the Lync or Skype for Business client
• External participant tries joining the meeting, but is greeted with “An error occurred during the Skype Meeting”
• External participant is able to join the meeting if forcing connection via Web App in browser (appends ?sl=1 to the end of the meeting URL)
  
  

Let’s compare some client logs for the External participant:

• Company A Federation Enabled and Meeting organizer Enabled for Federated User Access (Successful federated join):
  
• Company A Federation Disabled or External participant’s domain is blocked (Successful anonymous join):
  
• Company A Federation Enabled and Meeting organizer Disabled for Federated User Access (Failed anonymous join):
  

As per Scott’s blog, the following table lists the valid SIP response or diagnostic codes that the client will use to trigger the anonymous join process:

So we have the External participant’s client triggering anonymous join when seeing 504 or 404, but not the 403 response that is received when the meeting organizer is disabled for federation.