It's definitely source port.
Seeding only works for databases within a DAG.
It only applies to PC clients. Mobile clients do not support QoS.
You don't have to do this. The Clustering Service will take care of all this during the DAG creation process or the failover process.
Yes, that makes sense. If the client is authenticating, all you need to do is have the Exchange User permission checked. This will allow them to utilize that connector. Then for the devices that cannot authenticate, you can simply just use the relay connector as I have outlined in this article.
You need to use either Anonymous as I outlined or you can use Externally Secured. The problem with Externally Secured is anything that hits that connector also bypasses antispam rules. With Externally Secured, you're providing more privileges than are necessary. Principle of Least privilege applies here. I recommend using the Anonymous Group method I have outlined. As always, it is imperative that you restrict what IPs can hit your connector or you will turn your server into an open relay.
This article has absolutely nothing to do with disabling SSL for any Exchange related stuff and is about disabling SSL at the root only as an option. Obviously if you require any security at the root such as for logging in or anything else, you would want SSL. And if you do want SSL, make sure the certificate includes the root domain name. Both are options. Obviously you need to make the smart decision based on your needs. But again, it's still a workable option. And quite honestly, if you decide to choose the disable SSL option and your root webpage needs SSL for secure transactions or for secure logins, you shouldn't be in IT...
I did however edit the post to add some clarification around the preferred method and why.
Yep, my mistake. I knew that but copied this from another really old Autodiscover article I wrote before I learned about the oldest SCP thing. Thanks for pointing it out, I will get it corrected.
SIP always goes from the Edge to its next hop. However, Media always goes direct to the shortest path. So the Edge A would send media directly to Pool B. Edge A would talk to Pool A (if Pool A is Edge A's next hop), Pool A would proxy the traffic to Pool A if the conference or user is on Pool A for authentication., and then the media will go direct.
If Pool B is in another site with its own Edge B, part of the proxy from Pool A to Pool B will find the External AV FQDN for Pool B and have the external user talk to the AV FQDN that belongs to Edge B and the external user will start talking to Edge B. This is what enables regional/worldwide deployments to ensure AV is as local as possible no matter what Edge you may initially hit for authentication.
You need to use the Charm and choose Settings.