Here is
an "interesting" observation I did a couple of days ago. The customer has chosen not to allow
DNS discovery of federated partners, but will allow federation with selected
partners on the allow list. After a while with this configuration, the customer called me and
told me they had mixed experiences with the solution. There were times when
meetings with a partner (NOT on the allow list) actually would work, even if
they expected the meeting to fail.
They
asked me to verify the settings, and to investigate why some users reported
they could connect to a meeting others couldn't.
This is
what I saw on a client who failed to connect:
5
messages. And the interesting one would be the 504 message: "Can not
route".
And then
the client stops trying, as I would expect it to.
But here
is an interesting twist. Log on with the same client from a remote connection
(through edge), and then let's see what happens.
The
client does not honor the 504 message "Can not route". It continues
and connects to the meeting, unexpectedly. How can that be?
The
interesting part is what happens after the 504 message. First the client
acknowledges the rejection, but then it does something it didn't do on the
inside. There is a new invite, trying to connect anonymously:
And this
connection is allowed. Quite confusing for the end user, actually. But now they
know.
It is
important to note the user was allowed for federation in this scenario, but the
domain in question was not in the allow list and DNS discovery was not allowed.
Also, the organizer on the other side was allowing anonymous invites.
Comments